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

[James Clark <jjc@jclark.com>]

I think that's a very common pattern: the same thing can either have a 
simple value (which fits in an attribute) or a complex value (which needs 
child elementa to represent it).  Some examples:

1. RELAX NG itself: the name of an element can be a simple name or can be a 
name class
2. XML Schema: the base type in a simple type restriction can be either a 
base attribute or a simpleType child
3. XSLT: the value of a parameter can be either an expression in a select 
or a template expressed as child elements

--On 20 January 2003 13:35 -0500 "David Mertz, Ph.D." <mertz@gnosis.cx> 
wrote:

>|> ----- 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> ]--------------------------
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>