The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Current wildcarding usage (and a strong recommendation to support target=> in BSC 1.3)


  • Subject: Current wildcarding usage (and a strong recommendation to support target=> in BSC 1.3)
  • From: Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 29 Jul 2005 13:04:05 +0100

--------------000503070107050106070909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Whilst I was re-reading the BSC spec I came across the following line.....

"*However, all devices must respond to the wildcard address
*.*.>*"   -
following later discussions on the practicalities of wildcarding this
probably could do with some clarification. This wildcard construct
addresses your main application or device as a whole (ie the main
address without any subaddresses).  You should actually also implement
*>* as well.     This line was really intended for applications not
supporting full wildcarding. If you do support wildcarding then it
should all work anyway ;-)

Source= <main address>:<subaddress>

Let's use as example a device as follows with one input and two outputs

1)  FF123400     ACME.SAMPLE.CONTROLLER
2)  FF123401     ACME.SAMPLE.CONTROLLER:SWITCH.OUTPUT
3)  FF123402     ACME.SAMPLE.CONTROLLER:SWITCH.INPUT
4)  FF123403     ACME.SAMPLE.CONTROLLER:INDICATOR

and a couple of other addresses on your network

5) FF234500      ACME.Heating.SYSTEM.UPSTAIRS
6) FF234600      ACME.Heating.SYSTEM.DOWNSTAIRS
7) FF234601      ACME.Heating.SYSTEM.DOWNSTAIRS:INDICATOR


>:>   matches 1,2,3,4,5,6,7  <ie everything>
> matches  1,5,6   (ie all main applications/devices)
>:*.> matches 2,3,4,7  (ie all sub addresses)

The above three are  the recommendations for addressing all devices out
there of a particular category .. the next construct was also commonly
used in xAP 1.2 (before sub addressing)  and should be supported too. It
is equivalent to >
..
*.*.> matches  1,5,6   (ie all main applications/devices, as in the BSC
spec document )

Some more examples..

*.*.*.* matches 5,6  (this construct means there must be exactly 4
levels present in the main address)
*.*.*.> matches 1,5,6  (this construct means there must be at least 3
levels present but more are ok)
*.>:*    matches 4 and 7 only  (devices with 1 level of sub address)
>:*.* matches 2 and 3 only (devices with exactly 2 levels of sub
address)

Note the big difference here is the ':' and it's now inclusion in the
wildcard filter. The : provides a limit to how far the wildcard can
match so effectively there are two wildcard constructs , one applying to
the main address and one to the sub address.  A * requires a value be
present and a > does not but matches everything following (up to the :
if it is applied before that).  Some older applications and libraries do
not apply wilcarding in this way (often they treat . and : as identical)
but practical usage of wildcards has shown that the above usage allows
all combinations of addresses and sub addresses to be wildcarded
correctly and offers the greatest flexibility.

Moving back to the BSC spec therefore you should recognise *.*.>  and
also >  as addressing your BSC implementation.  This is the minimum for
an "address all" address.  Actually technically *.>  and
*.*.*.> should
also be supported but are rarely used, for completeness please support
it if possible.  Note this only addresses the main application and no
sub addresses (endpoints).  Also note that if you support wildcards
fully within your application then all of these should work anyway  and
don't need specific individual recognition.

Kevin


--------------000503070107050106070909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">


