Re: Re: Weather, and a new xAPplication coming on

["Michael McSharry" <mcs101main@xxxxxxx>]

------=_NextPart_000_00CC_01C4B060.593F82E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The Weather.Report schema does not have any context dependencies as I
under=
stand from this discussion.  The content of each value is only with
respect=
to its associated key.  There is no dependency between keys in the schema.=
The forecast date key provides a list of 5 dates.  The forecast icon prov=
ides a list of 5 icons.  There is no relationship between the date and
icon=
implied.  What is implied, however, is that there are 5 individual dates o=
r icons associated with their respective key and these are contiguous.  It
=
may be 6 entries, as in the case or WeatherXML or 5 in the case of
WeatherM=
SNBC but each is only relative as day 1, day 2, etc.  This is the same as
t=
he section of Weather.Forecast being Forecast.Day1, Forecast.Day2, etc.

With respect to X10, I do use use multiple device on the same house code
in=
the same transmission.  I never use multiple house codes.  If I want to tu=
rn on my two garage lights together I use D13, D14.  (D13+14 in raw X10). 
=
I never turn on garage light and hall light together (D13, F7).  I
organize=
d by device codes so functional areas would be on the same house code so I
=
could take advantage of optimizations provided by the X10 protocol.  When
a=
bstracted to a more generalize xap schema then there is no rationale to
inc=
lude multiple devices in the same message except in the case where a
hardwa=
re/protocol optimization can be accomplished.  That is why it made more
sen=
se to me to have the X10 schema support the D13+14 rather than what is
curr=
ently defined.

This example also points out that we do have another case where multiple
se=
ctions could/should be used per the xap designers' intent so each command
w=
ould be in its own section and include only 1 device.  The application
that=
feeds the data into the xap message will know it wants two devices to be e=
ngaged.  If it gets mapped into one section with two commands of two
sectio=
ns with one command each is transparent to the application to xap-parser
in=
terface.  At the receiving end/connector the decomposition of the message
h=
as the same complexity either way.
----- Original Message -----=20
From: David Buckley=20
To: xAP_developer@xxxxxxx=20
Sent: Tuesday, October 12, 2004 1:00 PM
Subject: [xAP_developer] Re: Weather, and a new xAPplication coming on



--- In xAP_developer@xxxxxxx, Kevin Hawkins <lists@u...> wrote:
> HI - Looking forward to seeing this - ( I think we spoke about this=20
> almost a year ago but lost touch so I'm glad it's materialised)

err - Kevin - It wasn't me you discussed this with :-)

> One concern I have is that we are again seeing the issue where=20
> one paramater  (in the below example the forecastdate) is acting=20
> as a key value defining the CONTEXT for all the other=20
> collective data. However from just  examining the message it is=20
> not possible to ascertain which parameter(s) set the CONTEXT
> and which contain the related DATA . A human can interprest=20
> these often but not a parser.=20=20

This is a valid general concern.  You are correct, parsers are syntax
directed tools, and once you have context you are into semantics.=20
generally, parsers dont do semantics at all well.

> Also I am concerned by the complexity  of parsing such a message=20
> as it requires many iterations through a single block

Oh no - you should never multiply parse the message.  What you have to
do is store the contents of the message as you parse it - once, and
all the way through to the syntax-error free end - in some local
format.  This isnt unique to the Weather.Report schema - even the
humble X10 schema suffers from this.=20=20

device=3DA1,A2,B1,B2

easy. generate A,1,2,command,B,1,2,command

device=3DA1,B2,A2,B1

on-the-fly - A,1,command,B,2,command,A,2,command,B,1,command

Try and do this on-the-fly and you are stuffed.  You are required by
the schema notes to (sensibly) command devices as housecode sets, but
there is no requirement that the devices are in housecode order.=20
Unless you parse the entire thing and then act upon it, your code will
never underand that there are two sets required, not four.

Does anyone (apart from the connectors) actually generate multiple X10
devices?=20