W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2008

RE: Implementations/Non-Implementations of xs:redefine?

From: Michael Kay <mike@saxonica.com>
Date: Mon, 7 Jan 2008 15:03:14 -0000
To: "'Eliot Kimber'" <ekimber@reallysi.com>, <xmlschema-dev@w3.org>
Message-ID: <012f01c8513e$6daf8220$6401a8c0@turtle>

I think it's not so much a question of whether tools implement redefine or
not, it's a question of whether they handle the corner cases, and how they
handle the cases that are not well-described in the specification. Examples
are whether two schema documents B and C can both redefine A, and under what
circumstances those redefinitions can coexist. Or what happens if you load a
schema incrementally (for example because of xsi:schemaLocation) and you've
already started validating before you encounter a redefinition. Or what
happens if you are doing something other than straight validation.

I think it would be wise for anyone using xs:redefine to check that their
usage of it is supported by the tools they consider important in their

Michael Kay


> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Eliot Kimber
> Sent: 07 January 2008 14:53
> To: xmlschema-dev@w3.org
> Subject: Re: Implementations/Non-Implementations of xs:redefine?
> Eliot Kimber wrote:
> > 
> > I'm trying to get a clear understanding of what the current 
> and likely 
> > future state of implementation of the xs:redefine feature is.
> I just wanted to touch this thread, which I posted before the 
> holiday and suspect that it went unnoticed.
> This is both a practical issue for some of my current and 
> potential clients as well as an issue for the DITA standard 
> and community as well.
> In short, I need to be able to accurately determine the risk 
> and/or wisdom of using XSDs for DITA specializations.
> The issue as I understand it comes down to two things:
> 1. There are certain valid DITA specializations that cannot 
> be expressed with xs:redefine, namely the case where you 
> specialize from a base type and do not want to allow the base 
> type in the specialized document type (e.g., you create 
> specialized type "bar" of base type "foo" and then modify the 
> group containing foo to only allow bar, not foo or bar.
> 2. As DITA's use of XSD relies on xs:redefine (and, in 
> particular, how it is implemented by Xerces), use of 
> XSD-based DITA documents is precluded with any tool that does 
> not either implement xs:redefine or does not implement it in 
> a way that agrees with Xerces' interpretation of the XSD 
> specification.
> If my issue 1 is stated correctly, I know that it will not be 
> addressed in XSD 1.1 (because the xs:override feature 
> proposal was not accepted). 
> However, one can still safely use XSD for DITA 
> specializations as long as you can live with the constraint 
> of not disallowing base type.
> But issue 2 is more critical: if there are popular tools that 
> do not or will not implement xs:redefine (at all or 
> consistent with DITA's
> requirements) then there is a problem for which there is no 
> workaround.
> Thanks,
> Eliot
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
> www.reallysi.com
> www.rsuitecms.com
Received on Monday, 7 January 2008 15:03:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:45 UTC