Context parameters within Message Bodies

[Kevin Hawkins]

Hi All,

Sorry turned out long again but please read his....

As xAP has encompassed some more complex devices and data sources an
interesting issue has cropped up in the way data is presented in xAP
packets
. This becomes particularly true for software sources like news feeds,
weather reports, email applications, stock ticker feeds etc. Let me take as
an example a TV listings application..

...
UID=FF122200
Source=ACME.TV.listings
}
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 ??)

Here's the snag - the "Program=" data in the first body part
relates to BBC1
and in the second body part to C5. There is a 'context' set by the
inclusion of the Channel= that relates to the other parameters. Now when a
human reads this it is easy to understand that Channel= sets the context
but
how would a computer know - it could think duration= set the context. To
readily pick up what program is on say BBC1 now requires logic to be
applied
- "Is channel=BBC1 if so then read Program= from the same body
section" ...

A worse example

temp.report.1
{
Sensor=lounge
Value=maximum
Temp=23
Time=2048
}
Temp.report.2
{
Sensor=hall
Value=minimum
Temp=15
Time=0630
}

Now two parameters set the context "Maximum AND Lounge" and in
the second
body "Minimum AND Hall" - although you as a human can interpret
this, it is
impossible to pick this up reliably in software. 'Sensor' and 'Value' are
context parameters but 'temp' and 'time' are values. Also if you want to
pick the maximum temp up for the hall you need to read each message body
and
check 'maximum' nad 'hall' exist and only if that is true you extract temp
from that body.

So what are the solutions ?? Here's some thoughts - but this is a question
not a how to !

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
}

.....
UID=FF122205
Source=ACME.TV.listings:C5
BBC1showing.now.2
}
showing.now
{
Program=Boxing: Fight of the week
Duration=65
}

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 ???

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.. So how about



Favourites
{
Fav01=Friday Night with Jonathon Ross
Time01=0200
Fav02=Eastenders
Time02=1455
}



awkward but better ......

Thoughts ???


Taking the latter example (repeated in part here)


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.

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.

Again Thoughts ???




Lastly - and I'm only using this because it's a great example that amply
demonstrates the complexities of context here - plus it's only when I came
to try and recover how many emails for <a
href="/group/xAP_developer/post?postID=Ahn5QkxUh6_UnoM3aIPw9KMXtcwUmCV7O-vFdr39qpRUBKybGoEB2f6T0dnRrNOW8pIehfu5JD47BNoN">kevin@u...</a>
that I realised the
problem - take a look at the following three sample messages from ACME's
email program


.....some identities have been changed to protect the innocent ;-)


xap-header
{
v=12
hop=1
uid=FF04E200
class=Mail.waiting
source=acme.mail.machine
}
Status
{
server=pop3.demon.co.uk
total=2
username=kevin
}

xap-header
{
v=12
hop=1
uid=FF04E200
class=Mail.waiting
source=acme.mail.machine
}
Status
{
server=pop.ukusa.co.uk
total=1
username=kevin
}

xap-header
{
v=12
hop=1
uid=FF04E200
class=Mail.waiting
source=acme.mail.machine
}
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=Ahn5QkxUh6_UnoM3aIPw9KMXtcwUmCV7O-vFdr39qpRUBKybGoEB2f6T0dnRrNOW8pIehfu5JD47BNoN">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.

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
}


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'

Another alternative

Status.kevin
{
Total=1
}
Status.webmaster
{
Total=3
}

Or even

Status:kevin )but I don like this really

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.


I hope I have conveyed the difficulties that this context with body
sections creates when you are trying to get a controller application to
makes sense of data. True we can define which parameters are context
parameters in the schema definition but the controllers would need access t
the schemas - and very capable rules engines.

look at this for an example



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' .


Needs some thought.... Please wade in


Kevin