README.md 6.13 KB
Newer Older
oneM2Mdev's avatar
oneM2Mdev committed
1 2 3
oneM2M-schemas
==============

PeterNiblett's avatar
PeterNiblett committed
4 5 6
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
PeterNiblett's avatar
PeterNiblett committed
7 8 9 10

Further work / questions on the schemas is listed here. Many of these need CRs against TS-0004

General
PeterNiblett's avatar
PeterNiblett committed
11 12 13
 
    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.
Peter Niblett's avatar
Peter Niblett committed
14
    Showing the cardinality of child resources is tricky for resource types where the cardinality varies by child resource. It's easy to do if we make them a sequence, but that forces a particular order. If we want to allow them to appear in any order, we have to use a repeated choice, which makes it hard to force a minOccurs of 1 or a maxOccurs of 1 on any of the of the child resources - they all become [0..n] 
PeterNiblett's avatar
PeterNiblett committed
15 16 17 18 19 20 21

\<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
PeterNiblett's avatar
PeterNiblett committed
22
    Do something with the 2 character country codes.
PeterNiblett's avatar
PeterNiblett committed
23 24 25 26

\<container\>

    What values go in latest and oldest if there are no child resources?
27

PeterNiblett's avatar
PeterNiblett committed
28 29 30 31
\<CSEBase\>

    m2m:resourceTypeList can be removed, since this type can be declared inline

32 33 34 35 36 37 38
\<execInstance\>

    It isn't clear what the type of execDisable ought to be, as it isn't obvious what the cancellation mechanism is. TS-0001 says "The UPDATE request shall address the execDisable attribute with a predefined value in order to trigger the CANCEL action" i.e. you trigger a cancellation by writing a "predefined value" to this attribute, but doesn't say what that value is. We could achieve that by making it xs:boolean or by making it a string with two permitted values (e.g. "" and "CANCEL"). On the other hand TS-0004 says "Cancel operation is triggered by an Update primitive, if the primitive addresses the execDisable attribute or the URI provided as the value of the execDisable". This suggests that execDisable should be xs:anyURI and that triggering is cancelled either by writing a new URI into it, or by sending an Update to the URI that it already contains. The corresponding execEnable attribute in \<mgmtCmd\> has type xs:anyURI.

    In TS-0004 7.2.16 the execStatus attribute has type m2m:execStatusType, but in the enums clause the type is called m2m:execStateType


PeterNiblett's avatar
PeterNiblett committed
39 40 41 42 43
\<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?

Peter Niblett's avatar
Peter Niblett committed
44 45 46 47 48
\<node\>

    There's an attribute which is called called hostedCSEID in TS-0004, but is called hostedCSELink in TS-0001
    The cardinality of the child resources is enforced (see general comment)

49 50 51 52
\<serviceSubscribedNode\>

    Needs to be added to TS-0004 (in place of authororizedNode)

PeterNiblett's avatar
PeterNiblett committed
53

PeterNiblett's avatar
PeterNiblett committed
54 55
\<subscription\>  

PeterNiblett's avatar
PeterNiblett committed
56
    Should the eventNotificationCriteria type be moved in to Common Types? (i.e. is it used anywhere else)?
PeterNiblett's avatar
PeterNiblett committed
57 58 59 60
    
CDT-enumerationTypes

    Add or update definitions of the following types:
61 62
      resultContent, statusCode, requestStatus, notificationCongestionPolicy, SRole-ID
    Decide how to represent the attribute attribute
PeterNiblett's avatar
PeterNiblett committed
63 64
    Does m2m:memberType need to be different from m2m:resourceType? Can we remove it?
    Sort out the two m2m:operation types
PeterNiblett's avatar
PeterNiblett committed
65 66
    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
PeterNiblett's avatar
PeterNiblett committed
67 68 69
    
CDT-commonTypes

PeterNiblett's avatar
PeterNiblett committed
70 71 72 73 74 75 76
    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
77
    The declaration of m2m:responseStatus/description looks wrong
PeterNiblett's avatar
PeterNiblett committed
78 79 80


    More general revision and checking of CDT-commonTypes is required (defer this until after the other XSD files are complete)
PeterNiblett's avatar
PeterNiblett committed
81 82
    
    
Dale Seed's avatar
Dale Seed committed
83
Announcement of mgmtObj Specializations
PeterNiblett's avatar
PeterNiblett committed
84

Dale Seed's avatar
Dale Seed committed
85 86
    TS-0001 defines whether each of the common attributes of the mgmtObj are announceable or not.  However niether TS-0001 or TS-0004 defines which of the specialization specific attributes are announceable or not.  This information is needed before  each of the specialization XSDs can be updated with announced versions of resources 
 
PeterNiblett's avatar
PeterNiblett committed
87