- From: Kasimier Buchcik <kbuchcik@4commerce.de>
- Date: Mon, 07 Mar 2005 11:28:45 +0100
- To: noah_mendelsohn@us.ibm.com
- CC: xmlschema-dev@w3.org
Hi, noah_mendelsohn@us.ibm.com 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
Received on Monday, 7 March 2005 10:29:25 UTC