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

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

From: Eliot Kimber <ekimber@reallysi.com>
Date: Wed, 09 Jan 2008 07:17:08 -0600
Message-ID: <4784C954.9050103@reallysi.com>
To: xmlschema-dev@w3.org
CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, Michael Kay <mike@saxonica.com>

Henry S. Thompson wrote:
> Hash: SHA1
> Michael Kay writes:
>> 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.
> Another way of going forward wrt Eliot's concerns is to observe that
> for _non_-corner cases, redefine implementations are in my experience
> pretty good and consistent.  If the DITA schema's usage of redefine
> doesn't explore the darker corners such as those Mike mentions above
> (and it's not hard to stay out of those corners), you should be in
> pretty good shape.

I think DITA shines a spotlight on those corners. In particular, any two 
  topic specializations used in the same environment (which will be all 
realistic uses of DITA, which, out-of-the-box, defines three 
specializations of the base topic type) will re-use the same base schema 
modules and apply *different* redefines.

I think that's exactly the main issue Mike is describing: schemas B and 
C (e.g., topic-type-specific "shell" schemas) both redefine groups 
defined in schema A (the base "topic" topic type schema module).

In a CMS system that's trying to manage these topics, I can imagine a 
serious problem if it expects to be able keep a single, invariant 
version of the "topic" module in memory or reflected in its internal 
schema or whatever.


Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
Received on Wednesday, 9 January 2008 13:17:45 UTC

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