Schema definitions -- a discussion

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy All,

Now that I've stuck my beak into plugin files and such, I'm starting to
think the concept should be extended a bit to programatically document the
schema definitions.    This comes up as I'm creating a (hopefully) generic
xPL aware user interface tool for creating panels to control xPL (and
other)
devices.  I keep running into cases where either I have to embed knowledge
into my code about how certain schemas work or leave things so generic that
the "end user" creating a panel just has to type things in
"free form"
because I can't validate the details (or supply defaults).  Neither case
sits well with me.

Right now, the schema is described in text documents and that is very
useful, but at the same time, it's next to impossible to programatically
learn things, at a schematic level, about messages.

The existing plugin file is great in that it allows you to define common
means to command a device.  However, it requires you to define those means
for every device out there -- even if several devices are basically the
same
(i.e. support the same schema).

For example, the X10 schema is supported for about 5 different xPL devices.
Right now, using plugins, there would have to be 5 fairly lengthy plugin
definitions that contained, for the most part, the exact same data (the
commands and such).  And should things change with the schema, then each
devices author needs to update their plugin before the change can take
effect.

First, let me be clear in that I'm not suggesting altering the existing
elements of the plugin files.  True, if this were to work out, it might
beneficial to provide a mechanism in a plugin to "extract" things
from a
schema (to eliminate having to type all the stuff in), but this doesn't
have
to happen in the first draft and indeed, it doesn't have to happen at all.

Fortunately, a lot of the concepts needed have already been fleshed out in
the plugins file, so we can leverage a lot of that in a schema based file
definition.  In certain cases, I've changed small bits of terminology if I
felt the terms might be too UI oriented.  But those are rare (i.e.
"dropdownlist" becomes "list").

I could imagine each schema class having it's own file and within that
file,
all the schema types would be defined. Like the plugins file, I'd propose
the XML be used as the encoding format to promote cross-platform use.  Like
plugins, there would have to be some "master index" that could be
consulted
to find where to fetch schema documents automatically.

I also think the idea of a limited form of "inheritability" is
needed to
allow a vendor to perhaps create their own extension of a schema (for more
private use -- if it were more general, they should apply for a new schema
type in that class).

The interesting thing is, done right, we could use these files to
auto-generate the more human readable schema documents we have now.  In
short, find a way to encode the schema definition once and then create the
machine readable version and human readable version from the same source
material.

I would be happy to supply a tool that allowed editing these documents,
much
like XPE allows editing plugins.

I've put together a sample document to illustrate what I'm thinking.  I'm
perfectly ok with this being ripped to shreds and rebuilt -- in fact, I'm
hoping a discussion along these lines will result in a good deal of this.
But it gives a starting point for the discussion to start from.  You can
read it at:

http://www.xpl4java.org/xpl-schema.txt

First question, I suppose, is -- is there any interest in this?

Next: whats missing?  what is too convoluted or not described enough?  etc.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org