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 _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
