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