- From: Kasimier Buchcik <kbuchcik@4commerce.de>
- Date: Fri, 05 Nov 2004 16:25:44 +0100
- To: Ed Day <edday@obj-sys.com>
- CC: <xmlschema-dev@w3.org>
Hi Ed, Ed Day wrote: > Hi Kasimier, > > I am trying to understand the problem here better because we have an > application (XBinder) which processes XML schema import and includes. I am > interested in making sure we do it right as well. I assume that you are > just compiling or parsing schema A since doing B1 or B2 separately would not > appear to be a problem. What we do in the case of A is include all of the > definitions for A, B1, B2, and C inline and reolve from there. It has not > seemed to cause any problems so far. What is the case where this would > cause a problem? Ah, this sounds more like the 'copy & paste' essence mentioned by Henry Thompson. This (maby naively) would be nice: 1. Evaluate what schema documents are involved in all the recursive includes/imports. 2. Create all schemata + components from the schema documents 3. Make a list of components which are duplicate by name and target namespace 4. Resolve references: 4.1 if resolving to duplicates: use only the first one 5. Build properties of components which involve referenced components 6. Check if the duplicate components are identical by component: 6.1 if yes, remove the duplicates, leaving the first one 6.2 if not, raise an error Any component would need to know to what namespaces its references actually can resolve, reflecting the <import namespace="http://FOO" /> thingy. Ed, does this binder take care of cameleon inclues? Are there any problems with creating 'complete' wildcards with this mechanism? Assuming inline definitions of B1 and C, plus being B1 and C schema documents with no target namespace, when do you change the target namespace of B1 and C to the target namespace of A? If from begin on, do you get the same results from deriving wildcards with ##targetNamespace? As per spec, ##targetNamespace would be 'absent' here during intersection of wildcards, with your machanism it would be different. Hmm, does a table exist, which makes clear that this results in the same 'complete' wildcard in any case? [...] Kasimier
Received on Friday, 5 November 2004 15:26:28 UTC