[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