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



Howdy All,

>>First, let me be clear in that I'm not suggesting altering the
existing
> elements of the plugin files.
>
> I wouldn't try to limit the usage by shying away from changes to the
plugin
> architecture - it seems pretty logical that a schema definition for
(for
> example, X10) contains a lot of the information that a developer would
have
> to add to their own fragment for an X10 application.

I was trying to take this a chunk at a time so as to keep from overwhelming
things.  I do believe that the current plugin format should remain allowed
for compatibility purposes and because it allows vendors who have really
weird devices to create a custom plugin.  However, I could see some
extensions allowing a plugin definition to take advantage of schemas to
simplify themselves like:

<xpl-plugin>
<device id="the-device schema="control.basic"
schema="control.serial">
<configItem .../>
<configItem .../>
<configItem .../>
</device>
</xpl-plugin>

I guess I just didn't want to be throwing too much into the blender at once
:-)

>>Like plugins, there would have to be some "master index"
that could be
> consulted to find where to
>>fetch schema documents automatically.
>
> Which, in a sense would give us an xml representation of the whole
protocol!

Yep -- and using something like XSLT, we could even general human readable
web pages, much like the current schema description pages, from each schema
automatically, so we describe the entire protocol and document it in one
step.

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



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.