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 mike@s... Mon Jan 07 15:03:26 2008
Received: from lisa.w3.org ([128.30.52.41