Data components that are children of an instance of a block component shall be used solely as data descriptors.

[GoogleCodeExporter]

08-094r1 SWE Common Data Model 2.0
Req 49. Data components that are children of an instance of a block component 
shall be used solely as data descriptors. Their values shall be block encoded 
in the “values” attribute of the block component rather than included 
inline.

Our templates do not meet this requirement. We use inline values in DataArrays, 
Vectors and in the fields of the DataStream to specify values which do not 
change in each record such as location. Our resulting data structure is 
unambiguous. Fields which have a specified value inline, can not have a value 
in the block encoded records. A strict interpretation of this requirement would 
make SWE unusable for the IOOS use case.

I suggest we note this issue and move forward with Milestone 1.0. Then address 
this issue with OGC and propose relaxing this requirement. 

Credit to Shane StClair for bringing this issue forward. 

Original issue reported on code.google.com by stu3b3 on 1 Mar 2013 at 4:12

[GoogleCodeExporter]

FYI, I contacted Mike Botts and Alex Robin about this issue. I get the 
impression from the SWE 2.0 spec that the intention of Requirements 49 and 52 
is only to prohibit the use of <swe:values> in data components (e.g. DataArray) 
that are used within the elementType of a DataStream, DataArray, or Matrix, and 
not to prohibit the use of static swe:value elements within swe:field 
definitions in those elementTypes. Otherwise it seems that the use of swe:value 
within swe:field at all would be prohibited, and there are examples in the SWE 
2.0 spec (08-094r1) that show this usage (e.g. top of page 92). I'll report 
back with the verdict from Mike and Alex.

Original comment by sh...@axiomalaska.com on 2 Mar 2013 at 1:30

[GoogleCodeExporter]

Shane, I am in Reading now at the 4th ECMWF workshop. Mike Botts is not here 
but Alex Robin has a presentation Wednesday morning. I can ask him directly, 
and let the team know.

Original comment by abir...@gmail.com on 4 Mar 2013 at 9:08

[GoogleCodeExporter]

That would be a great help - thank you Alex.

Original comment by stu3b3 on 5 Mar 2013 at 3:07

[GoogleCodeExporter]

OK, here is the Alex Robin's verdict: 
1. in general, our templates violate the spec;
2. specifically, it is a violation of the swe2 spec, hence not a big deal for 
now as we use a mix of swe1 and swe2;
3. the best solution would be to keep the templates "as is" but make a notice 
of that conflict, and fix it in Milestone 2.0.

The intention of the requirement was to keep the DataArray, DataStream, etc. 
clean and uniform, i.e. to prohibit the mix of variables and constants in the 
same array. It is not the case with swe1 as there is no way to avoid the use of 
an all-inclusive <swe:DataStream>. In swe2, that use of the <swe:DataStream> is 
not mandatory. Thus, the solution is to move all <swe:values> with inline 
values (lat, lon, etc.) outside of the DataStream or DataArray.

Alex Robin graciously suggested that we send one of our templates to him and he 
restructures it in a way that swe2 requires. I won't be able to do that till 
next Monday, perhaps Shane could do that earlier this week?

Original comment by abir...@gmail.com on 6 Mar 2013 at 11:34

[GoogleCodeExporter]

What I meant in my previous comment by moving "inline values" outside of the 
DataArray, was to make another DataRecord, which the initial DataArray will be 
a part of, and move those constants to the beginning of that inclusive 
DataRecord. 

Hopefully, all of this makes enough sense...

Original comment by abir...@gmail.com on 6 Mar 2013 at 11:40

[GoogleCodeExporter]

Discussion of this issue primarily took place on the IoosTech_dev list in an 
email thread titled: SWE 2.0 compliance and the IOOS SOS

The resulting template structure is redesigned using a DataRecord as the root 
element rather than a DataStream. The DataRecord contains two fields one for 
static metadata about stations and sensors, and one for dynamic observation 
data from sensors.

The key to this schema is the implicit use of the same value for DataChoice 
Item@name in the dynamic data and for sensor DataRecord@id in the static 
metadata. This makes it easy to parse and find sensor data or sensor metadata 
in a single query.

All the field elements of this data structure are identified by the definition 
(type) of element they contain. For instance the field which contains the 
station metadata can be found by keying on the "stations" definition:
  <swe2:field name="stations">
    <!-- IoosTech Convention: -->
    <!-- The data record containing the static data for each station shall be defined -->
    <swe2:DataRecord definition="DEFINE_ME_http://mmisw.org/ont/ioos/definition/stations">

All such conventions are noted using the above format. Most of these new type 
definitions have yet to be entered in MMI and so have the prefix "DEFINE_ME" 
for the time being.

This is an explicit choice to move away from using the name attribute as a type 
identifier. The use of definition is much more appropriate and will avoid 
confusion later on.

Please review and comment by Monday, May 6.

David

Original comment by stu3b3 on 1 May 2013 at 8:42

• Changed state: Started

[GoogleCodeExporter]

This issue is closed and complete.
David

Original comment by stu3b3 on 6 Jun 2013 at 4:53

• Changed state: Fixed