W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2004

'Re: "Re: Including schemata with duplicate referents"'

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>
Message-ID: <418B9B78.8090404@4commerce.de>

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

This (maby naively) would be nice:
1. Evaluate what schema documents are involved in all the recursive
2. Create all schemata + components from the schema documents
3. Make a list of components which are duplicate by name and target
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" />

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?


Received on Friday, 5 November 2004 15:26:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:06 UTC