[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: increment pattern for an attribute..
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|