- 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>
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 market. Michael Kay http://www.saxonica.com/ > -----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