lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] an xml schema for (single|multiple)_cell_document file XML for


From: Vadim Zeitlin
Subject: Re: [lmi] an xml schema for (single|multiple)_cell_document file XML format
Date: Thu, 8 Mar 2012 20:20:05 +0100

On Thu, 08 Mar 2012 18:10:15 +0000 Greg Chicares <address@hidden> wrote:

GC> > so this could be explained by the fact that there is simply not much else
GC> > to do with it, while XML Schema is used for many things (data bindings;
GC> > serialization; code generation; ...) other than validation because it's, 
in
GC> > fact, better suited for them than for validation.
GC> 
GC> I don't see how those other capabilities would be useful to lmi, but
GC> tell me if I'm missing something:
GC>  - data binding: we bind xml-data <-> lmi-data already
GC>  - serialization: we save and load xml data; in the past, we accomplished
GC>      the same goal by serializing C++ objects, and it was overkill
GC>  - code generation: been there, done that, too; writing code is more
GC>      flexible than generating it automatically, and it's already been
GC>      written anyway
GC> I suspect this means that if we were going to rewrite lmi from scratch,
GC> and we wanted to make it xml-centric, then these things might help;
GC> else, not.

 FWIW I agree with all of the above, I just listed them in an attempt to
give a more complete view of the situation.

GC> >  I also found Trang (http://www.thaiopensource.com/relaxng/trang.html)
GC> > which can be used to translate RELAX NG to XML Schema and apparently quite
GC> > a few people use it successfully with XML Schema tools by writing the
GC> > schema in RELAX NG and then just converting it to XML Schema 
automatically.
GC> > So the following strategy seems safe enough: use RELAX NG for the schema
GC> > but ensure (by running Trang on it periodically) that it can be converted
GC> > to XML Schema if needed. Like this we get the benefit of nicer input
GC> > language without being locked into using it for ever.
GC> 
GC> That sounds like a good plan. Do you know whether the XML Schema
GC> produced by Trang is harder for humans to understand than a
GC> hand-written Schema? (Maybe it's easier just to do it first, and
GC> see how it goes.)

 I could try to run Trang on some existing schema but I haven't done it
yet. But again I agree that it would be more useful to implement our schema
in RELAX NG and run Trang on it as the results can vary depending on the
exact constrains used in the specific schema.

GC> > GC> For now, only '.cns' and '.ill' files need be covered. Obsolete 
historical
GC> > GC> versions needn't be supported; we'd want schema support only for 
current
GC> > GC> and future versions.
GC> > 
GC> >  We can try to produce a RELAX NG schema for them to see how it goes.
GC> > Should we?
GC> 
GC> Yes, please.

 OK, we'll start working on this and will look at the output generated by
Trang as soon as we have something minimally working.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]