RE: [xml-dev] increment pattern for an attribute..

[Rick Jelliffe <rjelliffe@allette.com.au>]

On Thu, 2007-11-08 at 13:46 +0000, Michael Kay wrote:
> > XSD is so full of distinctions ...
> 
> Yes, it's not an animal that you grow more fond of as you get to know it
> better. I don't think we can ever get rid of the complexity, but I have some
> hope that we can make it do the job that users want it to do. It's nice to
> have got a release out (Saxon 9.0) that supports assertions, I'm looking
> forward to getting feedback on it.
 
Yes, indeed. I know that XSD is really useful for many types of jobs,
especially those related to DBMS and DTD replacement. But it is patently
hopeless at many others, indeed bad. But XSD has been treated as if it
were a general purpose language (like, say, C++ is for programming
languages) rather than a specialist one (like, say, SQL is for
programming languages): the only bus into town rather than just one
bus.  

And congratulations on the new SAXON release, we have switched over to
Saxon 8 for pretty much all our XSLT work here, and we find it
excellent. Highly recommended. And I am glad to see the assert statement
starting to being added (after 8 years), I think it is invaluable and
such low-hanging fruit (though it misses several points that
Schematron's assert statement addresses, which is why I recommended to
the XSD WG that they use the XSD namespace for it and not treat it as
the Schematron assert: Schematron's assertions place primacy on
human-readable text and diagnostics.) I am not sure that xsd:assert will
really solve the architectural problem, that complex type derivation is
so unwieldy and inpractical: a multi-layer approach where XSD or RELAX
NG handles the basic storage-strategy issues and another layer
(Schematron or whatever) provides the constraints and closing properties
that are traceable to specific business requirements, seems workable:
the big step is making base XSDs that are as open as evolution will
require. 

For XSD, I think there is a strategy that could be used to get rid of
the complexity. For a start, XSD was designed with a clear separation
between the components and the syntax: alternative syntaxes are
possible. Next, XSD is so under-modularized that there is scope for
action there (moving out all the XPath-related bits for example.
Finally, there are quite a few concepts in XSD that treated as core but
which could perfectly readily be made into extra layers: complex type
checking against base types being one (since complex types are declared
by redeclaration rather than by deltas, the same approach as RELAX NG
uses could be adopted, where you can compare two schemas and see the
relationship);  PSVI is another; splitting out schema construction and
grammars. Ambiguous content model detection similarly can be a layer not
required by the core. 

Cheers
Rick Jelliffe