[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
