Re: Re: PIC testing WAS OSD ALERT

[Ian Lowe]

> > Row ,Column or delay can be optional BUT if any included they
must be
> > in the proper order as im using a table and its ok to jump fwd
but
> > to keep jumping back and forth searching would be a pain to keep
> > track ...is this ok?? (im using asm) ;-((
>
> The xPL protocol doesn't specifically cater for the order in which the
> namepair come so it's best not to rely on it.

oops! yes, the order of namepairs *IS* fixed in the xPL Protocol:
all mandatory tags have to be present, in the correct order.
optional tags may be present or not, but if they are present, they *must*
be
in the right order.
developer's custom tags must be *after* any of the schema specified tags.

> Having said that though I
> see no reason why a device can't specific that it expects the
namepairs in
> a specific order as I see this as a operational point of the device
rather
> than the protocol.

This is specifically to allow for smarter, easier parsing of the messages
using a small MPU

>
> > hop =*....??
> > Source =.....ignore the rest
> > Target =aec-sunroom.tv or target =*
>
> hop= ignore for incoming the hub deals with hop counts - outgoing
message
> =1
> Source = ..ignore for incoming messages aec-sunroom.tv for outgoing
> Target = fine with above but you will need to state that the device
only
> support direct addressing or a full wildcard and not partial wildcards
i.e.
> aec-sunroom.*. Again I see this an acceptable device restriction.

yep, it's perfectly okay to not support any filters other than the full
match or full broadcast.

> On a more general note I believe that devices will general fall into
two
> categories either fully xPL compliant supporting all options or with
> operate with the core values of the protocol but with a few bits on
the
> edges not being supported. As long as the restriction are clearly
stated
> in the documentation I see no problems.

We can say that xPL devices don't have to support filters and groups, but
I'm afraid that the Configuration really is "core" enough that it
needs be
supported. That being said, it's not that "expensive" in terms of
CODE and
EEPROM space.

Ian.