- From: Eliot Kimber <ekimber@innodata-isogen.com>
- Date: Tue, 26 Jun 2007 07:52:24 -0500
- To: <xmlschema-dev@w3.org>
- Cc:
Michael Kay wrote: >> The motivation is to provide an invariant rather like that of >> object-oriented programming languages: any valid member of a >> type defined by restriction is also a valid member of the >> type defined by its base. > > I think that what this demonstrates is that's there's a set of use cases > where what people want is "a schema that's the same as X except for > difference D", with no constraints on the nature of the difference D - it > might be making a mandatory element optional, or adding values to an > enumeration, or changing something from float to double. > > People imagine that's what xs:redefine was designed for, and perhaps it > should have been. Rather like overriding in XSLT, come to think of it - no > constraints requiring compatibility with whatever it is you are overriding. Exactly: I think I (and the DITA schema developers) took the name "redefine" at its word as the mechanism by which things could be redefined, not restricted. We already have restriction and substitution groups and we've already demonstrated that they are insufficient or inappropriate for the use case of simply allowing unconstrained reconfiguration of base declarations. It may be that in the specific DITA case of enabling reconfiguration of content models that substitution groups would work *if* the current restrictions were relaxed such that any restriction that satisfied the original content model would be allowed, but that not being the case, we had to look for another method by which specializing schemas could conveniently re-configure base content models. In the case shown here, which I think is not a-typical, I have (in DITA terms) specialized element "A" to create new element type "B" and I want to both allow "B" where "A" was allowed and disallow the use of "A". With the current behavior, I can allow "B" in addition to "A", but I cannot then also disallow "A" (ignoring the trick Henry showed, which I cannot of course use in a standard if it's likely to be disallowed in XSD 1.1). In the DTD version you can just redeclare the parameter entity corresponding to the "a" group in this example, e.g.: Base parameter entities (in base.ent): <!ENTITY % a "A"> <!ENTITY % c "C"> <!ENTITY % para.content (%a; | %c;)* > Overriding parameter entities: <!ENTITY % a "B"> <!ENTITY % baseEntityDecl SYSTEM "base.ent" >%baseEntityDecl; Making the effective value of %para.content; "(B | C)*" Without the ability to do this in XSD schemas, there is really no way for something like DITA (or DocBook) to use schemas directly--the only non-DTD option will be to generate them from some other form, either a private XSD variant or something like RelaxNG. However, a generation-based process does not have the same convenience characteristics that using schemas directly would have, significantly increasing the cost and complexity of creating variant schemas, something that is central to the productive use of DITA (creating local specializations) and pretty central to the productive use of DocBook as well. DocBook has already stepped up to use RelaxNG as the base form of its normative schemas but DITA has not. Personally, I think that using RelaxNG and then generating is not the best thing for a standard to do, especially one tightly aligned with W3C standards. That's one reason the limitations on redefine are so frustrating. Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 8500 N. Mopac, Suite 402 Austin, TX 78759 (214) 954-5198 ekimber@innodata-isogen.com www.innodata-isogen.com
Received on Tuesday, 26 June 2007 12:51:45 UTC