Re: Context parameters within Message Bodies

[Stuart Booth]

On Sun, 30 Nov 2003 02:38:57 -0000, "Kevin Hawkins"
<<a
href="/group/xAP_developer/post?postID=GT-SBWsHbMKlhm978uxMZJH2CHrkEvZj2HMm7EGRzmbjBsyUvCAN2nHCk3QyK7f_2zp3nsaWpQcC5aWSbB2UgA8">lists@u...</a>>
wrote:

>showing.now.1
>{
>Channel=BBC1
>Program=A Question of Sport
>Duration=40
>}
>showing.now.2
>{
>Channel=C5
>Program=Boxing: Fight of the week
>Duration=65
>}
>
> (I think we agreed we would index duplicate section names ??)

Yup. James had a compelling argument for that, although I think it was
more of a recommendation. Must admit my framework has this turned off
by default. Maybe I should enable it by default. Certainly in all
schema I work on I fully intend indexing them.

> First of all I think it is very important to try and make use of
hardware
>subs and UID's as much as possible. Taking the TV listings example the
>message should become two separate messages based on the channel
>
>....
>UID=FF122201
>Source=ACME.TV.listings:BBC1
>}
>showing.now
>{
>Program=A Question of Sport
>Duration=40
>}

Got to say here that I really like that! Since you and James sold me
on the use of hardware subaddresses I've been quite taken with this
setup. TiVo is another example where it could be used where multiple
devices exist. Or Xbox even. It certainly works fantastically well for
SliMP3's.

>Note now that the subs define the channel and the data within the one
xAP
>message relates to that one channel. Multiple bodies ... Well
>
>....
>UID=FF122201
>Source=ACME.TV.listings:BBC1
>}
>showing.now
>{
>Program=A Question of Sport
>Duration=40
>}
>Showing.next
>{
>Program=Top of the Pops
>Duration=60
>}
>
> The context of the bodies stays as BBC1 throughout the message
>
>Does this mean though that identical body sections can never occur - as
the
>context of the data must be set within the body itself if they did ???

Perhaps a message should be self contained? All the blocks that make
it up are related/grouped, or highly cohesive if you like. Separate
issues, or data units, go in separate messages. Otherwise you might as
well pack as many blocks into the one packet as you can?

I recall that multi-part messages has been discussed before, but
keeping a single message as complete in itself would be preferable.

>Consider a favourite body section that lists any fovourites n today and
the
>time they air
>
>Favourite
>{
>Program=Friday Night with Jonathon Ross
>Time=0200
>}
>Favourite
>{
>Program=Eastenders
>Time=1455
>}
>
> ...... The context is right in that they are both BBC1 but now some
>context is again supplemented within the body..

That's a nice example of a good reason for multiple blocks in the
body.

> So how about

>Favourites
>{
>Fav01=Friday Night with Jonathon Ross
>Time01=0200
>Fav02=Eastenders
>Time02=1455
>}
> awkward but better ......

How is that one better, Kevin? Doesn't it mean you have to search out
Time05 when doing something Fav05? I prefer the multiple block
approach as each unit is distinct and complete. And easily read in
code too.

I think that the former layout means you deal with a tight group of
data, then move onto the next, rather than keeping track of all
possible items? Especially when some people mess the order around
(that's me, folks!).

>Temp.report.2
>{
>Sensor=hall
>Value=minimum
>Temp=15
>Time=0630
>}
>
>Source=acme.tempsensor.main:hall
>}
>{
>Minimum=15
>Time=0630
>}
>
> Here we have taken context in the body out by naming the parameter
>minimum - and there will be a maximum parameter too. This is definitely
to
>be done wherever possible I feel. Try and avoid parameters that set
context
>within a body section.

I need to go modify the CID schema I suggested. I think I do it the
old way with a fixed pair name and a variable (read: enumerated type
so it has a fixed range of values) value part.

I actually opened up your Basic Status/Control document as a lot of
this reminded me of it, such as the hardware subaddress value (01 -
FF):

{
01=15
Time=0630
}

In fact there seems to be a large amount of overlap here.

> It crops up in some very simple scenarios
>
>X10.status
>{
>Device=A10
>State=ON
>}
> I feel we need to avoid this sort of thing if possible - it's
>awkward to pick the values up in a program that is trying to track
state
>like HomeSeer for example.

So in this case you'd go with the following?

X10.status
{
A10=ON
}

I like this a lot actually, although you mentioned in your BS/C
document (Basic Status/Control I mean!) how awkward multiple
subaddresses becomes for

{
Light=Lounge.TableLamp
Command=ON
}

Or...

{
Lounge.TableLamp=On
}

>Status
>{
> server=pop.ukusa.co.uk
> total=1
> username=kevin
>}
>Status
>{
> server=pop.ukusa.co.uk
> total=3
> username=webmaster
>}

