Elliot Kimber writes:

> 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 instancesthat 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.

Henry Thompson writes:

> 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.

I'd like to very strongly endorse what Henry's saying.  xs:redefine is one 
way that users evolving vocabularies can wind up with inconsisent 
declarations for, say, the type T of element E between two different 
validation sessions.  Another way is to just introduce a schema document 
with a new definition for the type in question, but without using 
redefine.  Either way you've got in your use case two schema documents 
defining type T.   My view is that redefine is largely a convenience 
mechanism that is particularly helpful when the original type (or group) 
is a good base for the revised one.  It does, of course, enforce such 
derivation rules (by using the original type as a base type, for better or 
worse), and it does give you the intensional connection that the new type 
is being explictly based on the old.  Still, it's in my mind just another 
way of deploying a new schema document that creates a new (and probably 
different) definition for a type or group.

Yes, all of this means that the caching mechanisms used by whatever 
processors need to be flexible enough to meet the needs of the enviornment 
in which they're being used.  Not a suprise as far as I'm concerned.  By 
analogy, there are some programming environments in which you can edict 
that all the programs you run will use the same implementation for each 
Java or C++ class.  In those environments you can use a simple caching 
strategy -- once you see the class, compile it, and never check again.  In 
many other environments it's legal and useful for me to first run a 
program in which class T has one definition, and then a minute later to 
run a program that uses a different definition, and to have the source 
code for both (or the class files for both) lying around at the same time. 
 Worse, it's quite common to find that the class T itself wasn't 
redefined, but its base class was (this happens every time the base Java 
packages are reshipped by Sun).  A suitably written execution environment 
can cache any or all of these, but it needs to know which versions are 
being used when, and to do invaliations as appropriate.  I think schema is 
the same:  in any given validation episode the types to be used are (or 
will be if the spec is cleaned up) a well defined function of the schema 
documents used in the validation, plus any built in definitions or 
declarations.  Across validation episodes, your mileage may vary, and your 
caching strategy must adapt appropriately.   So, yes, you need to get an 
XSLT implementation that's smart enough to know what you're doing, but I 
don't think that's mainly an issue with redefine.  It's about whether you 
can have two or more schema documents that offer definitions for the same 
type.

BTW: this is my personal view not only of how things do work, corner case 
ambiguity not withstanding, and also how they should work.  I do not speak 
for other schema WG members or for the group as a whole in saying the 
above.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------





From easirois@r... Wed Jan 09 19:58:22 2008
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim