You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org> on 2005/10/31 10:20:55 UTC
[jira] Created: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
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
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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=all ]
Jean-Jacques Thomasson updated XERCESJ-1112:
--------------------------------------------
Attachment: dmodule_descriptSchema_flat.xsd
> 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, 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12358579 ]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
> "descriptSchema.xsd" does not redefine
> "complexElements.xsd" but some groups of elements defined in
> "elementGroups.xsd" and one complex type defined in "complexTypes.
> xsd".
Right. I apparently messed up the xsd file names.
> I have run the test you mention where "descriptSchema.xsd" is
> containing only one redefinition (the first one). I have experienced
> that that case is also leading to the same errors list with
> Xerces
As mentioned in my previous comment, this is the bug I'm fixing, but I haven't comment the changes yet.
> I agree with your conclusion that Xerces has an internal
> architectural problem which quickly leads to difficult situations
> such as the one we have found.
I agree that Xerces' architecture makes it hard to produce a more helpful error message, but I'm not yet convinced that it's architecturally broken.
> With that test, it is clear that
> Xerces do not support <redefine> when the redefined schema is itself
> complex, using mutually included "sub-schemas".
Again, this is the bug I'm in the middle of fixing.
> 1) as said in introduction, we redefine objects of distinguished
> spaces : groups on one side and one complex type in an other side.
> Both are of different level and do not interfer directly.
The spec is very clear that R needs to include all components from the *schema* (note: not the schema document) corrresponding to R1, except for those being redefine. Because of mutual include, the schema corresponding to R1 has components from both R1 and R2. The same applies to R2. So no, they do interfere!
> 2) XSV and XML Spy are perfectly able to handle that situation and
> are exactly producing the models we are expecting from the schemas.
All that's to say is: there is a bug somewhere in some processor(s). The question of "who" is answered by the spec.
> 3) Our working group has developped a Java program which produces
> what we call a "flat schema"
Unfortunately, what the spec says is you are redefining a 'schema", not a schema document, so "flattened" schema documents aren't necessarily the same as "redefined" ones.
> 4) Xerces is not able to handle the situation even in the case there
> is only one redefinition.
:-) Again, I'm fixing it.
> By solving the problem for one redefinition, you will maybe solve
> the global problem.
If you can pursuade me that's what the spec says.
> I am not convinced that we are facing a restriction of the spec for
> the following reason :
I agree with most of your resons, but they are all for "what the spec may want to say", as opposed to "what the spec says". That is, they are good reasons to correct/clarify the spec. My reading of the big constraint in 4.2.2 (especially clause 4) leads to my earlier conclusion.
> I'm going to continue thinking about the matter and being open to
> discussion. Don't you think that it could be interesting to present
> the case to Henry Thompson.
>From past discussion with him (and other Schema WG members), there are certainly disagreements regarding how redefinition works. It may be useful to move this disucssion to xmlschema-dev@w3.org or www-xml-schema-comments@w3.org.
> I'm not sure that the case you mention at the end of your message is
> fully equivalent since there is an <include> before the
> <redefine>ition.
I wasn't advocating that kind of usage. What I'm asking for is a way to redefine a component that's in an inlcuded schema document. If that works, then you don't need to redefine both schema documents in R. You can then put all your component redefinitions in a single <redefine>.
> On my point of view, the parser should run the following steps, in order :
Again, if that's what the spec says, instead of what some poeple belive what it should say.
> But if
> you are right when you say that what we do is not authorized by the
> spec, then we have a serious problem with XSV and XML Spy which are
> clearly supporting such design.
As said earlier, the spec definitely needs some clarification (or correction), so I wouldn't be surprised that people have interpreted it differently. This certainly isn't the first time schema processors don't agree with each other.
> 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, 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12356505 ]
Jean-Jacques Thomasson commented on XERCESJ-1112:
-------------------------------------------------
Hi Sandy,
WG was a shortcut for EPWG : Electronic Publishing Working Group, a working group of ASD and AIA (respectively
AeroSpace and Defence Industries Association of Europe and Aerospace Industries Association).
That group establishes the S1000D standard which applies to the Aerospace and Defence industries.
I have made a zip fil of the case.
Th "top" level schema (the one containing the redefinitions) is descriptSchema.xsd.
Several good reasons conducted the group to define the type of architectural model you will discover in the zip (flexibility, scalability, ease of management, ease of modification, reusability of components etc.).
Regards,
Jean-Jacques
> 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: dm.zip
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Assigned: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=all ]
Sandy Gao reassigned XERCESJ-1112:
----------------------------------
Assign To: Sandy Gao
> 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
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple
inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12423091 ]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
The (complete) fix I was working on never got finished. But the good news is that a recent change for some other problem made the attached schema happy (or at least a lot happier). Details about the changes can be found in [1,2], and the latest build can be obtained at [3] for testing purposes.
[1] http://marc.theaimsgroup.com/?l=xerces-cvs&m=114798157722279&w=2
[2] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/impl/xs/traversers/XSDHandler.java?r1=348829&r2=407624&diff_format=h
[3] http://vmgump.apache.org/gump/public-jars/xml-xerces2/jars/
> 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
> Issue Type: Bug
> Components: XML Schema Structures
> Affects Versions: 2.7.1
> Environment: Any platform. Problem exists on any version of Xerces
> Reporter: Jean-Jacques Thomasson
> Assigned To: Sandy Gao
> Attachments: bugXercesStudy.zip, dm.zip, dmodule_descriptSchema_flat.xsd, DW1.zip, ParseWithXerces.zip
>
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12356884 ]
Jean-Jacques Thomasson commented on XERCESJ-1112:
-------------------------------------------------
Hi Sandy,
I have a doubt. It seems that the "dc.xsd" schema I joint to the previous zip, is mising one namespace prefix declaration :
and the following
xmlns:dc="http://www.purl.org/dc/elements/1.1/"
must be added to the xs:schema root element.
Regards,
Jean-Jacques
> 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: dm.zip
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12358552 ]
Jean-Jacques Thomasson commented on XERCESJ-1112:
-------------------------------------------------
Hi Sandy,
I do not understand your first paragraph where you write that "descriptSchema.xsd" redefines 1) "complexElements.xsd" and 2) "complexElements.xsd". "descriptSchema.xsd" does not redefine "complexElements.xsd" but some groups of elements defined in "elementGroups.xsd" and one complex type defined in "complexTypes.xsd". I agree that those last two schemas are then mutually including themselves or common parts but redefinitions made in the top-level schema are clearly in two different dimensions (logical spaces).
I have run the test you mention where "descriptSchema.xsd" is containing only one redefinition (the first one). I have experienced that that case is also leading to the same errors list with Xerces--> I agree with your conclusion that Xerces has an internal architectural problem which quickly leads to difficult situations such as the one we have found. With that test, it is clear that Xerces do not support <redefine> when the redefined schema is itself complex, using mutually included "sub-schemas".
But I have difficulties to agree on the fact that the spec does not allow what we for the four following reasons :
1) as said in introduction, we redefine objects of distinguished spaces : groups on one side and one complex type in an other side. Both are of different level and do not interfer directly.
2) XSV and XML Spy are perfectly able to handle that situation and are exactly producing the models we are expecting from the schemas.
3) Our working group has developped a Java program which produces what we call a "flat schema" where all the definitions are in one single file (schema) corresponding to the final and expected result of our model (descripSchema.xsd for example). The program loads the main schema (by the case "descript Schema.xsd") in memory as a DOM object and then recursvely replaces the nodes by the ones coming from the included "sub-"schemas and finally by the redefined objects. As explained in §4.2.2 of the spec. I will post the resulting "flat schema". Not only we are able to produce a global flat schema but we are also able to produce the schema of any of the global element defined anywhere in the top level schema (descriptSchema.xsd by the case) or the sub-schemas (fromcomplexElements.xsd for example).
4) Xerces is not able to handle the situation even in the case there is only one redefinition.
By solving the problem for one redefinition, you will maybe solve the global problem.
I am not convinced that we are facing a restriction of the spec for the following reason :
1) XSV, XML Spy and our Java program are able to handle the situation.
2)Splitting into different schemas the definitions corresponding to simple types, complex types, simple elements and complex elements is not something forbidden and even encouraged for modularization.
3) as soon as you split schemas into different "sub-"schemas you face the problem highlighted by our group. It is not possible to splitt a schema into small parts without having multiple recursive inclusions or the schemas have to be very simple with no common complex types.
4) The paragraph 4.2.2 of the recommendation is stating : "In order to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not." The rest of that paragraph is clear to me and our model is corresponding to any of the written rules in 4.2.2, including the final note. The paragraph stating that "This mechanism is intended to provide a declarative and modular approach to schema modification, with functionality no different except in scope from what would be achieved by wholesale text copying and redefinition by editing." is also clear to me.
I'm going to continue thinking about the matter and being open to discussion. Don't you think that it could be interesting to present the case to Henry Thompson.
I'm not sure that the case you mention at the end of your message is fully equivalent since there is an <include> before the <redefine>ition. Taht is something which 1) is not directly the case in our model and 2) does not explain why Xerces is not making a good job even in the case where there is only one redefinition.
On my point of view, the parser should run the following steps, in order :
Step 1) Stores in memory all of the redefined objects of the top-level schema (the one which is submitted to the parser)
Step 2) Includes (or import) the "sub-"schemas and replaces any of the included objects which are redefined.
Step 3) (in reality part of step 2) Never includes (or import) twice one same "sub"-schema. If any of the included schema contains itself some redefinition, the same process applies but an error mus be produced when a "sub"-redefinition is applying to an already redefined objects. (I think that this is the idea developed in §4.2.2. of the spec "In particular redefining a type is not guaranteed to be side-effect free: it may have unexpected impacts on other type definitions which are based on the redefined one, even to the extent that some such definitions become ill-formed.")
If that series of steps is respected, there will be no more problem while respecting the spirit of spec. But I'm not at all a specialist of the internal architecture of Xerces and definitely not as well informed as you are of XML Schema. If I'm wrong, let me know. But if you are right when you say that what we do is not authorized by the spec, then we have a serious problem with XSV and XML Spy which are clearly supporting such design.
Regards,
Jean-Jacques
> 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, 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12356476 ]
Jean-Jacques Thomasson commented on XERCESJ-1112:
-------------------------------------------------
Yes, we use <xs:redefine> and, originally, our problem was named "Xerces do not support redefine" by the WG.
Would you like to receive the complete sample or do you have enough information to solve the matter ? Models are not confidential.
My feeling is that Xerces does support multiple inclusion of one same "sub-"schema but do not detect it when the multiple inclusion is indirectly caused by a redefine statement.
Regards,
Jean-Jacques Thomasson
> 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
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12356449 ]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
Do you have an <redefine> somewhere in those documents?
If a schema document XSD1 includes another schema document XSD2 (directly or indirectly via other includes) and also redefine XSD2 (again, directly or indirectly via other includes), you'll most likely get the quoted error, because you get both the original component (from <include>) and the redefined component (from <redefine>) and they have the same name.
> 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
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12358687 ]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
> A) I moved the redefinition of the complex type ("contentType") into the first <redefine> element.
Actually, another evidence that the spec needs improvement. From the spec:
"The definitions within the <redefine> element itself are restricted to be redefinitions of components from the <redefine>d schema document, in terms of themselves."
where it clearly mentions "schema document". Also
"1.1 One component which corresponds to the top-level definition item with the same name in the <redefine>d schema document, as defined in Schema Component Details (§3), except that its {name} is - absent- ;"
where again, "schema document" is used. So at least parts of the spec indicate that you can only redefine components in the redefined schema document, hence you are *not* allowed to redefine "contentType" in a redefefinition of "elementGroups.xsd".
But I do agree with you that it'd be helpful to allow this, which is why I raised [1].
> B) I have replaced the <redefine> element by a simple <include> element
Yes, Xerces can handle it; and yes, Xerces should handle the one-redefine case (note that this is different from your scenario #A).
> C) I have used the <redefine> with no redefinition in
Another fixable bug. Didn't want to give this one a high priority because people don't typically have empty <redefine>s. Given that I'm already working on the other fix, I'll take a stab at this one too.
Again, this is different from what you are asking for. To make you happy (either by allowing your original redefinitions, or by allowing your #A), more serious work needs to be done. I really want to defer that untill we get some clear direction from the schema WG.
Unfortunately, given the size and workload of that group (of which I'm a member), I don't see this as something that can be resolved quickly. I'll try ...
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=2330
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple
inclusions of the same "sub"-schema
Posted by "James Coughlin (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12363444 ]
James Coughlin commented on XERCESJ-1112:
-----------------------------------------
I too have a simular problem:
[Error] DWIrmcCommon.xsd:16:27: sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two occurrences of 'irmc,grp_SysID'.
My schema directory implementation is thus:
DW1/Schemas/CCD
Schemas folder contains files:
DW_BaseTypes.xsd
DW_Debtor.xsd
DW_IRMC_Common.xsd
CCD folder contains files:
DWDebtor.xsd
DWIrmcCommon.xsd
The xml instance document's xsi:schemaLocation attribute:
<DebtorFile
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="irmc http://jackflash/DW1/Schemas/CCD/DWDebtor.xsd"
xmlns="irmc"
>
I am attaching a zip file containing the schema files, this file will be called DW1.zip
I would agree that there is some "fishy" here.
The .NET 2.0 Microsoft validating parser has no problem or errors with this schema and the <refefine> feature.
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=all ]
Jean-Jacques Thomasson updated XERCESJ-1112:
--------------------------------------------
Attachment: ParseWithXerces.zip
> 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, dm.zip
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=all ]
Jean-Jacques Thomasson updated XERCESJ-1112:
--------------------------------------------
Attachment: bugXercesStudy.zip
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12358520 ]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
Just took another look at your schemas. Basically what you have is:
descriptSchema.xsd (Call it R for root) redefines both complexElements.xsd (call it R1 for redefine #1) and complexElements.xsd (call it R2), and R1 and R2 some how include each other. Assume C1 (component #1) in R1 and C2 in R2 are redefined.
This is (argurably) invalid. The schema corresponding to R1 has both C1 and C2; C1 is redefined in R so now you have C1_new, C1_old, and C2. The schema corresponding to R2 also has both C1 and C2; C2 is redefined in R so now you have C1, C2_new, and C2_old. The processor is supposed to put all these 6 components into the schema corresponding to R, and a "duplicate component" error is resulted, because C1_new (from R+R1) and C1 (from R2) are same-named but different global components. The same for C2_new and C2.
I agree that Xerces isn't helping in diagnose the problem because it reports "duplicate component" error for almost all components, as opposed to just C1 and C2. To report a more meaningful error is very difficult given the current architecture, and I'd very much like not to do it.
Note that I had originally thought that you only had 1 redefine in descriptSchema.xsd. Xerces couldn't handle that case either, which is fixable bug. I've put together a fix for that and am in the middle of reviewing it.
Unfortunately, the schema spec doesn't allow you to do what you really want to do: to redefine components in Both XSD1 and XSD2 where XSD1 includes XSD2. I've raised a similar issue here [1].
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=2330
> 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: dm.zip
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1112) The parser do no support multiple
inclusions of the same "sub"-schema
Posted by "James Coughlin (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=all ]
James Coughlin updated XERCESJ-1112:
------------------------------------
Attachment: DW1.zip
I am using the sample program:
java sax.Writer -v -s -f
To validate the instance document
There appears to be a bug in this upload that you cannot upload unless you "Grant" otherwise when you press the Attach button,
you get "page not found"
> 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: DW1.zip, 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Updated: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Jean-Jacques Thomasson (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=all ]
Jean-Jacques Thomasson updated XERCESJ-1112:
--------------------------------------------
Attachment: dm.zip
Zip file contains :
One main top level schema
---------------------------------------
descriptSchema.xsd
sub-schemas :
---------------------
attributes.xsd
attributeGroups.xsd
complexElements.xsd
simpleElements.xsd
elementGroups.xsd
complextypes.xsd
simpleTypes.xsd
standard imported schemas :
---------------------------------------
dc.xsd (dublin core)
rdf.xsd (rdf)
xlink.xsd (xlink)
notations declarations :
-------------------------------
notation.xsd
> 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: dm.zip
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple
inclusions of the same "sub"-schema
Posted by "James Coughlin (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12363459 ]
James Coughlin commented on XERCESJ-1112:
-----------------------------------------
Okay, I have found a work around but I don't like it!
Using DW1.zip as a reference:
Modify file DWDebtor.xsd to look like:
-------------------
<?xml version="1.0" encoding="utf-8" ?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="irmc"
xmlns:ir="irmc"
xmlns:ib="IRMC.Base"
elementFormDefault="qualified"
>
<import namespace="IRMC.Base" schemaLocation="../DW_BaseTypes.xsd" />
<redefine schemaLocation="../DW_Debtor.xsd">
<group name="grp_SysID">
<sequence>
<element name="SysID" type="ib:bTypeSysID" fixed="CCD" />
</sequence>
</group>
</redefine>
</schema>
-------------------
Modify file DWDebtor.xsd to look like:
-------------------
<?xml version="1.0" encoding="utf-8" ?>
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ib="IRMC.Base"
xmlns:ir="irmc"
targetNamespace="irmc"
elementFormDefault="qualified"
>
<import namespace="IRMC.Base" schemaLocation="./DW_BaseTypes.xsd" />
<!--
<include schemaLocation="./DW_IRMC_Common.xsd" />
-->
<group name="grp_SysID">
<sequence>
<element name="SysID" type="ib:bTypeSysID" />
</sequence>
</group>
<group name="grp_FileHeaderGroup">
<sequence>
<element name="FileSeqNo" type="ib:bTypeFileSeqNo" />
<group ref="ir:grp_SysID" />
<element name="EffectiveDt" type="ib:bTypeUSAGregorianDate" />
<element name="RunStartDt" type="ib:bTypeUSAGregorianDate" />
<element name="RunStartTime" type="ib:bTypeTime" />
<element name="SourceID" type="ib:bTypeSourceID" />
<element name="DBName" type="ib:bTypeDBName" minOccurs="0" />
<element name="RunID" type="ib:bTypeRunID" minOccurs="0" />
</sequence>
</group>
<group name="grp_FileTrailerGroup">
<sequence>
<element name="RunEndDt" type="ib:bTypeUSAGregorianDate" />
<element name="RunEndTime" type="ib:bTypeTime" />
</sequence>
</group>
<complexType name="ct_Debtor_PhoneItem">
<sequence>
<element name="PhoneType" type="ib:bTypePhoneType" />
<element name="PhoneNo" type="ib:bTypePhoneNo" />
<element name="PhoneValid" type="ib:bTypePhoneValid" minOccurs="0" />
</sequence>
</complexType>
<complexType name="ct_Debtor_PhoneGrp">
<sequence>
<element name="PhoneItem" type="ir:ct_Debtor_PhoneItem" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="ct_Debtor_DemogItem">
<sequence>
<element name="DemogType" type="ib:bTypeDemogType" />
<element name="NameTitle" type="ib:bTypeNameTitle" minOccurs="0" />
<element name="LastName" type="ib:bTypeLastName" minOccurs="0" />
<element name="FirstName" type="ib:bTypeFirstName" minOccurs="0" />
<element name="MiddleName" type="ib:bTypeMiddleName" minOccurs="0" />
<element name="NameSuffix" type="ib:bTypeNameSuffix" minOccurs="0" />
<element name="AddrLine1" type="ib:bTypeAddrLine" minOccurs="0" />
<element name="AddrLine2" type="ib:bTypeAddrLine" minOccurs="0" />
<element name="AddrLine3" type="ib:bTypeAddrLine" minOccurs="0" />
<element name="AddrLine4" type="ib:bTypeAddrLine" minOccurs="0" />
<element name="City" type="ib:bTypeCity" minOccurs="0" />
<element name="State" type="ib:bTypeState" minOccurs="0" />
<element name="Zip" type="ib:bTypeZip" minOccurs="0" />
<element name="Country" type="ib:bTypeCountry" minOccurs="0" />
<element name="CountryID" type="ib:bTypeCountryID" minOccurs="0" />
<element name="AddrValid" type="ib:bTypeAddrValid" minOccurs="0" />
<element name="LangID" type="ib:bTypeLangID" minOccurs="0" />
<element name="SSN" type="ib:bTypeSSN" minOccurs="0" />
<element name="DOB" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="DriversLicense" type="ib:bTypeDriversLicense" minOccurs="0" />
<element name="PhoneGrp" type="ir:ct_Debtor_PhoneGrp" />
<element name="DcdDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="BKYDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="BKYSettleDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="BKYType" type="ib:bTypeBKYType" minOccurs="0" />
<element name="BKYCourt" type="ib:bTypeBKYCourt" minOccurs="0" />
</sequence>
</complexType>
<complexType name="ct_Debtor_DemogGrp">
<sequence>
<element name="DemogItem" type="ir:ct_Debtor_DemogItem" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="ct_Debtor_ScoreItem">
<sequence>
<element name="ScoreType" type="ib:bTypeScoreType" />
<element name="Score" type="ib:bTypeScore" />
</sequence>
</complexType>
<complexType name="ct_Debtor_ScoreGrp">
<sequence>
<element name="ScoreItem" type="ir:ct_Debtor_ScoreItem" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<!-- *** BEGIN: Debtor Stuff -->
<simpleType name="bTypeDebtorUDFType">
<restriction base="ib:bTypeNonBlankPrintableChars">
<minLength value="1" />
<maxLength value="15" />
</restriction>
</simpleType>
<simpleType name="bTypeDebtorUDFData">
<restriction base="ib:bTypeBlankAndPrintableChars">
<minLength value="1" />
<!-- <maxLength value="100" /> -->
</restriction>
</simpleType>
<!-- *** END: Debtor Stuff -->
<complexType name="ct_Debtor_OrigBalItem">
<sequence>
<element name="BalType" type="ib:bTypeBalType" />
<element name="BalAmt" type="ib:bTypeBalAmt" />
<element name="BalDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
</sequence>
</complexType>
<complexType name="ct_Debtor_OrigBalGrp">
<sequence>
<element name="OrigBalItem" type="ir:ct_Debtor_OrigBalItem" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="ct_Debtor_CurrBalItem">
<sequence>
<element name="BalType" type="ib:bTypeBalType" />
<element name="BalAmt" type="ib:bTypeBalAmt" />
<!--
default attribute only applies if element is optional (minOccurs=0) and
tag is submitted without any data. like: <BalIntRate />
-->
<element name="BalIntRate" type="ib:bTypeBalIntRate" default="0" minOccurs="0" />
<element name="BalIntBalType" type="ib:bTypeBalType" minOccurs="0" />
<element name="BalDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
</sequence>
</complexType>
<complexType name="ct_Debtor_CurrBalGrp">
<sequence>
<element name="CurrBalItem" type="ir:ct_Debtor_CurrBalItem" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="ct_Debtor_DebtorUDFItem">
<sequence>
<element name="DebtorUDFType" type="ir:bTypeDebtorUDFType" />
<element name="DebtorUDFData" type="ir:bTypeDebtorUDFData" />
</sequence>
</complexType>
<complexType name="ct_Debtor_DebtorUDFGrp">
<sequence>
<element name="DebtorUDFItem" type="ir:ct_Debtor_DebtorUDFItem" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="ct_Debtor_DB">
<sequence>
<element name="RecAction" type="ib:bTypeRecAction" />
<element name="PacketID" type="ib:bTypePacketID" minOccurs="0" />
<element name="IRMCAcctNo" type="ib:bTypeIRMCAcctNo" />
<element name="UAcctNo" type="ib:bTypeUAcctNo" />
<element name="ClientID" type="ib:bTypeClientID" />
<element name="MainClientID" type="ib:bTypeMainClientID" minOccurs="0" />
<element name="ServiceID" type="ib:bTypeServiceID" minOccurs="0" />
<element name="LocID" type="ib:bTypeLocID" />
<element name="IRMCLocation" type="ib:bTypeIRMCLocation" />
<element name="DeskID" type="ib:bTypeDeskID" minOccurs="0" />
<element name="CollectorID" type="ib:bTypeCollectorID" minOccurs="0" />
<element name="PlaceDt" type="ib:bTypeUSAGregorianDate" />
<element name="LoadDt" type="ib:bTypeUSAGregorianDate" />
<element name="StatusCode" type="ib:bTypeStatusCode" />
<element name="StatusCodeDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="DispCode" type="ib:bTypeDispCode" minOccurs="0" />
<element name="CurrencyID" type="ib:bTypeCurrencyID" />
<element name="OrigBalGrp" type="ir:ct_Debtor_OrigBalGrp" />
<element name="CurrBalGrp" type="ir:ct_Debtor_CurrBalGrp" />
<element name="CommPct" type="ib:bTypeCommPct" minOccurs="0" />
<element name="IntEffDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="LastIntDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="Reason" type="ib:bTypeReason" minOccurs="0" />
<element name="CliAcctNo" type="ib:bTypeCliAcctNo" minOccurs="0" />
<element name="AltAcctNo" type="ib:bTypeAltAcctNo" minOccurs="0" />
<element name="LastChargeDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="ChargeOffDt" type="ib:bTypeUSAGregorianDate" minOccurs="0" />
<element name="DemogGrp" type="ir:ct_Debtor_DemogGrp" />
<element name="ScoreGrp" type="ir:ct_Debtor_ScoreGrp" />
<element name="DebtorUDFGrp" type="ir:ct_Debtor_DebtorUDFGrp" />
</sequence>
</complexType>
<complexType name="ct_Debtor_DBGrp">
<sequence>
<element name="DB" type="ir:ct_Debtor_DB" minOccurs="0" maxOccurs="unbounded">
</element>
</sequence>
</complexType>
<complexType name="ct_Debtor_DebtorFile">
<sequence>
<group ref="ir:grp_FileHeaderGroup" />
<element name="DBGrp" type="ir:ct_Debtor_DBGrp">
<!--
Should be enforced. Temprorarily disabled.
<unique name="UniquenessConstraint_UAcctNo">
<selector xpath="ir:DB/ir:UAcctNo" />
<field xpath="." />
</unique>
-->
</element>
<group ref="ir:grp_FileTrailerGroup" />
</sequence>
</complexType>
<element name="DebtorFile" type="ir:ct_Debtor_DebtorFile" />
</schema>
-------------------
What was done to the above file was to comment out the include for file: ./DW_IRMC_Common.xsd
and to physically include its contents in file DWDebtor.xsd
This gets around the initial error.
However if you remove the directly copy contents of file: ./DW_IRMC_Common.xsd and re-implement the include,
the following problem reappears:
[Error] DW_IRMC_Common.xsd:12:27: mg-props-correct.2: Circular definitions detected for group ':grp_SysID_fn3dktizrknc9pi'. Recursively following the {term} values of the particles leads to a particle whose {term} is the group itself.
[Error] DW_IRMC_Common.xsd:12:27: src-redefine.6.2.1: No group in the redefined schema has a name matching 'grp_SysID'.
I don't see the "usage" difference in logically including via an <include> or physically including. All the object should be treated that same. Logically including makes the physical deployment more flexible.
> 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: DW1.zip, 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Commented: (XERCESJ-1112) The parser do no support multiple inclusions of the same "sub"-schema
Posted by "Sandy Gao (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESJ-1112?page=comments#action_12356499 ]
Sandy Gao commented on XERCESJ-1112:
------------------------------------
I'm not yet convinced that there is a problem. (See my above description.) But there could very well be a bug. I vaguely recall seeing something similar: some strange interation between mutual-include and redefine.
Yes, some sample documents will be very helpful.
> "Xerces do not support redefine" by the WG
You mean the schema working group? Hum... Being a member of the WG, I don't recall it making such a comment.
> 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
>
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org