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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Making a silk purse out of the schema sows ear - was [xml-

[ Lists Home | Date Index | Thread Index ]


IMHO, the main difficulty that schema technologies encounter is their 
poor capabilities to express constraints because they are hard-coded in 
the schema. This is the case for occurrence constraints and content 
model definitions.

I have experimented a schema language that allows to compute the 
occurrence constraints dynamically and that allows to switch from a 
declarative language to an imperative one, which increases dramatically 
the expressiveness of the schema. The idea is to push back the limits of 
the declarative language when they are reached.

An example :
a RelaxNG user was complaining about a constraint that he couldn't 
express : he had to design a <table> with any <column>s but <column>s 
should have the same number of <cell>s

I respond that he could consider an alternative schema technology, such 
as these that I designed :
<asl:element name="column">
     <xcl:if test="{ asl:element()/preceding-sibling::column }">
         <asl:element ref-elem="cell" min-occurs="{
  $asl:max-occurs }" max-occurs="{ count( asl:element()/../column[1]/cell
  ) }"/>
         <asl:element ref-elem="cell" min-occurs="1"
The full schema and the running results are available here :

This demonstrates that a simple if-then-else statement allows to build a 
made-to-measure content model with dynamic occurrence constraints.

I named that schema language the Active Schema Language and I have an 
almost full implementation of it in Java, called RefleX :
You can read the examples, download the tool and play with it.

Moreover, ASL allows to design smart data types ; there is a tutorial in 
the RefleX web site that shows a semantic data type : the "temperature" 
data type, which is able to parse "32F" and "20C" ; as this type is 
used to augment the amount of information of the XML document, we can 
sort a list of attributes of this type not on the string values but on 
the typed values

It is worth seeing because all the problems you consider in your message 
are pointed out and solutioned in ASL.

Michael Champion wrote:
> I think the reality is that lots of people flipped the Bozo Bit on the 
> XSD spec in 1999-2000.  They went in different directions, however:  
> Some to alternative schema languages, some to radical simplification of 
> XML to de-emphasize schemas altogether.
> In hindsight, had  people foreseen today's reality that we're stuck with 
> XSD as what the mainstream user thinks of as the "real standard", 
> clearly the energy would have been better spent debugging the wretched 
> thing rather than trying to pretend it doesn't exist or trying to drive 
> a stake thru its heart.  I'm more interested in discussing what to do 
> going forward given the current mess.  The problems I see are:
> - The W3C is more interested in moving the XSD spec forward than fixing 
> its numerous ambiguities.  (Their pushback is that the people who want 
> to fix it are not represented on the WG, and the people who have skin in 
> the game want to move forward).
> - RELAX NG is clearly "better" for textual documents but doesn't have 
> much support for the data-oriented use cases. (Sure you can plug in the 
> XSD type system, but that's a big part of the problem).  We now have an 
> unpleasant situation of fragmentation where there's little mainstream 
> tool support for RELAX NG due to lack of demand, exploitation of its 
> geek chic (partly to strike a blow against the empire, I suppose), with 
> the result that the normative definitions of Atom and ODF can't be used 
> with most commercial XML tools.  Maybe a good guerilla tactic in the 
> open source wars, but for the moment it's the innocent who suffer the 
> collateral damage.
> - Schematron is moving forward as an ISO standard and has some good 
> implementations but has few normative references in vertical industry 
> standards nor mindshare.  (Correct me if I'm wrong about the normative 
> references).
> - Lots of people complain about the limitations of XSD that Schematron 
> addresses and the W3C doesn't plan to, especially the lack of occurrence 
> constraints.
> The best way forward that I can see is to encourage end users to 
> employ XSD + Schematron as necessary, and encourage W3C to address XSD's 
>  bugs and ambiguities before adding more onto an unstable foundation.   
> What does that miss that the world actually values? (as much as it 
> depresses me to say it, the world doesn't seem to value RELAX NG's 
> elegance and mathematical foundation very much). 


              (. .)
|      Philippe Poulard       |
        Have the RefleX !


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS