Nope, looks like your problem is different. This appears to be an
incomplete or just an unsure implementation. The code that is causing it is
in xmlschemas.c, just a different location:
/*
* Chameleons: the original target namespace will
* differ from the resulting namespace.
*/
isChameleon = 1;
if (bucket->parsed &&
(bucket->targetNamespace != pctxt->targetNamespace)) {
/*
* This is a sanity check, I dunno yet if this can happen.
*/
PERROR_INT("xmlSchemaParseIncludeOrRedefine",
"trying to use an already parsed schema for a "
"different targetNamespace");
return(-1);
}
Obviously the comment says it all. Your case shows this can happen and from
the XML Schema Part 1: Structures document
"The ·XML
Schema·<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#key-schema>corresponding
to
<schema><http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-schema>contains
not only the components corresponding to its definition and
declaration [children] <http://www.w3.org/TR/xml-infoset/#infoitem.element>,
but also all the components of all the ·XML
Schemas·<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#key-schema>corresponding
to any
<include><http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include>d
schema documents. Such included schema documents must either (a) have the
same targetNamespace as the
<include><http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include>ing
schema document, or (b) no targetNamespace at all, in which case the
<include><http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include>d
schema document is converted to the
<include><http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-include>ing
schema document's targetNamespace."
Your case is the last where no namespace is in the included schema. So it
should allow a generic schema with no targetNamespace to be pulled into the
current document's targetNamespace.
The problem will be to implement pulling the same file into multiple
namespaces which is what it really seems to be complaining about. I'm not
familiar enough with the code yet to know if it is as simple as pulling this
check out to fix, and if that may create any wierd redefinition problems as
the xml file is parsed against common.xsd in different namespaces at the
same time.
Hopefully this helps :)
Jason
On Wed, Mar 4, 2009 at 9:39 AM, Luke Robison <[email protected]>wrote:
>
> On Tue, 2009-03-03 at 20:53 -0500, Oblivian wrote:
> > And I was so busy getting the test cases and patch done, I didn't
> > check today's list threads:
> >
> > http://mail.gnome.org/archives/xml/2009-March/msg00007.html
> >
> > Seems related too...
>
> Indeed it does seem related. I tried applying your patch to my 2.7.3
> code, and while it fixed your test case, it fails to fix mine. Glad I
> could provide another corner case :-).
>
> -Luke
>
> -----------
> Luke Robison
> [email protected]
> Applied Research Laboratories: University of Texas
> Engineering Scientist Associate
>
>
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
