- 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