Re: Reviving the xPL Schema definition discussion

[Mark Hindess <xpl@xxxxxxxxxxxxxxxxx>]

On 26 November 2005 at 10:32, Gerry Duprey <gerry@xxxxxxx> wrote:
>
> Howdy,
>
> A while back, I brought up the topic of finding a formalized way to
> encode the xPL schema specification into a means that was machine
> parsable.  My thinking was this format could be used by programs to
> know how to receive/send messages to new devices and could be the
> "source" documented that is processed into a more human
readable HTML
> document.
>
> Right now, schemas are defined in plain text documents.  While they
> are pretty reasonably formatted, there are variation in terminology
> and structure leading to some questions that may not be fully answered
> by a developer looking to use that schema the first time.
>
> By formalizing this, it would remove much of the possibility for
> ambiguity and allow an even more dynamic xPL network to exist.  The
> schema documents can be hosted in a common place with a machine
> readable directory (just like the plugins files) so that an
> application, on first encountering messages for a schema it's not
> previously heard from, could fetch the document, parse it and adjust
> itself accordingly.
>
> Anyway, at the time (about October 12th), there was some discussion,
> but not too much more.  I'd like to get back to this at some point
> (once I get my UPB xPL modules complete) and thought I'd bring it back
> up (you can go back to that message in the archives for a summary of
> an initial XML file format proposal).
>
> Any thoughts?  Should this move forward, stay in discussion mode for a
> while or just be dropped?
>
> NOTE: It's important to realize that, like the vendor plugin file,
> this is an optional thing -- a vendor could introduce a new schema
> class/type without it and devices/programs would be under no
> obligation to have to support reading/parsing it, but it would be
> there for devices that can support it (like my currently languishing
> xPL user interface builder).

I really like this idea.  In the perl code I am busy writing, I am
creating perl objects based on "class.type" of a message.  I am
coding
the fields, validation on values - though this is weakened on incoming
messages - and ordering of fields.  The reason I'm doing this is so that
it means that I can catch mistakes early and have good validation to
avoid sending bad messages to other devices.

I'm doing this in the code as a quick way to get a few message types
working.  There are too many types to do this for them all.  So my
intention all along has been to capture the schema definitions as a data
format and create the code for the perl objects on-the-fly.  (I wasn't
planning to go so far as to downloaded them, but I certainly wanted
users to be able to add them themselves without having to know perl -
while I don't understand them, many intelligent people have no wish to
learn perl. ;-)

I was going to make up a format but if there is going to be a standard
way to do this that would be much better;  writing the
definitiions would be a joint effort and much of the ambiguity in the
current specifications would automatically be removed by having one less
(manual) step from specification to code.

I think that Mal's suggestion that we use XSD has some merit.  (There's
quite a good introduction at http://www.w3.org/TR/xmlschema-0/
for
those still wondering what it is.)  I loath XML because it's not easy
to parse with a small amount of code and it rarely ends up being human
readable.  However, even with this bias, I think the research that has
gone in to developing XSD - such as understanding basic field types and
the effective validation mechanisms that are required - is undoubtedly
applicable and we should make as much use of this as possible.

So, I think we should either use XSD or at least have a one-to-one
mapping between whatever we use and XSD - i.e. share types and
validations.

I'd be very interested in helping out with this.

Regards,
Mark.