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] Restrictions on existence of attributes?

[ Lists Home | Date Index | Thread Index ]

Lots of good points.

For the issue of supertype/subtype/inheritance, there are two aspects. 
One is whether the constraints can be expressed: and, indeed, the same 
constraints can be expressed and RELAX NG et al is more powerful than XSD.

The second is whether constraints can be modeled using inheritance 
relationships. You are right that RELAX NG does not have any facilities 
for this (e.g. it has a facility called combine that can be used to do 
the same kind of thing that XSD substution groups does, but it is not a 
type-based mechanism.) Schematron does have phases, abstract patterns, 
abstract rules, @role and diagnostics all of which allow different kinds 
of inheritance/type relationships to be expressed.

But the issue is, I think, whether modeling subtype relationships 
belongs to the validation language or to the IDE. XSD conflates these 
two issues, forcing tool makers to adopt the subtyping approach. RELAX 
NG splits them: a toolmaker could easily make a system that checks 
whether one RELAX NG schema is a restricted or xsd-style extension of 
another. A toolmaker could make a diagramatic tool for generating and 
maintaining schemas using UML or other inheritance based system.

So RELAX NG provides the resolved schema, and it leaves the issue of 
mapping from ER or classes as a tooling issue.

XSD's conflated approach is not univocally better. For example, my 
company Topologi puts out a large semi-custom web tool for allowing 
large distributed groups to collaboratively develop XSD schemas  in 
variants: it is used by a comprehensive consortium working in the 
largest industry sector in my country. The tool supports allowing 
different groups to create variant schemas independently, then 
reconciling them against a base schema as a separate. subsequent 
process. The XSD tight coupling is all wrong for development in that 
environment, because when you have more than a handful of groups with 
dozens of members making changes, you simply cannot afford to change the 
base schema constantly: it needs a more governed process. 

In effect, we have found that what works in this environment is to use 
XSD rather like RELAX NG, with a large vocabulary of datatypes and 
elements that can be combined in particular schemas, with complex typing 
of subtypes deferred to a separate process under schema governance. This 
resolution process obviously includes arbitration between conflicting 
requests for changing the base.  In common with many other XSD systems, 
we have to support only a particular set of XSD features, because some 
of the higher-level ones are wrong for our needs.

In the case of databinding, where there is a pre-existing ER or UML or 
classes that get converted into a schema, is there really any utility 
apart from documentation for having that schema contain inheritance 
relationships?  In the case of XSD, for complex types you have type in 
the whole content model again for extension and restricted derivation, 
so there is no saving in tersity. (Contrast with simple type derivation 
by restriction, which is terse by allowing deltas only.) 

Jack Lindsey wrote:
> So it does not make sense to use two schema languages for most people, 
> now and even less in the future, IMHO (and I have a personal oXygen 
> licence).  We need essentially one language that does it all, modular 
> or otherwise. 
I couldn't disagree more, maybe. "We" need a rich range of solutions 
*and* we need the will to promote convergence. In .NET, there are all 
those languages with the same libraries: syntax and approach difference 
allow more optimal fits.
> So alternatively, from a user perspective, I strongly support your 
> overtures to the W3C XML Schema WG to integrate Schematron and select 
> features of Relax NG.  That makes so much sense it should be 
> inevitable.  Any feedback on that to date?
Oh, I have very small hopes. The XSD vendors will be trying to get a 
return from their current investment, and trying to fix shortcomings in 
XSD by bluster and wallpaper (err, I mean education and tools support). 
In standards development, you go through stages of people saying "yes, 
it will be able to do that". "yes, it can do that", "yes, it doesn't do 
that", "yes, it should have been able to do that", "yes, you've made 
your bed now you have to sleep in it", to the final stage "yes, we are 
putting that on the list for some future version real soon now!".  
(These correspond to the Kubler-Ross stages of denial, anger, etc, 
perhaps :-) 

Rick Jelliffe


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

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