RE: Wildcarding query

["Edward Pearson" <edward.mailgroup@xxxxxxxxxxxxxxxx>]

------=_NextPart_000_0016_01C4E82A.2D70E3A0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

So, according to Patrick the x10 connector is off-spec as I've described it
below because I'm not letting the ':' be equivalent to a '.'.
=20
a.b.*.*.e   or  a.b.c.*.*  or a.b.*.d.* should all match
=20
Using the colon allows
=20
a.>:d.> to be legal
=20
The colon is effectively saying "re-start wildcard matching".
=20
Yes, this could do with rationalising - and some better examples.

-----Original Message-----
From: Edward Pearson [mailto:edward.mailgroup@xxxxxxx]=20
Sent: 22 December 2004 11:51
To: xAP_developer@xxxxxxx
Subject: RE: [xAP_developer] Wildcarding query


Here's my interpretation. I think of the address as two separate parts
separated by a colon.
<device-address>:<sub-address>
=20
I apply wildcarding rules within each part but not 'accross' the colon
=20
Given a device a.b.c:d.e
=20
The device would be targetted by a.b.c or some wildcard like a.*.c or
a.>
=20
You can then target a sub-device within that device by specifying a
sub-address after the colon either specifically
a.b.c:d.e or with a wildcard
a.b.c:d.*
=20
So, what that "last part" is saying is that if you want to target
some
sub-device (or selection of sub-devices via a wildcard) then the colon has
to be present. If it is not there then you can only address whole physical
devices not selections of sub-devices within that.
=20
Yes a.b.*:*.* is a match.
=20
But none of a.b.*.*.e   or  a.b.c.*.*  or a.b.*.d.* are matches because the
colon is not there.
=20
It depends on the implementation as to what messages targetted at the
devic=
e
rather than its sub-devices does. For example, in the X10 connector, all
th=
e
X10 modules appear on some sub-address eg,
ersp.x10.pacific:study.lamps
ersp.x10.pacific:study.uplighter
=20
The address ersp.x10.pacific deals with messages that relate to the
connector as a whole rther than the specifc devices eg, heartbeats come
fro=
m
that address only and theres a command to reset the connector which goes to
that address.
=20
The uplighter (and possibly other devices) is addressed by all of:
=20
ersp.x10.pacific:study.*
ersp.x10.pacific:*.*
ersp.x10.*:*.uplighter
=20
but not by any address with no : in it.
=20
On the topic of targetted bodies and body wildcaring, I believe this is now
depreciated and to be removed from the specification. The BSC spec has a
much better way of sending multiple command bodies rather than using the
target=3D within a body. I'm not aware of any working implementations that
=
use
or rely on target=3D within a body. Keep it in the header.
=20
'>' is the wildcard that matches 'all the rest' of an address, so no,
there
shouldn't be anything else to the right of it in the address (it's like
saying, "and anything else"). I apply this independently each
side of a
colon so to match that uplighter from above
ersp.>:study.> would work (that's the "exact matching
against..." coming
into play again). In my implementation, ersp.x10.> (no colon) doesn't
match
all (or indeed any) of the subaddresses, but this maybe off-spec.

-----Original Message-----
From: David Buckley [mailto:db@xxxxxxx]=20
Sent: 22 December 2004 10:44
To: xAP_developer@xxxxxxx
Subject: [xAP_developer] Wildcarding query



Spec says:

"Unless explicitly specified, the : (colon) sub-address separator is
treated as being synonomous with a . (dot) separator. Exact matching
against a : (colon) is only required in situations where wild card
filtering against just the sub-address element is required."

What does that last bit mean?  When does it apply??

Given a device a.b.c:d.e

a.b.*:*.* would shirley match.  Is this what "explicitly
specified"
means?

But does a.b.c.d.e match it?

How about a.b.*.*.e   or  a.b.c.*.*  or a.b.*.d.*

I'm also a bit hazy on body wilcarding.  In the BSC spec it is clear
that multi-part bodies are permitted (xAPBSC.cmd example), and the xAP
spec says "Any multi-block message [note message not schema] with a
wildcarded header address may optionally include additional target
filter" but the BSC spec makes no mention of body targets.

Is it safe to just generically assume that _any_ body may contain a
target=3D element?

Finally, the '>' character, it is correct that nothing can follow it
in a wildcard specification?=20