Discussion: Is the <action> "input" attribute correctly defined?
Looking at the <action> resource's input attribute I am wondering how it is supposed to work and whether it is correctly specified.
To refresh: If the input attribute is present in an <action> resource and that <action> resource is triggered, then the value of the input attribute replaces the Content parameter of the <action>'s request. The interesting part here is that this adds the possibility to add some late "binding" flexibility to the content for the <action>'s request.
But looking at the type definition and how this attribute is applied I am a bit puzzled about the details. input is of type "m2m:actionInput, which a complex type with three attributes that are mutual exclusive (defined in TS-0004, 6.3.5.80):
Element Path | Element Data Type | Multiplicity |
---|---|---|
contentString | xs:NCName | 0..1 |
resourceID | xs:anyURI | 0..1 |
resourceAttributeID | xs:anyURI | 0..1 |
Note: These elements are mutually exclusive from one another. Exactly one of these elements shall be present.
The procedures are defined in TS-0001, 10.1.21.2. The following is an extract from that procedure and some comments about it where I have problems understanding the procedures.
If the input attribute is present and is a string, the Hosting CSE shall overwrite the Content parameter of the primitive to be sent with the string.
How should this work? The Content attribute always is complex type, a resource etc., but not a string.
If the input attribute is present and is a resource identifier, the Hosting CSE shall retrieve the resource and overwrite the Content parameter of the primitive to be sent with the retrieved resource representation.
This sounds like a good idea, but it isn't. First of all it is only useful if the <action>'s request is a CREATE request. Then, and this is the main problem, just copying a resource is not enough. Before "overwriting the Content parameter" at least all the NP attributes need to be removed from the copy. There might also be other attributes, depending on the resource type, that are not allowed or meaningful when creating a resource.
This would be easier if oneM2M would support a kind of "resource templates".
Last but not least there is no procedure defined to check the validity of the input attribute during CREATE or UPDATE of an <action> resource, such as availability, access control etc.
If the input attribute is present and is a URI of a resource attribute , the Hosting CSE shall retrieve the resource attribute and overwrites the Content parameter of the primitive to be sent with the value of the given resource attribute.
Again, a good idea for indirect flexibility, but how should this work?
First, we don't have a URI format to address individual attributes (or do we?). Usually, even in the <action> we use two attributes to address a resource by its ID and then the name of the attribute when we do the evaluation.
The second problem is again the inner format of that attributes value: What is it? Does it need to be checked? etc.
To summarise, I have no idea what to do with the input attribute. Applying it as described in the procedure above it either leads to a wrong request or it cannot be determined. Personally, I think this attribute should be removed, and there should be some discussions and investigations how to correctly define or even extend this behaviour.