[xml] Re: xsd:include question

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

agantuk B wrote:
> > Hi.. i've a newbie question... 
> >
> > I've a basic question on includes.  I've 3 files - 
> > base.xsd,  one.xsd, two.xsd.
> >
> > base.xsd defines some element names (of type
> > simpletypes, & complex types).
> > one.xsd, two.xsd refer to the element names in
> > base.xsd, and add additional elements.
> >
> > two.xsd includes base.xsd
> > one.xsd includes base.xsd
> > one.xsd also includes two.xsd
> >
> > one.xsd:
> > ....
> > <xsd:include schemaLocation="base.xsd"/>
> > ....
> >
> > two.xsd:
> > ...
> > <xsd:include schemaLocation="base.xsd"/>
> > <xsd:include schemaLocation="one.xsd"/>
> > ....
> >
> > Should the schema parser complain about multiple
> > element names ?  with libxml (testSchema) it does,
> > with some others it doesn't !

No, it shoudn't complain. I guess you hit the non-complete
implementation of the <include> mechanism. Could you send a
reproduceable test case, i.e. an instance and the XSD files? Is the
included XSD a cameleon include? I.e. is the targetNamespace not
existent in it?
The main problem with includes is a check for component-identity,
which is not implemented yet: one has to check if a component has the
same name/namespace _and_ if it is identical in structure, the latter
being not easy, since for complex types the content model needs to be
compared as well. Additionally there is no definition for such a
component-identity check. So we could decide to implement such a
comparison, but it would still leave a good chance of our comparison
being different from other schema validators - gaining not much.

The include mechanism is one of issues the W3C XML Schema working group
has promised to clear up in the next version of the XML Schema spec.

My thinking here is that a component-identity check is not the most
wise thing to do; there should be an other easier mechanism to
distinguish components. I don't know if the schema spec people have
thought about associating a globally-unique-identifier (GUID) with each
component. This is how interface declarations in Delphi work; if a name
conflict arises, the GUID is there to distinguish.

But the good thing is that the most cases could be solved by using
the targetNamespace/file name of an included XSD as the basis for
component-identity. This would assume document-location-identity,
i.e. the machanism would know that a document - and its components - at
the same location are equal; this would _not_ cover cases where the
_same_ document is hold in different locations; imagine a base XSD
hold locally on every machine for perfomance purposes, but all the other
XSDs, including this base XSD, being distributed over different
machines. The workaround for this would be to use XML dictionaries, but
those are not anchored in the schema spec.
I hope this makes some sense to you, since I'm ill and feel a bit
dazed today :-)

If this is a blocker for you, please bugzilla it. I'll have little time
for Libxml2 the next weeks, and want to use that time for the completion
of the indentity-constraints.

> > (error: A global element declaration with the name
> > 'foo' does already exist)
> >
> > Thanks  a lot.
> > agan.

I'll carbon-copy your mail to the list.

Regards,

Kasimier