What is the reponseFormat that we are working on called?

[GoogleCodeExporter]

OOSTethys used 'text/xml;subtype="om/1.0.0"'

Can we safely adopt that, or will it cause client nightmare?  It seems like the 
correct response format type for this.

1.) text/xml;subtype="om/1.0.0"
2.) text/xml;subtype="om/1.0.0/ObservationCollection"
3.) ?

Original issue reported on code.google.com by wilcox.k...@gmail.com on 17 Oct 2012 at 7:26

[GoogleCodeExporter]

Original comment by dpsnowde...@gmail.com on 22 Oct 2012 at 4:30

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

I vote #1 (text/xml;subtype="om/1.0.0"). It's what I've always seen used. 

Original comment by sh...@axiomalaska.com on 23 Oct 2012 at 10:50

[GoogleCodeExporter]

Any objections?

Original comment by sh...@axiomalaska.com on 26 Oct 2012 at 9:53

[GoogleCodeExporter]

I don't have a *constructive* objection, but doesn't 
text/xml;subtype="om/1.0.0" imply swe/1.0.x as well? If it does, 
text/xml;subtype="om/1.0.0" would be misleading, since we use swe 2.0 in 
om:result.

But I don't have an alternative to suggest. Other than, maybe:
text/xml;subtype="ioosTemplateVersion/1.0"
I suspect we don't want that, though it passes the truthyness test.

If no else raises other objections and my own objection and suggestion seem too 
weak, let's just go with text/xml;subtype="om/1.0.0"

Original comment by emilioma...@gmail.com on 26 Oct 2012 at 10:50

[GoogleCodeExporter]

Well, it *is* an om/1.0.0 document, it just happens to contain an extra 
namespace (swe2). Right? I think we can still call it 
text/xml;subtype="om/1.0.0" and move on...

Original comment by sh...@axiomalaska.com on 26 Oct 2012 at 11:00

[GoogleCodeExporter]

Sure. +1

Original comment by emilioma...@gmail.com on 27 Oct 2012 at 5:06

[GoogleCodeExporter]

I can't decide if I like Emilio's suggestion to use a custom response type like:

text/xml;subtype="ioosTemplateVersion/1.0"

If we adopt text/xml;subtype="om/1.0.0", parsing libraries won't be able to 
tell the difference between our response and any other without looking for the 
<gml:metaDataProperty xlink:title="ioosTemplateVersion"> tag in its predefined 
place.  BUT, libraries will already need to read this property since there will 
be future versions...

Does anyone else want to weigh in here?

I think i'm leaning towards at +1 for using text/xml;subtype="om/1.0.0"

Original comment by wilcox.k...@gmail.com on 14 Nov 2012 at 4:12

[GoogleCodeExporter]

Reference for this discussion is  IETF RFC 3023.

Original comment by dpsnowde...@gmail.com on 19 Dec 2012 at 8:34

[GoogleCodeExporter]

text/xml;subtype="ioos_sos/1.0"
text/xml;subtype="ioos_sos/1.1"
text/xml;subtype="ioos_sos/2.0"

Any last comments before we adopt this?

Original comment by wilcox.k...@gmail.com on 19 Dec 2012 at 8:40

[GoogleCodeExporter]

+1 for Kyle's 12/19/2012 suggestion. Let's close this.

Original comment by sh...@axiomalaska.com on 29 Dec 2012 at 12:03

[GoogleCodeExporter]

If we accept Kyle's suggestion, do we have to provide and maintain IOOS 
schemata for SOS 1.0 and 2.0?

Original comment by abir...@gmail.com on 31 Dec 2012 at 5:47

[GoogleCodeExporter]

I thought Shane's response on Oct 26 (Comment 5) made sense, arguing for using
text/xml;subtype="om/1.0.0"
It's not 100% satisfying, but it is consistent and rational.

As Kyle points out, that does imply that parsing libraries will need to look at 
the <gml:metaDataProperty xlink:title="ioosTemplateVersion"> tag, but I think 
this was implicit already in our approach towards this SOS reference 
implementation. We have deliberately avoided developing a new IOOS schema. I 
can't comment on Alex's question whether using text/xml;subtype="ioos_sos/1.0" 
*requires* us to maintain IOOS schema, though. I also don't know what Derrick's 
Dec. 19 comment about IETF RFC 3023 refers to; Derrick, can you add URL's or 
explain it?

