OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [relax-ng-comment] Limitations of W3C XML Schemas vs. RELAX NG?


|> ----- Mixed Model Document -----
|>   <?xml version="1.0"?>
|>   <Foo>
|>     <item>Value</item>
|>     <item value="Value" />
|>   </Foo>

"Anthony B. Coates" <abcoates@theoffice.net> wrote:
|Although this is one of the standard examples of how RELAX NG is better than
|W3C XML Schema, I think you should also ask what actual value there is in such
|a construct.  When is it necessary to encode a value sometimes as element
|content and sometimes as attribute content.

The example I presented was simplified, but the situation arose from an
actual production system.  In part, this was because my data
serialization library evolved over time, but I did not want to abandon
compatibility with previous serializations.  Well, also because
gnosis.xml.pickle is an open source package, and changes were
contributed by a users who thought they needed it.

In the more complete case, each <item> does not only have a "value", but
also a "type".  Depending on the type, it either is or is not possible
to encode the necessary data within a "value" attribute.  For example:

  <item type="string" value="Bar" />
  <item type="list">
    <item type="numeric" value="17"/>
    <item type="None"/> <!-- None is singleton like NULL, NIL, NaN -->
  </item>

Initially, I knew based on the type alone whether it would contain a
"value" attribute, or whether it would require nested subelements.  But
as the capabilities were enhanced, we grew the capability for custom
types, and custom representations.  I do not know in advance whether a
given new type needs to go in an attribute or body (and whether it will
have subelements, or use the body as a BLOB.

I realize that I could have "bitten the bullet" during initial design,
and never used a "value" attribute.  But that seemed inelegant, and less
descriptive.  Moreover, past initial design, there were compatibility
issues to worry about.

Admittedly, I don't really *need* to validate serializations at all
outside the library that handles them.  In part it is a matter of having
examples for my articles.  But it also seems like the "right thing" to
allow such validation... maybe serializations became corrupt, or were
manipulated by buggy tools.

Yours, David...

--
---[ to our friends at TLAs (spread the word) ]--------------------------
Echelon North Korea Nazi cracking spy smuggle Columbia fissionable Stego
White Water strategic Clinton Delta Force militia TEMPEST Libya Mossad
---[ Postmodern Enterprises <mertz@gnosis.cx> ]--------------------------



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC