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: Greg Chicares
Subject: Re: [lmi] an xml schema for (single|multiple)_cell_document file XML format
Date: Thu, 08 Mar 2012 18:10:15 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 2012-02-27 16:31Z, Vadim Zeitlin wrote:
> On Mon, 27 Feb 2012 15:34:30 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2010-08-09 16:28Z, Vadim Zeitlin wrote:
> GC> > On Sun, 08 Aug 2010 16:28:55 +0000 Greg Chicares <address@hidden> wrote:
> GC> > 
> GC> > GC> On 2007-12-27 12:43Z, Evgeniy Tarassov wrote:
> GC> > GC> > 
> GC> > GC> > The newer version of XML Schema files for cns/ill files could be 
> downloaded
> GC> > GC> > from lmi project download area at savannah:
> GC> > GC> > | 
> http://download.savannah.nongnu.org/releases/lmi/cell_document.tar.bz2
> GC> > GC> 
> GC> > GC> If we were doing this all over today, would XML Schema still be a 
> good choice,
> GC> > GC> or is something else like RELAX NG or Schematron clearly better now?
> GC> > 
> GC> >  I'm not aware of any dramatic changes in the XML validation area since 
> the
> GC> > last 3 years so I'd be tempted to say no, i.e. that XML Schema still
> GC> > remains a decent choice because even though RELAX NG has its advantages
> GC> > over it (notably relative simplicity) it's still less 
> standard/supported by
> GC> > various tools than it. As for Schematron, I believe it's mostly used in
> GC> > addition to either XML Schema or RELAX NG and not solely on its own 
> anyhow.
> GC> > 
> GC> >  I could look more into recent developments in this area but, frankly, I
> GC> > doubt that we're going to find any earth shattering revelations. IMHO it
> GC> > would make sense to stick with XML Schema even if subjectively I like 
> RELAX
> GC> > NG "compact syntax" 
> (http://en.wikipedia.org/wiki/RELAX_NG#Compact_syntax)
> GC> > a lot.
> GC> 
> GC> I wonder whether we should reconsider that, and perhaps use RELAX NG
> GC> instead.
> 
>  I've briefly looked at this again and I found that the difference in
> degree of support in the various tools between XML Schema and RELAX NG has,
> if anything, become even greater in the last couple of years. However RELAX
> NG is still considered to be a better choice for XML validation (only) and

I never thought of it as having any use other than validation...

> so this could be explained by the fact that there is simply not much else
> to do with it, while XML Schema is used for many things (data bindings;
> serialization; code generation; ...) other than validation because it's, in
> fact, better suited for them than for validation.

I don't see how those other capabilities would be useful to lmi, but
tell me if I'm missing something:
 - data binding: we bind xml-data <-> lmi-data already
 - serialization: we save and load xml data; in the past, we accomplished
     the same goal by serializing C++ objects, and it was overkill
 - code generation: been there, done that, too; writing code is more
     flexible than generating it automatically, and it's already been
     written anyway
I suspect this means that if we were going to rewrite lmi from scratch,
and we wanted to make it xml-centric, then these things might help;
else, not.

>  I also found Trang (http://www.thaiopensource.com/relaxng/trang.html)
> which can be used to translate RELAX NG to XML Schema and apparently quite
> a few people use it successfully with XML Schema tools by writing the
> schema in RELAX NG and then just converting it to XML Schema automatically.
> So the following strategy seems safe enough: use RELAX NG for the schema
> but ensure (by running Trang on it periodically) that it can be converted
> to XML Schema if needed. Like this we get the benefit of nicer input
> language without being locked into using it for ever.

That sounds like a good plan. Do you know whether the XML Schema
produced by Trang is harder for humans to understand than a
hand-written Schema? (Maybe it's easier just to do it first, and
see how it goes.)

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

Yes, please.



reply via email to

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