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 08:11:12 -0600
Message-ID: <4784D600.8080803@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:
>> 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.
> Right -- so my point would be, _this_ case at least is not a
> corner-case wrt xs:redefine as such, but rather an issue for
> namespace/schema/cache management in multiple-validation-session
> contexts.  Many/most of the relevant issues might arise without
> redefine being involved at all, e.g. if I have two documents which
> share a namespace but have xsi:schema-location hints pointing to
> differing schemas (e.g. different versions) for that namespace.

Fair enough.

In thinking about this particular issue, I'm not sure if the other case 
can occur, where top-level schema D uses modules C and B, which each 
apply *different* redefines to groups used in base module A. I suspect 
that that case *does* occur but I'll have to verify.

For example, you could have a shell that integrates two modules that 
each define different specializations of elements in a base module. 
Those two modules would be (at least conceptually) applying different 
redefines to the base groups defined in the base module, but I'm not 
sure if it actually occurs with the way DITA requires that schemas be 
composed into working document types. I will investigate.


Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
Received on Wednesday, 9 January 2008 14:11:35 UTC

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