From: Rick Jelliffe [mailto:rjelliffe@a...]
Three responses.


First is that XSD was not designed as an abstract data modeling language but rather a markup description language: even though the grammars have been somewhat extended with xsd:any and wildcards (and now assertions and conditional types), XSD is not a substitute for the kinds of things you would use, say, UML for. (And then convert the UML to RELAX NG.) XBRL is an example of a system that attempts to piggyback data modeling on top of XSD, and makes an almost fatal complexity.



Okay, I'm not sure I entirely followed that; using UML to model data structures is fine and great, but UML doesn't enforce anything.  If the contract specified by your abstract (UML) data model is not enforced by your concrete data model (be that XSD or RNG or a combination of layers), then your abstract model is a lie and any code that depends on it will be unreliable.  However...



The second is that IMHO it is better to see RELAX NG as part of the ISO DSDL standard, so when there is some feature missing from RELAX NG, it may be provided elsewhere.  This is a layered approach, where each language tries to do one thing really well, rather than a monolithic approach where . For example, you organize your system to that there is a master RELAX NG schema, then you add your restrictions as a layer in Schematron. You do the detailed cardnality constraints in Schematron.
The advantage of this approach is that you are not at the mercy of the abstractions provided by the schema language: you don't need to think "what combination of restiction/extension/redeclaration do I need, and what are the order, ambiguity and UPA issues?" because you can just say "Inside a Bar, element X is not allowed" directly.



Fair enough, but the projects I work on tend already to have a rather painful number of layers, so I try to avoid adding more layers than is absolutely necessary.  On the other hand, I have recently been looking into adding a Schematron layer anyway, in order to enforce some of the rules that XSD cannot (or cannot easily) enforce, so I may re-evaluate RNG as part of that process.



[...]

The third thing is that the design of RELAX NG is, to my mind, that abstract assertions about the relationships between schema items does not belong in the schemas themselves. They would better left to tools. [...]



I'm not sure that I agree with that, but that is perhaps a philosophical discussion in which I'm not prepared to engage just now. :-)



I would note that one large schema we maintain, in which a master vocabulary is used by a dozen committees to make multiple local schemas, we actually remove type derivation information from the working draft schemas, and only add it at the end (it is a pain) because it is too much trouble maintaining the base schemas to track the work in progress. [...]



I would only comment that it _sounds_ (if I understand your description correctly) like you're not following the open-closed principle; perhaps the difficulty is due to the design and not the grammar.

Doug Glidden
Software Engineer
The Boeing Company
Douglass.A.Glidden@b...

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php