Whilst I was re-reading the BSC spec I came across the following
line.....<br>
<br>
"<b>However, all devices must respond to the wildcard address
*.*.&gt;</b>"&nbsp;&nbsp;
- following later discussions on the practicalities of wildcarding this
probably could do
with some clarification. This wildcard construct addresses your main
application or device as a whole (ie the main address without any
subaddresses).&nbsp; You should actually also implement
<b>&gt;</b> as
well.&nbsp;&nbsp;&nbsp;&nbsp; This line was really intended
for applications not supporting
full wildcarding. If you do support wildcarding then it should all work
anyway ;-)<br>
<br>
Source= &lt;main address&gt;:&lt;subaddress&gt;<br>
<br>
Let's use as example a device as follows with one input
and two outputs<br>
<br>
1)&nbsp; FF123400&nbsp;&nbsp; &nbsp;
ACME.SAMPLE.CONTROLLER<br>
2)&nbsp; FF123401&nbsp;&nbsp;&nbsp;&nbsp;
ACME.SAMPLE.CONTROLLER:SWITCH.OUTPUT<br>
3)&nbsp; FF123402&nbsp;&nbsp;&nbsp;&nbsp;
ACME.SAMPLE.CONTROLLER:SWITCH.INPUT<br>
4)&nbsp; FF123403&nbsp;&nbsp;&nbsp;&nbsp;
ACME.SAMPLE.CONTROLLER:INDICATOR<br>
<br>
and a couple of other addresses on your network <br>
<br>
5) FF234500&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACME.Heating.SYSTEM.UPSTAIRS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
6) FF234600&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACME.Heating.SYSTEM.DOWNSTAIRS<br>
7) FF234601&nbsp;&nbsp;&nbsp; &nbsp;
ACME.Heating.SYSTEM.DOWNSTAIRS:INDICATOR<br>
<br>
<br>
&gt;:&gt;&nbsp;&nbsp; matches 1,2,3,4,5,6,7&nbsp;
&lt;ie everything&gt;<br>
&gt; matches&nbsp; 1,5,6&nbsp;&nbsp; (ie all main
applications/devices)<br>
&gt;:*.&gt; matches 2,3,4,7&nbsp; (ie all sub
addresses)<br>
<br>
The above three are&nbsp; the recommendations for addressing all
devices out
there of a particular category .. the next construct was also commonly
used in xAP 1.2 (before sub addressing)&nbsp; and should be supported
too.
It is equivalent to &gt;<br>
..<br>
*.*.&gt; matches&nbsp; 1,5,6&nbsp;&nbsp; (ie all main
applications/devices, as in the
BSC spec document )<br>
<br>
Some more examples..<br>
<br>
*.*.*.* matches 5,6&nbsp; (this construct means there must be exactly 4
levels present in the main address)<br>
*.*.*.&gt; matches 1,5,6&nbsp; (this construct means there must be
at least
3 levels present but more are ok)<br>
*.&gt;:*&nbsp;&nbsp;&nbsp; matches 4 and 7 only&nbsp;
(devices with 1 level of sub address)<br>
&gt;:*.* matches 2 and 3 only (devices with exactly 2 levels of sub
address)<br>
<br>
&nbsp;&nbsp; Note the big difference here is the ':' and it's now
inclusion in
the wildcard filter. The : provides a limit to how far the wildcard can
match so effectively there are two wildcard constructs , one applying
to the main address and one to the sub address.&nbsp; A * requires a
value
be present and a &gt; does not but matches everything following (up to
the : if it is applied before that).&nbsp; Some older applications and
libraries do not apply wilcarding in this way (often they treat . and :
as identical) but practical usage of wildcards has shown that the above
usage allows all combinations of addresses and sub addresses to be
wildcarded correctly and offers the greatest flexibility.<br>
<br>
&nbsp;&nbsp; Moving back to the BSC spec therefore you should
recognise *.*.&gt;&nbsp;
and also &gt;&nbsp; as addressing your BSC
implementation.&nbsp; This is the
minimum for an "address all" address.&nbsp; Actually
technically *.&gt;&nbsp; and
*.*.*.&gt; should also be supported but are rarely used, for
completeness please support it if possible.&nbsp; Note this only
addresses
the main application and no sub addresses (endpoints).&nbsp; Also note
that
if you support wildcards fully within your application then all of
these should work anyway&nbsp; and don't need specific individual
recognition.<br>
<br>
&nbsp; Kevin<br>
<br>



<!-- **begin egp html banner** -->

<br><br>
<div style="width:500px; text-align:right; margin-bottom:1px;
color:#909090;">
<tt>SPONSORED LINKS</tt>
</div>
<table bgcolor=#e0ecee cellspacing="13"
cellpadding="0" width=500px>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Computer+internet&w1=Computer+internet&w2=Developer&c=2&s=38&.sig=5bbJZdfg001HQCSSbY5zIg";>Computer
internet</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Developer&w1=Computer+internet&w2=Developer&c=2&s=38&.sig=ydixObfEijpILo5U-6NkdQ";>Developer</a></tt>
</td>
</tr>
</table>

<!-- **end egp html banner** -->



<!-- **begin egp html banner** -->

<br>
<div style="text-align:center; color:#909090;
width:500px;">
<hr style="border-bottom:1px; width:500px;
text-align:left;">
<tt>YAHOO! GROUPS LINKS</tt>
</div>
<br>
<ul>
<tt><li type=square>&nbsp;Visit your group "<a
href="http://groups.yahoo.com/group/xAP_developer";>xAP_developer</a>"
on the web.<br>&nbsp;</tt>
<tt><li type=square>&nbsp;To unsubscribe from this group,
send an email to:<br>&nbsp;<a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>xAP_developer-unsubscribe@xxxxxxx</a><br>&nbsp;</tt>
<tt><li type=square>&nbsp;Your use of Yahoo! Groups is
subject to the <a href="http://docs.yahoo.com/info/terms/";>Yahoo!
Terms of Service</a>.</tt>
</ul>
<br>
<div style="text-align:center; color:#909090;
width:500px;">
<hr style="border-bottom:1px; width:500px;
text-align:left;">
</div>
</br>

<!-- **end egp html banner** -->


</body>
</html>

--------------000503070107050106070909--



xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.