Lists Home |
Date 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,