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

["Michael McSharry" <mcs101main@xxxxxxx>]

------=_NextPart_000_00B8_01C4B04B.E56FC640
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I understand the multi-section vs. multi-value distinction.  When I
impleme=
nted this awhile back I looked at the schema for Weather and the only
thing=
I found was http://www.xapautomation.org/modules.php?name=3DSections&op=3D=
viewarticle&artid=3D2 so I tried to make-do with what was already
defined a=
nd fit the other pieces of information that I wanted to include.=20=20

My "listener" for this schema does treat each key/value as
individual entit=
ies.  The application built upon the received value does have specialized
i=
ntelligence to split the value and route it to two places  On for display
i=
n an HTML tag and the other for storage in a database.  Had it been
defined=
using multiple sections then the xap parser would have it already split an=
d the application would not need to know about the ";" field
separator.  It=
would just need to know to look for multiple sections which I suspect the =
parser would populate to some arbitrary number of sections.=20=20

The application, however, still needs to know how to use the data as an
ico=
n index for display and as a number for database storage.  When the
applica=
tion is adding value to the data content then it does need to have
knowledg=
e as to what it represents.  Knowledge that it represents 1-day or data vs
=
5-days vs n-days of data is not a big distinction.  An application,
however=
, that expects data to be in some least-common-multple will not want the
en=
coding in the value field.=20=20

In my implementation I build a collection of key/values received in an xap
=
message. The application queries that collection just like it would
request=
Form data from an HTTP message.  I do not have any multi-section xap messa=
ges so I have only a single collection and my applications need to know
abo=
ut this single collection.  In essence the same application logic is used
i=
f a message is received from HTTP/Browser or from UDP/xap.  If I was to go
=
multisection then I would need to propogate section information up to the
a=
pplication.=20=20

I imagine that had I seen the Weather.Forecast schema when I started I
woul=
d have gone down that road.  The distinction of the approach is a good
disc=
ussion topic.

----- Original Message -----=20
From: Kevin Hawkins=20
To: xAP_developer@xxxxxxx=20
Sent: Tuesday, October 12, 2004 5:30 AM
Subject: Re: [xAP_developer] Re: Weather, and a new xAPplication coming o=
n


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)

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

parameter=3Dset1;set2;set3;set4
value=3Dval1;val2;val3;val4

is not a  xAP standard way of accomplishing this... what I'm meaning is=20
that this is your specific interpretation and perhaps we need to look at=
=20
an endorsed way of  achieving something like this.   Maybe even exactly=20
as you propose.  We really don't have such a feature within xAP at the=20
moment so its a a good discussion topic.  (however see my comment later=20
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=20
say that each set of data should be contained within its own block of=20
data within the same single message body - still within one packet and=20
hence there is no bandwidth issue (on UDP anyway) but it does increase=20
the volume of data to parse. This is how the 5 day forecast in James'=20
weather works for example..James also segments weather.report and=20
weather.forecast into two different message types.  However there is an=20
obvious duplication of data and on slow speed links this is=20
undesireable.  (quite in practice how many of these there are remains to=
=20
be seen - I suspect very few).  The advantage is that from a parsing=20
perspective each set of data is presented as one unit (one block) and=20
hence works with existing applications very easily , perhpas even=20
transparently. The coding is much easier.

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

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

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

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

At the moment the only official way is to break this into mutiple bodies=
=20
(or define your own schema as Michael has done) - what do people think -=
=20
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=20
schema as above would  be adopting the standard Class=3DWeather.report=20
schema but with added parameters that are specific to the mcs=20
enhancements for weather.report.      An alternative is James' way of a=20
separate weather.forecast message with mutiple message bodies for each=20
group of data .  I think it might be sensible to add a date / time field=
=20
to these blocks as well rather than just a name.

xap-header
{
v=3D12
hop=3D1
uid=3DFF400100
class=3DWeather.Forecast
source=3Dmi4.weather.egnm
}
Forecast.Day1
{
mintempc=3D11
icon=3Dovercast
windspeedk=3D9
maxtempc=3D16
windspeedm=3D6
maxtempf=3D60
day=3DTuesday
mintempf=3D51
winddir=3DSE
}
Forecast.Day2
{
mintempc=3D9
icon=3Dlight_rain
windspeedk=3D14
maxtempc=3D14
windspeedm=3D9
maxtempf=3D57
day=3DWednesday
mintempf=3D48
winddir=3DS
}
Forecast.Day3
{
...etc

Michael McSharry wrote:

> This capture is for English units.
>
> xap-header
> {
>     v=3D12
>     hop=3D1
>     uid=3DFF001700
>     class=3DWeather.Report
>     source=3Dmcs.WeatherXML.MCS5
> }
> Weather.Report
> {
>     humidity=3D84
>     uvindex=3D0
>     feelf=3D65
>     tempf=3D65
>     forecastday=3D30;39;12;30;30;11
>     icon=3D28
>     windm=3D4
>     forecastdate=3D2004-06-11 0:00;2004-06-12 0:00;2004-06-13=20
> 0:00;2004-06-14 0:00;2004-06-15 0:00;2004-06-16 0:00
>     date=3D
>     localtime=3D22:00
>     visibilitym=3D999
>     cloud=3DMostly Cloudy
>     city=3D
>     country=3D
>     utc=3D5:00
>     forecastlowtempf=3D66;58;56;56;58;58
>     forecastprecipitation=3D20;50;70;30;10;60
>     forecastnight=3D47;11;11;29;45;11
>     winddirc=3DSE
>     winddird=3DSE
>     airpressurei=3D29.53
>     forecasthightempf=3D81;75;68;73;78;76
> }
>=20=20
>=20=20