This is a private repository for developing oneM2M xsd files
The default branch will initially contain a "0.80" version of the files, mathching the 0.8 version of TS-0004
Further work / questions on the schemas is listed here. Many of these need CRs against TS-0004
General
How should virtual resources be represented? According to TS-0001 they are Child Resources, but they have a well-defined name which makes them look a bit like attributes that have a URI type. Presumably we are supposed to return these URIs if rc includes "child-resource-references" but not if it asks for just "attributes" or for "child-resources". So one interpretation is that we don't show them in the schemas at all, and they are just returned via the childResourceRef mechanism (this would mean we would need to add values for the virtual resources to the resourceType enumeration). The alternative is to represent them as explicit named elements in the schema (like we do for attributes) and return their values that way (when rc permits this).
There are a few places where attributes are defined as xs:string. If these are human readable - e.g. groupName - that's fine (though it raises a question of whether they should carry the xml:lang attribute). In some cases - e.g. contentType or locationStatus - it seems that the value is meant to be machine readable, but we don't enumerate (or even define) the allowable values for them.
\<accessControlPolicy\>
Do we need to give explicit names to all the types currently defined in the file?
Should some or all of theses types go into CDT-CommonTypes or CDT-Enumerations?
Since accessControlOperation is an enumerated integer type, we could represent accessControlOperationList as a list of simple types. This would be shorter than having it as a complex type.
Look at definition of accessControlOriginators
Do something with the 2 character country codes.
\<container\>
What values go in latest and oldest if there are no child resources?
Should <containerAnnc> be allowed to have <contentInstanceAnnc> as a child resource?
\<CSEBase\>
m2m:resourceTypeList can be removed, since this type can be declared inline
\<group\>
The order in which the attributes appear is different between TS-0001 and TS-0004 (also TS-0004 should say creator not Creator)
Should the element for the virtual resource be called fanOut or fanOutURI?
\<serviceSubscribedNode\>
Needs to be added to TS-0004 (in place of authororizedNode)
\<subscription\>
Should the eventNotificationCriteria type be moved in to Common Types? (i.e. is it used anywhere else)?
Does m2m:memberType need to be different from m2m:resourceType? Can we remove it?
Sort out the two m2m:operation types
Should have a better name for listOfBoolean (it isn't a list)
The third value of m2m:consistencyStrategy is called MODIFY_TYPE in TS-0004, but SET_MIXED in TS-0001
CDT-commonTypes
There are two different types to represent a list of URIs. One is a simple type (using XSD list) the other one is a complex type, containing a separate child element for each URI.
We should look at the way that IDs are represented in the schemas. At present most of them are just xs:anyURI. Is that sufficient?
There is some confusion as to whether the type is m2m:id or m2m:ID (and whether the other xxxid types should be xxxID or not).
TS-0004 now seems to have three different kinds of timestamp. There's m2m:timestamp, xs:dateTime and xs:dateTimeStamp
It is not easy to see how to represent the changes made by PRO-2014-0562-Implementation_of_Filter_Criteria_as_concept
Consider moving the m2m:filterUsage enumeration type into CDT-enumerationTypes
The order of elements in m2m:operationResult looks a bit strange
It's not clear what the cardinality of m2m:responseStatus/description should be
More general revision and checking of CDT-commonTypes is required (defer this until after the other XSD files are complete)
