Re: Re: TSC.cmd / id

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

Hi Per,

Using the BSC or TSC schema the issue with including several blocks
within one message  is that the identifier for the endpoint that is
being reported is contained in the header,  as both a named sub address
(the portion of the address after the : ) and the last few digits of the
UID.  Hence all the block(s) content can only relate to this one
endpoint and not more.     You had blocks for different endpoints in one
message.

This approach is strongly recommended in xAP now - i.e. as much
addressing information as possible is contained in the header.  Some
early schema were designed differently and the 'context' of the block
was set by a parameter within the block, eg the device= in the X10 one
below.    We found that this approach , whilst often understandable by a
person when they read the schema, was difficult for computers
recognition without recourse to an electronic schema repository.  You
can still design a schema this way should you wish of course, it's just
not so intuitive to interpret.

xap-x10.event
{
command=on
device=B3
}

example.event
{
light=red
ident=flashing
}

Not a brilliant example (still suffering from the wine last
night)  but in the latter case it is unclear if the red light is now
flashing or if the flashing light has been turned to a red colour

You will see that when we send xAPBSC.cmd  or TSC.cmd messages we
support the target= address being wildcarded and then we support
multiple indexed blocks within one message and each contains an ID=
parameter to determine which endpoint is being addressed.  This was
included to allow coincident changes to be made to a device and it also
means that all or none of the changes happen (should a cmd fail to reach
a destination).

So back to your point about the block indexing being 'recommended
rather than mandatory' the point is that indexing is a recognised way
for code to interpret the content of blocks as being identical.
Additionally we do not (currently) apply any time based inference to
parameters eg that earlier blocks or parameters within those blocks
should be actioned before later ones.  This allows the message to be
broken apart and stored in a structured way and just queried for
parameter values.  Indexing identical blocks preserves some integrity of
order.

Lastly the comment about the schema specification and it's
precedence over the v1.2 protocol specification.   The protocol spec is
defining  the allowable construction of all possible variants of a  xAP
message , however not all variants of a message are going to be useful
or approriate in all schema .  For example many schema , including the
X10 one above,  do not use sub addressing at all.    If the schema uses
sub addressing, as TSC does, then by definition that message content
must only relate to the addressed endpoint from source=  .

Schema can just be seen as a higher layer protocol using xAP as a
transport - nothing would actually break in xAP at the protocol layer if
you did add more blocks but it would not be logical or valid at the
schema level.    The same is seen with high level protocols sitting on
top of TCP for example.

cheers Kevin


Per wrote:
> Kevin,
>
> Regarding the naming of the message blocks the xAP protocol
specification, 1.2-9, states:
>
> Message Body Policy: ...Multiple message blocks may share the same
name if, and only if, they use the same schema. In array type situations,
it is recommended that message blocks are labelled with an index...
>
> So, while it is recommended, it is not mandatory.
>
> You say that
>
> "However the BSC and TSC schema do not require (or support)
duplicate blocknames"
>
> All this makes me wonder about the relationship between the xAP
protocol specification and the different schemas. Correct me if I'm wrong,
but isn't the protocol spec. what defines how a xAP message is built and
parsed, and the schema defines which elements/block names that are to be
used?
>
> Based on your statement, one might make the conclusion that the TSC
schema takes precedence over the protocol specification. That can't be
right, can it?
>
> Regards,
>
> Per
>
>
> --- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
>> Hi Per
>>
>>      I think you have two sensors reporting here , channel 0 and 1
,
>> although both are possibly within the same physical device.  Best
for
>> TSC  if each sensor had a unique UID - and then the sub address
would
>> perforce also be different for each , and so would the ID e.g
ID=ABCD
>> ID=ABCE ... or ABCD01 ABCD02 or whatever
>>
>> You can't include two identically named blocks within one xAP
message
>> either so as a rule these would have to be indexed as below
>>
>> info.state.1
>> info.state.2   etc
>>
>> However the BSC and TSC schema do not require (or support)
duplicate
>> blocknames so if you create separate sub addresses for these
endpoints
>> they would then be sent as separate messages
>>
>> presence.status is not a defined part of the TSC schema either but
could
>> be included should you wish  (as you can supplement whatever
custom
>> blocks you like) but these might be better presented as an
additional
>> xAP schema/message of your own design.
>>
>>  Late night Saturday work eh...  most impressed :-) - my comments
are
>> post several wine bottles of wine and a party  so I hope they are
valid.
>>
>>     cheers  K
>>
>>  parameterPer wrote:
>>
>>> Hello,
>>>
>>> I'm a bit confused regarding the mandatory ID pair in the
TSC.cmd body.
>>>
>>> Based on the following xAP message, what would be the correct
ID value to set the latch on channel 1 to False be? I'd say ABCD, but
that'd be four characters and the spec limits it to two.
>>>
>>> Maybe I've missunderstood the sub addressing rules?
>>>
>>> xap-header
>>> {
>>> v=13
>>> hop=1
>>> Source=MSure.xAPGateway.Bigboy:D100000003AE661F
>>> Uid=FF.000001:ABCD
>>> Class=TSC.info
>>> }
>>> info.state
>>> {
>>> Channel=0
>>> ActivityDetected=True
>>> DetectedLevel=True
>>> LatchState=False
>>> DateTime=20091121233600
>>> }
>>> info.state
>>> {
>>> Channel=1
>>> ActivityDetected=True
>>> DetectedLevel=True
>>> LatchState=True
>>> DateTime=20091121233600
>>> }
>>> presence.status
>>> {
>>> connected=True
>>> }
>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>



------------------------------------