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:55:53 -0600
Message-ID: <4784D269.9010904@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
> Eliot Kimber writes:
>> I think DITA shines a spotlight on [the dark corners of xs:redefine
>> interop]. 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).
> I'm not sure I understand.  Do you mean that user 1 and/or document 1
> need schema B, which redefines schema A, while user 2 and/or document
> 2 need schema C, which redefines schema A?  Or do you mean that some
> users/documents need schemas B _and_ C, both of which redefine schema
> A?
> The former is fine, it's only the latter which is tricky and, in fact,
> I would say, an error (because B and C will produce distinct
> definitions of some top-level items. . .).

A given document will only use one of either schema B or C but a given 
user might have instances of documents that use B and instances that use 
C. These two documents might be processed together in the same 
transformation session (because they could be used from a single DITA 
map). This could, I think, lead to a case where an XSLT processor, for 
example, has a cached version of schema A, modified per the redefines in 
schema B, which then encounters schema C, which also uses A but applies 
different redefines. I'm not sure any XSLT processors actually do that 
but I think that's one of the cases Mike is thinking of. If the 
processor wants to do caching of schema modules (that is, caching the 
declarations defined in a given schema instance document without regard 
to use context via xs:include [which is probably a bad thing to do]there 
is no way for it to know, when it processes the document using schema B 
that it will later encounter another document using schema C that 
applies different redefines.

Having thought it about just now, it seems clear that the redefine 
feature definitely precludes caching of modules-as-redefined used via 
xs:include (that is, modules in the same namespace or no-namespace) and 
might preclude caching). The best you could do is cache modules in their 
unmodified state and apply redefines dynamically as you process 
top-level schemas.



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

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