Re: Re: Message Etiquette

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Gregg Liming wrote:
> Hi Darren,
>
> Quoting darrenp_lock (4/16/07 3:56 PM):
>
>
>> As a side note: are there any plans to introduce schema versions
to
>> allow schemas to evolve over time?
>>
>
> I'll defer to others "in the know".  It would seem more
useful if this
> were the case.  In practice, I see more "embellishment"
(i.e., additions
> or refinements to interpretation) than strict schema control.  There
are
> certain occasions/situations where this leads to considerable
problems.
>
xAP has thus far taken the approach that people can augment existing
schema with their own additional parameters should they wish. Having a
more formal schema 'evolvement/versioning' system is probably desirable
- possibly based around aspects of inheritance  from the existing ones
using the hierarchical Class= naming structure.

I'm interested Gregg in where you have found considerable problems being
introduced by these additional parameters as I haven't heard that
mentioned before at all and I haven't ever experienced it  ??
>
>> :-/As I understand it, I am limited to 254 subaddress IDs,
Yes - currently - however we have widely publicised that we will be
implementing a new expanded UID format in an imminent  minor xAP
revision . The aspect holding this back currently is that users will
obviously require a xAP hub (and Viewer) that will support the new UID
format and those applications are being revised accordingly alongside
updating xFX to .Net 1.2 .  Hub and Viewer are in beta currently and
should again appear 'any day now'.

FYI the new UID format is

UID=NN.AAAA:SS

NN=network number
AA=Application/Device address
SS= Sub address ie endpoints within the device

The above representation obviously reflects the current UID format with
the usage of a '.' and ':' to delimit the various portions of the value
similarly to the source address formatting. The good news is that we are
not restricting the length of any of these fields so NN AA and SS can be
any (even) number of uppercase hex digits.  We will recommend some
formats however. The sub address field is where we are seeing
restrictions currently and I therefore expect people will adopt 4 or
maybe 6 digits here. Some people may choose to use natural unique device
ID's like 1-wire addresses too. As previously values of all 0's and all
F's will be reserved in all fields.  We also intend to allow vendors to
reserve their own unique addresses in the 'AA' address field, rather
like MAC addresses and so I recommend that you not use any values here
that start with F0-FF.  Some likely recommendations are ...

FF remains at two digits
AA contains 4 or 6 (8 digits will likely be used for vendor assigned
addresses in the F0000000 to FFFFFFFE range).
SS contains 2, 4, 6, or possibly 8 digits

The three most common adoptions I expect will all be based around sub
address expansion with the second option being prevalent (SSSS)

UID=NN:AAAA:SS  (as currently used - 254 sub addresses)
UID=NN:AAAA:SSSS   (64K sub addresses)
UID=NN:AAAA:SSSSSS   (possibly - 16M sub addresses)

**************************************************************************************
* Everyone should code their current applications to be compatible with
this new UID format (as well as the old) *
**************************************************************************************


It is rare for device connector type applications to make use of the UID
on receipt so we do not expect this to cause significant issues with
current applications. The applications most likely to need updating are
'protocol enforcing' hubs and bridges, some diagnostic tools like Viewer
etc and in particular controllers / scripting engines.   Also
historically the 'AA' address portion of the address has been abused to
accommodate the lack of sub address space by creating 'virtual'
applications each with their own 254 sub addresses . This will not be
necessary and will be strongly discouraged once the new UID is available.

K