Hi,

noah_mendelsohn@u... wrote:
> FWIW, Schema 1.1 will attempt to clarify details of inclusion, import, 
> etc.    Though the Workgroup has not yet agreed on specific language, my 
> expectation is that it will be made very clear that cycles in the graph of 
> inclusion, import, xsi:schemaLocation, etc.  are definitely allowed.  As 
> someone has noted they are useful.  Circular redefines typically make no 
> sense, and I expect that they will be disallowed.
> 
> While implementations are free to get the right answer anyway they can, I 
> expect that the design will be compatible with an algorithm along the 
> following lines:
> 
> 1. Compute the set of files resulting from the transitive closure of a) 
> all the schema docs explicitly named on a command line, API, or similar 
> processor-dependent mechanism b) files included by them c) imports for 
> which schemaLocation is honored d) xsi:schemaLocations that are honored d) 
> redefines.   Note that transitive closures don't look infinitely on 
> cycles.   We just collect a set of filenames.
> 
> 2.  Check for cycles in the redefine graph.
> 
> 3.  Compute the schema resulting from this collection of schema docuemnts
> 
> The above oversimplifies many details, including among others "chamelon 
> include"  (include of a document with no targetNamespace by a doc that has 
> one), but the spirit is right.

[...]

Can you already make any statement whether component identity checks
will still play a role in the forthcoming spec? I.e. are there any other
ideas of how to identify a component being just a duplicate without
comparing the whole structure of the component? Or is it just me seeing
a lot of - still undefined - comparison operations if given a scenario
where schemata are partly located on the net and partly locally for
performance reasons, having an intersection of identical schemata at
different locations. If a system like XML Catalogs is not anchored in
the spec, thus not always having the ability to twist the location
information to the right place, the schema location becomes useless
for indentity assumptions; having this in mind, plus wanting to
eliminate component identity checks, I feel that there is a need for an
extra amount of information on every <schema>, marking its content to be
a specific fragment for a specific target namespace or no target
namespace. Like there's no Java class with the same name allowed
in the same package, schema component checks should not be necessary if
there would be a mechanism to define finer graded affiliation.

Regards,

Kasimier





From K.Buchcik@4... Mon Mar 07 15:32:22 2005
Received: from lisa.w3.org ([128.30.52.41])
	by