[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Define consistent approach to Tuples and SIngletons Language-compatible Profiles
There an almost-persistent blurring of Language and Serialization that is pretty consistent, and that is concerning to me.
In the language of the OMG, the Language and the promised-but-not-here Architecture section of the Language, is in effect the PIM (Platform Independent Model), and each of its Serialization/Binding documents is a Platform Specific Model (PSM). One of the Profiles, i.e., the Actuator Profile, should be expressed in the PIM, but instantiable in each PSM.
The PIM should support all the PSMs, but not specify one. It is an artifact of development and current thinking that the TC has opted to express the language and information model using JSON, but a PIM is still fundamentally abstract, that is, it should not interfere with or dictate the possible PSMs.
The Language document explicitly allows (but does not require) multiple in many places. A message MAY contain many commands. A command MAY contain many Targets. A PSM MAY constrain a message to be a single one of each, Command and Target.
If (as seems the case) the JSON Binding is restricting to one command and one target. That is a fine decision for a PSM, and I have no complaint about that.
The architecture, though anticipates some other interactions. These include:
1. A single message having multiple commands. At a later time, it may be appropriate (as Duncan’s note suggests) to change or revoke a specific one of these commands.
2. A Target may wish to respond to individual commands with separate messages.
3. A Bridge device may need to unpack a multi-command message into multiple messages as it bridges a command to a different PSM
4. A Bridge device may need to unpack a single-command message into multiple single-target messages as it bridges a command to a different PSM.
5. A Command or Message may need to be re-transmitted, either because of some sort of race state in the target (it may be under attack, after all) or for incorporation into a suite of responses/commands to a particular situation or incident.
In each of these cases, it is troublesome to have blurring between the transport mechanism (which would include header info) and the message payload.
That said, IF a PSM restricts a Message to a single Command, and IF a PSM expects a MessageID within the command, then it MAY be reasonable to make the MessageID and CommandID identical. Alternately, it is reasonable that IF a PSM requires a single command inside a Message, to require them to be the same.