Otherwise, my vote is for Shane's original preference:
text/xml;subtype="om/1.0.0"
(Now, if we could have, say:
text/xml;subtype="om/1.0.0";subsubtype="ioos_sos/1.0"
that'd be peachy)

Original comment by emilioma...@gmail.com on 31 Dec 2012 at 7:28

[GoogleCodeExporter]

BTW, in the current GetCapabilities template, 
sos:ObservationOffering/sos:responseFormat is listed as:
text/xml;schema="om/1.0.0"

Should that be "subtype" rather than "schema"? I don't know the answer, but it 
seems very inconsistent to have here something different from what would be 
used in issuing a GetObservation request.

Original comment by emilioma...@gmail.com on 31 Dec 2012 at 7:34

[GoogleCodeExporter]

I've seen both schema and subtype used... 'schema' seems more appropriate but I 
don't really know.  In "text/xml", the "xml" is already a subtype.  Specifying 
another "subtype" has always confused me and I may have changed them to 
"schema" as I came across them.

I still +1 #9, schemata or not.  Once these templates are done, will it be easy 
to generate a schemata?

Original comment by wilcox.k...@gmail.com on 3 Jan 2013 at 3:18

[GoogleCodeExporter]

The OGC SOS 1.0 spec uses response formats of text/xml;subtype=... throughout 
its examples.  They must have had some reason for this.

Original comment by mike.gar...@gmail.com on 3 Jan 2013 at 4:03

[GoogleCodeExporter]

Google "ows:MimeType" or look in owsCommon.xsd (sometimes it's just ows.xsd).  
I don't think either suggestions are illegal.  I can't for the life of me find 
any guidance on what goes after subtype (text/xml;subtype=...).  The definition 
in the schema shows the following pattern...
{{{
<simpleType name="MimeType">
<annotation>
<documentation>
XML encoded identifier of a standard MIME type, possibly a parameterized MIME 
type.
</documentation>
</annotation>
<restriction base="string">
<pattern 
value="(application|audio|image|text|video|message|multipart|model)/.+(;\s*.+=.+
)*"/>
</restriction>
</simpleType>
}}}

My interpretation is that anything after teh s* is legal.  So, if it doesn't 
matter in the spec then either 

om/1.0.0
or 
ioos_sos1.0 

are legal.  Look at the example here as well... 
http://www.geostor.arkansas.gov/arcgis/services/FEATURE_SERVICES/GEOSTOR_ENVIR/M
apServer/WFSServer?request=GetCapabilities&service=WFS  

{{{
<ows:Parameter name="outputFormat">
<ows:Value>text/xml; subType=gml/3.1.1/profiles/gmlsf/1.0.0/0</ows:Value>
</ows:Parameter>
}}}

I don't know if that's legal but it is in use.  I suggest we use the following 
proposal similar to the one Emilio thought was peachy...
text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"

Again, I'd like to close this by 1/7/2013.

Original comment by dpsnowde...@gmail.com on 3 Jan 2013 at 6:17

[GoogleCodeExporter]

+1 on 'text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"'

Original comment by wilcox.k...@gmail.com on 3 Jan 2013 at 6:30

[GoogleCodeExporter]

+1 on text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"

It's somewhat breath taking, but it is informative and does reflect reality.

Regarding the use "schema" rather than "subtype" in GetCapabilities, based on 
Kyle's and Mike's comments (14 & 15), it sounds like the value of
sos:ObservationOffering/sos:responseFormat
should be changed to also be
text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"

Original comment by emilioma...@gmail.com on 3 Jan 2013 at 9:57

[GoogleCodeExporter]

+1 for text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0".

Kyle, want to close this?

Original comment by sh...@axiomalaska.com on 10 Jan 2013 at 10:26

[GoogleCodeExporter]

Agreed.  Issue is closed and will be written up on SOSGuidelines.  Kyle, can 
you add this to the template?

Original comment by dpsnowde...@gmail.com on 30 Jan 2013 at 3:35

• Changed state: Done