Re: Wildcarding query

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi All,

Interesting to see at least two differing views here David and
illustrates the written spec is obviously open to interpretation and an
area that we have each applied different understandings or
implementation ideas for.

Here is my personal take on how it should work but I know that P and
I have different views on matching 'upto/beyond' the :   This came up a
year or so back but we passed over it so let's try and clarify it now
I took this approach as it seemed to allow any possibility that you
wanted with wildcarding

Firstly..   The ">" matches everything after up to a : or end
of address
if no : is present. "Everything" can also include 'nothing' and
therefore doesn't even require that position in the hierarchy to be
present.  A * however does requires something to be present, and hence a
hierarchy position , it can't be 'nothing'

eg     A.B.>     would match

A.B.C
A.B.C.D.E
A.B         <<<  this is important as otherwise you cant
create a wildcard match construct for this as A.B.* wont work.  (FTTB
ignoring the fact xAP addresses should be at least 3 hierarchies)

A.B.>  would not match   (this is where we maybe differ in view)

A.B.C:D

In order to match this then the wildcard construct would be
A.B.>:>  or   A.B.*.> or A.B.*:* or something, it needs a : in the
wildcard

Hence a wildcard without a : in it will only ever match a main
addresses and a wildcard with a : in it can match everything including
sub address (as the portion after the : could be empty)

So to achieve all three possible match all types we use

Target=> will only ever match main addresses (ones without a sub)
Target=>:> will match everything.
Target=>:*.>  will only match sub addresses as the * may not be empty

I think P is of the view that you would never have two '>' s in a
wildcard though, and I think his applications, libraries and OCX work
this way.

Whilst on the subkect I  also have a differing interpretation on
Target=>:>  and no target being present in the header. My view is
that
in general messages without a target are informational and not
instructional eg 'weather' or 'state' etc. Messages that have a target
in them  , even if that is everything ie target=>:> are intended as
instructional or commands that should be processed by any device whose
address matches.  In my implementations if there is no target= line in a
C-Bus (or BSC) for example command then I do not process it. It is an
early check I do on a packet to decide if it warrants further
inspection. Now I know James for example believes an untargeted packet
and a target=>:> packet should be treated the same.  My simple view
is a
target=>.> says 'please try and process/action this message if you
can'
and for me targetless messages does not carry this meaning, they are
informational.  As we have two scenarios that effectively look the same
it seems sensible to utilise them to different advantage. But my view
could be wrong here. Being able to ignore untargeted messages is very
useful for me, I believe E does this too ?

Lastly re the inclusion of Target=lines  in bodies.   The spec as it
stands says this is allowable. I think it is a powerful feature but it
is very complex and that is why we talked about deprecating it. I don't
know of it being used by any application. But I am always concerned
about losing a feature someone may find a use for so it sits there in
the spec still. We need to clarify perhaps that many (all) existing apps
do not support this (as it is an optional feature) but if someone wanted
or to support it in their app then they could do so. However, as you
know I never liked this complexity, and if it was to go then no problem.

BSC does sort of achieve a simpler version in that there is an ID= value
in the block but this can only be ID=* or ID=XX  where XX is a unique
address Hence it is a specific UID or everything that matches the
wildcard. Indeed if use ID=* it is a lazy way to address and enpoint
without knbowing its UID ;-) .  With BSC therefore you do not encounter
the potentially quite complex  overlap validations that two fully
flexible wildcard constructs could create.

Target=A.B.*.C.*.>:*.>    'AND'  Target= *.B.D:> for example :-(


Kevin