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@i...
www.innodata-isogen.com


From ht@i... Tue Jun 26 12:57:47 2007
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1I3Ac7-0006E5-1