[
http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12358600
]
Jean-Jacques Thomasson commented on XERCESJ-1112:
-------------------------------------------------
Hi Sandy,
I run some new tests :
A) I moved the redefinition of the complex type ("contentType") into the first
<redefine> element.
---------------------------------------------------------------------------------------------------------------------------------
So that we avoid the complex situation where the second <redefine> redefines an
object used in the first <redefine>.
--> it works (with XSV) since the type "contentType" is an object of one of the
sub-schemas of "elementGroups.xsd" which is redefined by the first <redefine>
element.
That is an interessant configuration since we have there only one <redefine>
element and we get exactly the result we wish to achieve with our models. So,
if you make it working, it will be a good good result to us.
In the zip file I download on the site and named "BugXercesStudy.zip", that
test is corresponding to "descriptSchema2.xsd" and has been test both for
Xerces and XSV.
B) I have replaced the <redefine> element by a simple <include> element
----------------------------------------------------------------------------------------------------
I have replaced the two <redefined> by one and only one <include> of
"elementGroups.xsd".
So, of course, any redefinition have gone out.
Why is that an interessant test ?
Xerces is perfectly able to valid that model : it does nto generate any error.
So, it means that if Xerces is fully able to handle our model where sub-schemas
are mutually included, then it should be able to handle at least one <redefine>
of that model.
In the zip file I download on the site and named "BugXercesStudy.zip", that
test is corresponding to "descriptSchema1.xsd" and has been test both for
Xerces and XSV.
C) I have used the <redefine> with no redefinition in
----------------------------------------------------------------------
That test is fun.
Remove all of the redefinitions and just keep the <redefine> declaration. Just
like an <include>.
Then Xerces is producing the exact same list of errors as before while it
produces no error when <include> is used.
Cnoclusion : Xerces handles correctly the <include> statement but not the
<redefine> one.
In the zip file I download on the site and named "BugXercesStudy.zip", that
test is corresponding to "descriptSchema3.xsd" and has been test both for
Xerces and XSV.
Conclusions
-----------------
Please, consider that there is a real bug of Xerces when <redefine> is used and
it is not only a problem of management of its error messages. If you just focus
on the correction of the way Xerces is handling error messages, I think that
the real problem will not be adressed.
I, and the working group which is behind me, are many many times thanking you
for your interrest on that problem which is of the first importance for the
success of the complex modeling of data and documents of the industry that
group is representing.
> The parser do no support multiple inclusions of the same "sub"-schema
> ---------------------------------------------------------------------
>
> Key: XERCESJ-1112
> URL: http://issues.apache.org/jira/browse/XERCESJ-1112
> Project: Xerces2-J
> Type: Bug
> Components: XML Schema Structures
> Versions: 2.7.1
> Environment: Any platform. Problem exists on any version of Xerces
> Reporter: Jean-Jacques Thomasson
> Assignee: Sandy Gao
> Attachments: ParseWithXerces.zip, bugXercesStudy.zip, dm.zip,
> dmodule_descriptSchema_flat.xsd
>
> An example :
> In a schema named "complexTypes.xsd", we define the following inclusions :
> <xs:include schemaLocation="attributeGroups.xsd"/>
> <xs:include schemaLocation="simpleElements.xsd"/>
> <xs:include schemaLocation="complexElements.xsd"/>
> <xs:include schemaLocation="elementGroups.xsd"/>
> and, in "complexEelements.xsd", we use the following inclusions :
> <xs:include schemaLocation="complexTypes.xsd"/>
> (Since we need element definitions to define complexTypes and vice-versa).
> Most of the parsers (XSV, XMLSpy) are now supporting this kind of
> self-mirroring inclusions which is admitted by the W3C recommendation (Note
> 2 of section 4.2.1 "Schema Representation Constraint: Inclusion Constraints
> and Semantics ").
> But Xerces produces (a series of) the following sample message :
> "[Error] complexTypes.xsd:32:54: sch-props-correct.2: A schema cannot contain
> two global components with the same name; this schema contains two
> occurrences of ',contentType_fn3dktizrknc9pi'."
> It is an important matter of concern for industries wishinig to have a
> complex architecture of schemas such as the aeerospace industry.
> Please, could you look at this ?
> Jean-Jacques Thomasson
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
