Re: Data Dictionary, Draft 2

[Gerry Duprey]

Howdy,

To throw in some more support, I also have a strong preference for what
Paul
and John have said.

For me, the big benefit of xPL over xAP is the strong schema emphasis.
While
the idea of having a "commonly used attribute" list has merit for
those
constructing/authoring new schemas and/or extensions to schemas, I'd like
to
see it stay at that level - clearly marked as a suggestion list for schema
authors - vs becoming a "parallel reference" that some folks may
mistakenly
use instead of going with existing/extended schema conformance.

As for what John said about data types - I'd like to add a very hearty and
hale "Hell Yes!!".

I'll be honest in that I'm just starting to make the transition from xAP to
XPL so I've not seen all the documents yet, but I'd love to see schema
definitions expressed in terms of attribute names of common use and data
types
of common use.

A simple data typing system would allow a developer to read a schema and
not
only know what attribute names are allowed, but what values those
attributes
can have in an unambigious way.

Consider something as simple as temperature. One developer may assume
Celsius, another Farenheight, another may be explicit and you are left with
something like:
TEMP = 20
TEMP = 22
TEMP = 18F

which makes xPL listeners vulnerable to misinterpretation and/or entirely
unable to make use of an attribute.

Strong typing makes for Strong interoperability! :-)

Here's an example/starting point that I had worked up last year when I was
starting with xAP. As xAP doesn't do a strong schema typing as xPL, I
didn't
publish it then.

Also, this is meant as an expressional form. I would imagine most
senders/listeners would not necessarily be expected to read/understand this
(they could - I'm not sure if xPL has a machine readable schema standard
yet
(I have draft for one of those if not too :-)).

The list is not comprehensive. Rather, it lists the "basic" types
and the
syntax for expressing them and extensions to them. We'd then need to

---------------------------
Proposed base xPL datatypes and datatype expressional form

** Datatypes:
Datatypes are unique identifiers that explicitly describe the allowed
for a given attribute in an xPL schema. Many scalar data types can accept
sub-ranges to restrict the values they carry. These can either be enforced
or
used as reference.

** Ranges:
Ranges, for types that support them, are expressed as a set of square
brackets containing a starting value, a colon and an ending value.

** List:
Lists are available for data types that have a limited number of acceptable
values. For example, a string may be used to track a color and the possible
valid values for that color are RED, GREEN and BLUE. Lists are expressed as
using a parenthesis, following by a number of comma delimited values and a
closing paranthesis. List values are case insensitive (i.e. Red, RED and
ReD
are all the same value).

Ranges and lists are, for the most part, meant as an expressional form
in the schema definition. xPL programs do not generally have to
parse/understand them. For example, if an INTEGER type is used for a
level value and has a range of 0-50, a xPL listener does not have to
expliclty know/parse/validate that value - it can simply extract the
value and use it. It is the responsbility of the sender not to
violate that range. The sender can do this using "implied"
knowledge
(i.e. it knows that this field has a describe range of 0-50) or could
choose to programatically parse a schema definition and learn this
(for a very advanced sender).

** Defining new types:
Stealing somewhat from BNF, an expression of ::= expresses a new type
being built from a previously known type. For example

TEMP ::= INTEGER(-50:100)

expresses a type called TEMP which is in fact an integer with a range
of -50 to 100.

New types can be a concatenation of other types to. For example

TEMP ::= INTEGER(-100:200) + STRING(C,F)

New types can also have literal text in them. For example

EMAIL_ADDR ::= STRING + '@' + STRING

Just remember - most xPL programmers need to be aware of what the
schema and data types are, but do not need to parse/enforce such
things in their code (i.e. keep it simple)


** Basic Data type listing/definitions

Name Options
--------- -----------
STRING List, Range
Description: 0 or more characters.
List: Allows spefic values only.

COLOR ::= STRING(Red,Green,Blue)

Range: Allows specific string length restrictions

