The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Schema definitions -- a discussion



Excuse me if I've got the wrong end of the stick, but isn't there
already a standard way in XML to describe schemas - the XSD?   We
wouldn't want to be reinventing the wheel if it can be avoided...

Mal


Gerry Duprey wrote:

> 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
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
> http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
>
>
>
------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "ukha_xpl
>       <http://groups.yahoo.com/group/ukha_xpl>"
on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        ukha_xpl-unsubscribe@xxxxxxx
>       <mailto:ukha_xpl-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>
------------------------------------------------------------------------
>




xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.