>Now If I want to know how many emails for <a
href="/group/xAP_developer/post?postID=6lBEPNaMejXjmBZ_ZEdfopUXPqm57WuUFh-h2j_vNNePUmw1b1Dk-kIWPOs3ulVrKdPwJ6SVQKJ7j9Q">kevin@u...</a>
I have to check
>for a mail.waiting schema with a body of status and a parameter of
>server=pop.ukusa.co.uk AND a username=kevin and recover the total=
parameter
>- it's very awkward and even worse to establish the context
programatically.

Ah, okay, I understand now! ;-)

>How could this be done ?? Well firstly we could add hardware subs - and
>manage the UID's accordingly
>
>xap-header
>{
> v=12
> hop=1
> uid=FF04E200
> class=Mail.waiting
> source=acme.mail.machine:ukusa
>}
>Status
>{
> total=3
> username=webmaster
>}
>Status
>{
> total=1
> username=kevin
>}

This is nice. I like the multiple bodies. I could go do this now in
fact... but maybe not.

However, I'm worried about the 'hardware' subaddress as that isn't
something we can always so readily control the value of. It could be
somewhat awkward.

What would we do if I had xAPFramework.net and xAPFramework.me.uk?
Does the subaddress become "xapframework.me.uk" in the latter
case,
with all its sub-subinstances? Taking the top (?) level, xAPFramework,
alone isn't unique enough.

Does the schema dictate the addressing mechanism, such as converting
.'s to _'s perhaps, and back again:

source=acme.mail.machine:xapframework_me_uk

>But we still have the username context within the body - how would we
>resolve this ? We need somehow to know that username is a 'context'
>parameter - so we could choose to identify it as such eg

>Status
>{
> Total=1
> +username=kevin
>} OR
>Status
>{
> Total=1
> username><kevin
>} OR
>*username OR username~kevin or some such identifier but I feel his is
not
>really 'xAPlike'

Yuck! Sorry!! It loses the distinction between ASCII and binary data
too, unless you start doubling up UserName=~Kevin, but this also loses
potentially valid characters from the variable part, causing
unexpected problems.

>Status.kevin
>{
> Total=1
>}
>Status.webmaster
>{
> Total=3
>}
>
>Or even
>
>Status:kevin )but I don like this really

Me neither. That feels like data creeping out of the block into the
block name where I don't believe it belongs. The indexing is a
slightly different mechanism but then again who is to say the 'index'
needs to be numeric and cannot be alphanumeric??? Ie "kevin" or
"webmaster".

But to assemble this data into something I can use to do something,
such as a display output, I have to assemble the data from outside the
block contents, and I have to handle block names differently by
fetching data from them. This would be reasonably unusual perhaps??

>Lastly should the hardware sub hierarchy come into play here
>
>source=acme.mail.machine:ukusa.kevin
>source=acme.mail.machine:ukusa.webmaster
>
> seems to make sense but it significantly reduces the usage for
>multiple bodies - but is that a bad thing ?? Multiple bodies would in
such a
>scenario invariably contain different section types.

In this case what happens when the two context parameters are much,
much larger? How do we handle unwanted characters in the context
stream? In this email example alone we could have @'s and .'s to deal
with for instance, although @'s don't (yet) have any special
significance in xAP.

We might compress the subaddresses to distinctive yet unique
signatures, or aliases, and still include the full value in the
message block somewhere:

source=acme.mail.machine:xFxNET.Stuart

Status
{
<a
href="/group/xAP_developer/post?postID=4F8RAppVu3flfZmZru676CxTECpxEzbLFdgeRFf4QzXS6AhtLjsXuNuqBATeL66sl7qvG5mj5cu1OoE44_9VHJg9-v8YFb7LLCmF">UserName=stuart@x...</a>
Server=mail.xAPFramework.net
Total=2
}

Or the xAP devices are built with knowledge that xFxNET means
xAPFramework.net and they can expand as required. Which introduces
another step unfortunately.

In the above example there's the context (xFxNET and Stuart) and the
useable values (in the block), making them distinct from each other.

>Status.information
>{
>Height=1000
>Colour=red
>Length=20
>Value=40
>Direction=west
>}
>
> It is now ambigous even to a human which are context parameters and
>which are values - maybe 'value' is the only true data here and all the
>other 4 provide context - or maybe they are all data for 'RED' .

Perhaps context parameters should be recommended/limited to just the
one? I wasn't even sure that the username was appropriate in the email
example but I can see where you're coming from I think.

Are we attempting to move too much out of the blocks here?

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=XqAj1Gy1i9E_PyUOfg56-WHWHDuzZR7VgeuEuj0-RE0q72w7-VFbLZ5Q7bRVLPY8t-AAHC_07ZewrEV6yYU7sA">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>