Re: Context parameters within Message Bodies

[mark_harrison_uk2]

Kevin,

The key point to me is the phrase "if a human reads it".

xAP is sophisticated - it is not a "plug and play" where new
devices
can simply be added and the rest of the house will in some way know
how to respond.

A xAP installation requires an INSTALLER. Whether this will be a
professional installer or a hobbyist is irrelevant.

It is part of the role of that installer to understand the
classes/schemas that will exist, and ensure that their content is
interpreted meaningfully by other devices within the xAP realm.

To facilitate this, I think that the next thing that xAP needs is
some rules-based language (xAPScript?) to hold state, and then work
out what needs to be done. Obviously, hand in hand with this is a
central controller... but this central controller is an interim step.
In the longer term, there will be a xAPScript COMPILER that is able
to push out the intelligence to end devices. At present, these
intelligent end devices don't exist, and the existing end devices are
fairly simple... but one of the cornerstones of xAP is that the work
WAS put into the 1.2 protocol design to allow massively parallel
architectures.

For example, imagine a simple xAP installation comprising of:

- A TiVo used as an output device
- A Meteor connector
- A POP3 connector
- A "controller"

The TiVo would display

EITHER
- nothing
OR
- the subject and sender of a new message
OR
- the phone number and name of a caller

There are two architectural possibilities here:

1: The xAP-TiVo software decides which to display, based on rules
encoded within in.

2: The central controller receives all the xAP messages, then sends
out a basic "xAPdisplay message" on which the TiVo acts.

At present, number 2 is probably where most people are...

Regards,

Mark

--- In <a
href="/group/xAP_developer/post?postID=EkGgwpWwpvWkjKiIRo8XDs2RTjgc4wnRh3e6KpoPAlvTsajVpXk3t4t6dg-fsoJbWdzYmUnzMZ6g85SifsHFKtwNOpCSKRGX">xAP_developer@xxxxxxx</a>,
"Kevin Hawkins" <lists@u...>
wrote:
> ...
> 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" ...