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

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

HI - Looking forward to seeing this - ( I think we spoke about this
almost a year ago but lost touch so I'm glad it's materialised)

I just have a comment on the schema below (end of message) Michael as I
didnt want to mislead anyone new to xAP - It is to do with the way the
consecutive days data has been added into one message block,   The
mechanism of

parameter=set1;set2;set3;set4
value=val1;val2;val3;val4

is not a  xAP standard way of accomplishing this... what I'm meaning is
that this is your specific interpretation and perhaps we need to look at
an endorsed way of  achieving something like this.   Maybe even exactly
as you propose.  We really don't have such a feature within xAP at the
moment so its a a good discussion topic.  (however see my comment later
if this is not a generalised way you are using to group collective data)

Within the existing spec the way to accomplish this would  have been to
say that each set of data should be contained within its own block of
data within the same single message body - still within one packet and
hence there is no bandwidth issue (on UDP anyway) but it does increase
the volume of data to parse. This is how the 5 day forecast in James'
weather works for example..James also segments weather.report and
weather.forecast into two different message types.  However there is an
obvious duplication of data and on slow speed links this is
undesireable.  (quite in practice how many of these there are remains to
be seen - I suspect very few).  The advantage is that from a parsing
perspective each set of data is presented as one unit (one block) and
hence works with existing applications very easily , perhpas even
transparently. The coding is much easier.

So Q..Do we need  a mechanism similar to the one you have used to form
collections of data - in an efficient manner.??

One concern I have is that we are again seeing the issue where one
paramater  (in the below example the forecastdate) is acting as a key
value defining the CONTEXT for all the other collective data. However
from just  examining the message it is not possible to ascertain which
parameter(s) set the CONTEXT  and which contain the related DATA . A
human can interprest these often but not a parser.  It is necessary to
have some external knowledge of the schema to know this.   I think there
should be a way of identifying a parameter as such a CONTEXT value just
from examining the message .  There have been a few 'specification
working group' suggestions to address this ( a very contentious topic
for me ) that as yet have not been ratified.  Bear in mind that the
order of paramaters within a schema is random and indeed they even get
re-ordered sometimes by hubs etc.

Also I am concerned by the complexity  of parsing such a message  as it
requires many iterations through a  single block - and creates scope for
errors with associated rules for handling such inconsistencies. For
example if there should be 6 values but on one line there were only 5.
My biggest concern is that it also removes the ; as being an allowable
character

Now I guess you're going to say that in actuality the value of say  "
forecastlowtempf "  in the schema below is " 66;58;56;56;58;58
"  and it
is only the schema interpretation of the data that breaks this into 6
different associated values with the date field.  As this is your 'mcs'
schema adaption of  course you're free to construct and use whatever
interpretation of data you wish and this is fine but I see this as a
frequent need within schemas so I was thinking we should address it in a
standard way such that xAP listening applications that are created to
accept a certain schema eg weather.report  would automatically be able
to receive a collection of data using such a schema.

At the moment the only official way is to break this into mutiple bodies
(or define your own schema as Michael has done) - what do people think -
do we need a way of grouping collective data or is what we have adequate.
??

Kevin

PS David - perhaps to clarify this I am saying that implementing the
schema as above would  be adopting the standard Class=Weather.report
schema but with added parameters that are specific to the mcs
enhancements for weather.report.      An alternative is James' way of a
separate weather.forecast message with mutiple message bodies for each
group of data .  I think it might be sensible to add a date / time field
to these blocks as well rather than just a name.

xap-header
{
v=12
hop=1
uid=FF400100
class=Weather.Forecast
source=mi4.weather.egnm
}
Forecast.Day1
{
mintempc=11
icon=overcast
windspeedk=9
maxtempc=16
windspeedm=6
maxtempf=60
day=Tuesday
mintempf=51
winddir=SE
}
Forecast.Day2
{
mintempc=9
icon=light_rain
windspeedk=14
maxtempc=14
windspeedm=9
maxtempf=57
day=Wednesday
mintempf=48
winddir=S
}
Forecast.Day3
{
...etc

Michael McSharry wrote:

> This capture is for English units.
>
> xap-header
> {
>     v=12
>     hop=1
>     uid=FF001700
>     class=Weather.Report
>     source=mcs.WeatherXML.MCS5
> }
> Weather.Report
> {
>     humidity=84
>     uvindex=0
>     feelf=65
>     tempf=65
>     forecastday=30;39;12;30;30;11
>     icon=28
>     windm=4
>     forecastdate=2004-06-11 0:00;2004-06-12 0:00;2004-06-13
> 0:00;2004-06-14 0:00;2004-06-15 0:00;2004-06-16 0:00
>     date=
>     localtime=22:00
>     visibilitym=999
>     cloud=Mostly Cloudy
>     city=
>     country=
>     utc=5:00
>     forecastlowtempf=66;58;56;56;58;58
>     forecastprecipitation=20;50;70;30;10;60
>     forecastnight=47;11;11;29;45;11
>     winddirc=SE
>     winddird=SE
>     airpressurei=29.53
>     forecasthightempf=81;75;68;73;78;76
> }
>
>