Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: "Michael Kay" <mike@--------.--->
To: "'Eliot Kimber'" <ekimber@--------.--->, <xmlschema-dev@--.--->
Date: 1/7/2008 3:03:00 PM

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@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Eliot Kimber
> Sent: 07 January 2008 14:53
> To: xmlschema-dev@w...
> 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
> 


From ekimber@r... Mon Jan 07 15:11:49 2008
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Ex


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent