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 ]

Michael Champion wrote:

> >> Atom and ODF can't be used with most commercial XML tools.
> > Unless you use relax ng tools to convert to xsd?
> But Atom uses constraints that can't be expressed in XSD, so those 
> people are going to be unhappy at some point, right? ...  I'm 
> wondering whether Atom (or one of the other specs that is normatively 
> defined with RELAX NG) could do what they need to do with XSD+Schematron.
I see the new DOCBOOK (is it 1.5?) uses Schematron schemas embedded in 
RELAX NG constraints.

I think they use Eddie Robertsson's XSLT script for embedded Schematron. See

He has a similar script for embeddeding Schematron in XSD schemas. Its 
disavantage for XSD is that it is not
type aware. But then neither are the XSD key and integrity constraints 
currently.  If you use a Schematron with
XSLT 2, then you can get type awareness.

> > I've always viewed Schematron as providing additional functionality
> > beyond what
> > my schema validation gives me, not as a replacement? Rick?
> <>I agree.  I'm not sure whether to call a check against 
> schematron-defined constraints "validation" or not, but it could be 
> used to refine a "data contract" that had to be left open in XSD 
> because of the lack of, for example, occurrence constraints.

If you define a schema language for XML as something which lets you 
describe a tree with attributes, Schematron
is certainly a schema language and more.

If you define a schema language for XML as something which lets you 
describe how the structures/relations found in an abstract
data set, considered as a graph of nodes and arcs or relations and 
entities, have been concretely modeled using XML, then Schematron is 
good as the only full schema language! There is no reason why an 
arbirtary dataset should form a nice tree; indeed, the different ways of 
marshalling/serializing databases to XML by different vendors and the 
various discussions on the desirability of flatness/depths in XML 
documents shows the weakness of regular grammars in this regard:  the 
act of choosing a
regular tree structure forces you to make decisions about which 
structural links or relations are somehow "non-schematic".

If you define a schema language as something which lets you inply types 
to  information items, then schematron is
not a schema language (and possibly RELAX NG is not either!)  When that 
is your definition, then Schematron is
a constraint language.

Schematron will become more important as people get experience and as 
business processes mature to instist on traceability
between business requirements and information structures.  Grammars are 
completely hopeless for this: they force
the schema to have extraneous contraints, they make it more easy to moit 
the rationales for particular information items,
and they leave the developer muddled between expressing business 
requirements and implementation decisions.

With Schematron, you can have a clean split between expressing business 
requirements ("An applicant must
supply a driver's licence number") and the implementation ( <rule 
test="string-length(license) &gt; 7">...) .  Using a grammar, this is 
inverted: the business requirement becomes
an optional comment rather than the main deal; and extra constraints go 
in due to the limited structural
possibilities (sequence, all, any, choice) rather than any actual 
requirement: for example, the  effective inability
of XSD to allow data dumps from databases to come in any order (RELAX NG 
is better with "interleave";
XSD only includes my ANY content model).

"Traceability for  alignment" is the next revolution; it is underlying 
meme behind XML's success--people say XML is good
because text is debuggable and readable and hackable and 
loose-couplable, but all these things are symptoms of the
greater undertow, which is to provide the traceability at all levels 
that allows alignment from business requirements
to implementations.  Ultimately, the requirement for tracability and 
schema governance will allow grammar-based
schemas to fal back to their proper and limited roles: as slightly more 
elaborate data dictionaries used to describe
implementation details that are not dealt with at a higher level by 
rules languages. Thats how it looks to me
as at the start of 2006, at least. 

Schematron  supports alignment, grammars support disalignment.*

> <>
> > I haven't heard of anything merging Schematron with xsd validation.

I do not believe that XSD will ever get path constraints. It is 
undesirable by all parties!
And it is unnecessary. XSD provides the <appinfo> element for embedding 

What should be of pleasant interest to vendors who like the idea of 
adding path based integrity constraints to
types in XSD, is that ISO Schematron explicitly has a faility to allow 
this kind of mix-and-match subsetting.
You want to just use the "assert" element but don't want to worry about 
patterns or variables, then you
can just use that element (in the standard namespace). 

See  http://www.schematron.com/iso/P25.html#GEN38 

We did this because we really wanted to make it as easy as possible for 
vendors to add path-based constraints
in a standard way that would not involve them in any more testing or 
difficulty than if they just went ahead
and added a single element of their own in the msot straightforward way. 
In other words, the extra work that
a vendor needs to say "we support ISO Schematron's assert element" 
instead of "we have our own path based
assertion element" is pretty well the typing involved in using the 
standard namespace and names. Effectively

Any vendor who is sick of having the same issues being constantly raised 
internally and externally
and giving the weak answer "well, you could use Schematron if we 
supported it" have a very quick
and easy way out. Just support ISO Schematron assert elements in xsd 
appinfo elements. (Of course,
the full Schematron language gives much more at little cost, but the bar 
to adding simple constraints
could not be lower. )  Personally, I have found that many of the 
frustrations with the limitations and
baroqueness of XSD (or DTDs, or even RELAX NG) go away when simple 
assertions are also

Rick Jelliffe

* Schematron (and any rule based languages which require natural 
language statements for each rule)  supports
alignment, grammars (and schema languages with syntax or structures that
add constraints not derivable from business requirements) support 
disalignment. <>


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

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