Re: xAP Schema

[Patrick Lidstone]

> 1. I like the idea of removing the Reason No <Name  Number> from
mine
> and merging that information into the Phone or Name line.

You can't do this sensibly because they're combinatorial.
You can (theoretically) have e.g. INTERNATIONAL + WITHHELD etc.

> 2. Patrick uses "CallType" and I shortened this field to
"Type". I
> figure that the "Call" bit is implicit in the message being
a
CallerID
> event, so why not omit it? The shorter the messages are the better.

Not bothered either way.

> 3. We have different values for CallType/Type. Which are correct? I
> pulled my values from the Meteor documentation way back when I first
> wrote the code.

I need to check the BT SIN to find out what the right answer is. Data
is definitely a valid value for call type field, and I'm pretty sure
your message waiting flag is too. I have a feeling ringback might be
indicated by the Name field?

> 4. Patrick uses TimeStamp which matches the incoming CID
information.
> I changed mine to a 'standard' DateTime value using the notation
that
> Gerry Duprey suggested a while ago. I think that if all time/date
> stamps use this one format then a larger variety of
formatting/parsing
> code is eliminated from a lot (if not all) xAP applications.

The issue here is that a dumb xAP interface to a meteor box will not
have a real time clock to be able to append the year or seconds
field. I'd much prefer to leave this as it is, given that it is odd
anyway. If you want to reorder it to make it look more like a Duprey
format, that's ok by me - but we shouldn't assume that supplementary
information about time of day is available outside of the caller id
box.

> 5. I don't bother with the Text line as I feel that that is a job
for
> another item on the xAP network.

Make it optional then :-) I use this all over the place, and it's
very handy. Most of my apps generate some kind of human readable
summary as a friendly gesture.

> 6. Patrick's Number field includes International or Payphone. This
is
> duplicated in the Name field I believe, which would seem to make it
> redundant, increasing the size of the message, but removing the need
> for a low-end device having to check both fields.

This was a deliberate design decision. It means a display device can
always display number verbatim and it will be meaningful without the
need to apply any decision logic, plus it neatly accounts for the
combinatorial stuff mentioned earlier.

> 7. Formatted Date/Time. This was another suggestion raised many
months
> ago now which I've left in.

Not very keen on this.

> This leaves us with this:
>
> CID.Incoming
> {
> Type=[VOICE RINGBACK MESSAGEWAITING]
> --- Mandatory call type
> DateTime=YYYYMMDDHHMMSS
> --- Mandatory
> Phone=["01234-567890"  UNAVAILABLE  WITHHELD
INTERNATIONAL??  PAYPHONE??]
> --- Mandatory
> Name=["Calling Line Name"  UNAVAILABLE  WITHHELD
INTERNATIONAL  PAYPHONE]
> --- Mandatory
>
> Formatted_Date=22 January 2003
> --- Optional
> Formatted_Time=21:27:00
> --- Optional
> }
>
> Any further comments?

Patrick