CODE ::= STRING[8] - String must be 8 characters long
CODE ::= STRING[1:8] - String can be 1-8 characters long
CODE ::= STRING[0:8] - String can be 0-8 characters long

Range and List are exclusive: You can use one or the other (or neither)
but not both

=============================
INTEGER List, Range
Description: Represents a positive or negative number of any size
with no support for fractions/decimals
List: Allows a specific list of values

PRIME ::= INTEGER(1,3,5,7,11)

Lists MUST be in numerically ascending order

Range: Allows a specific range of values

TEMP ::= INTEGER(-50:120)
OFFSET ::= INTEGER(-100:100)
VOLUME ::= INTEGER(0:100)

Range and List are exclusive: You can use one or the other (or neither)
but not both

=============================
NUMBER List, Range
Description: Represents a positive or negative number of any size
with support for decimals or any number

List: Allows a specific list of values

TUNER_STATION ::= NUMBER(91.7,102.1,106.4)

Lists MUST be in numerically ascending order

Range: Allows a specific range of values
FMTUNER_RANGE ::= NUMBER(88.1:107.1)

Range and List are exclusive: You can use one or the other (or neither)
but not both

=============================
BOOLEAN List
Description: Represents one of two possible values. By default,
TRUE and FALSE

List: Allows changing the boolean identifier values. The
TRUE/Positive identifier is always listed first. There must
always be two and only two items in the list

POLARITY ::= BOOLEAN(Pos,Neg)
STATE ::= BOOLEAN(High,Low)
POSITION ::= BOOLEAN(UP,DOWN)
CONFIRM ::= BOOLEAN(YES,NO)

=============================
DATE Range
Description: Represents a single date. Format is always YYYYMMDD (4
digit year, 2 digit, zero filled, right justified month
from 01-12, 2 digit zero filled right justified day in
month from 01-31).

Range: Allows setting limits on the valid range of dates. Rarely
used.

MAY_2003 ::= DATE[20030501:20030531]


=============================
TIME Range
Description: Represents a time within a day. Format is
HHMM[SS[.sss]] Time is in 24 hour format (00 = 12
midnight, 23 - 11PM). Minutes run from 00 to 59.
Seconds are optional and run from 00 to 59.
Milliseconds are optional and run from .1 to .999.
Hours, minutes and seconds are formatted as 2 digit,
zero fillied, right justified numbers.

Range: Allows setting limits on the valid range of times

PM_ONLY ::= TIME[1200:2359]


===============================
DURATION

Description: Describes a specific time and date. Format is
YYYYMMDDHHMM[SS[.sss]] where YYYY is a 4 digit year, MM
is the 2 digit, zero filled, right justified month in
the year from 01-12, DD is a 2 digit, zero filled right
justified day in the month from 01-31, HH is a 2 digit,
zero filled right justified hour in the day in 24 hour
format from 00 to 23, MM is a 2 digits, zero filled,
right justified minute within the hour from 00-59.
Seconds are optional and if supplied are 2 digits, zero
filled right justified from 00-59. Milli seconds are
optional and start with a decimal point and a number
from 1-999 representing the number of milliseconds


** Some Derived/extended standard data types

TEMP := INTEGER + STRING(C,F) (i.e. 80F 21C)
PERCENT := INTEGER[0:100]
DEVICE_STATE := BOOLEAN[ON:OFF]
DIGITAL_STATE := BOOLEAN[HIGH:LOW]

EMAIL_ADDR := STRING + '@' + STRING

X10HOUSE := STRING(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O)
X10UNIT := INTEGER[1:16]
X10DEVICE := X10HOUSE + X10UNIT

Again -- these are data types, not attribute names. The attribute
names are defined by the schema that defines them and each name has a
specific data type

-------------------------------------------------------------------

--
Gerry Duprey
Ann Arbor, MI 48103
<a href="http://www.cdp1802.org";>http://www.cdp1802.org</a>