Re: Interaction between redefine+include breaks augmenting a base schema's element with new attributes
Would also need to review what the standard actually says to determine whether there's a bug. Xerces generally tries its best to strictly follow the rules from the XML Schema specification and sometimes those rules (e.g. type restriction) defy what many users would expect. Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Mukul Gandhi wrote on 06/09/2016 11:59:31 PM: > Hi David, > Thanks for writing about this issue. I am sure, that Xerces > developers are always keen to know from users if there is a genuine > bug in Xerces's implementation and they would like to fix the bugs. > > Your problem description looks like a fairly advanced use case of > XML Schema (XSD), and it seems difficult to know the actual problem > in Xerces's implementation that is causing this (likely) bug, > without having an easier presentation of the bug report that is > usually expected to write fixes. > > I would suggest, to open a bug report in Xerce's JIRA with following > qualifications > > Issue Type : Bug > Priority : Minor or Trivial > > Please also attach XML and XSD files that illustrate the bug, and > the actual and expected outputs according to you. If you're keen in > helping us further, and are able to follow Xerce's source code, you > can try fixing the code and also attach a patch. > > But the least I think we would require are all the steps mentioned > here, without a patch. > > On 9 June 2016 at 19:04, David Costanzo > wrote: > There seems to be an interaction between xs:redefine referring to a > schema which then does an xs:include that prevents Xerces from > recognizing that an attributeGroup defined in the xs:include'd > schema has been extended to include new attributes from a second > namespace. I think this is a bug in xerces2, but I'm not an XML > expert, so I have some doubt. Per the instructions on http:// > xerces.apache.org/xerces2-j/jira.html, I am emailing this list for > clarification. > > The basic setup: > base.xsd - Defines an element named "element" with an attributeGroup > base-wrapper.xsd - Merely does an "xs:include" of base.xsd > second-ns.xsd - Defines an attribute named "happy" in a distinct > namespace from one in base.xsd > > augmented.xsd - Does "xs:redefine" of base-wrapper.xsd to add > the attribute from second-ns.xsd to the attributeGroup in > base.xsd.document.xml - Uses an element from base.xsd with the > attribute from second-ns.xsd. > > > My expectation is that document.xml is valid with respect to > augmented.xsd. However, Xerces2 reports a validation error. > > # java jaxp.SourceValidator -a augmented.xsd -i document.xml > [Error] document.xml:7:3: cvc-complex-type.3.2.2: Attribute > 'second:happy' is not allowed to appear in element 'element'. > > > If, instead of redefining base-wrapper.xsd, which does nothing but > xs:include base.xsd, augmented.xsd redefine's base.xsd directly, > then Xerces reports document.xml as valid. > > I have confirmed that "xmllint" (version 20706) reports document.xml > as valid. My JVM uses Xerces-J 2.7.1, but I have also reproduced > this on xerces-2.11.0 and on trunk using "java jaxp.SourceValidator". > > Is this a bug that I should open in JIRA? Or am I misunderstanding > something about XML? > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > > -- > Regards, > Mukul Gandhi - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Interaction between redefine+include breaks augmenting a base schema's element with new attributes
From: Mukul Gandhi> I would suggest, to open a bug report in Xerce's JIRA with following > qualifications [snip] Thanks Mukul, I'll open a JIRA ticket as you suggest. I'll be sure to attach all the files that are needed to reproduce the issue, as I don't think I'd be able to implement a patch. From: Michael Glavassevich > Would also need to review what the standard actually says to determine > whether there's a bug. Xerces generally tries its best to strictly follow > the rules from the XML Schema specification and sometimes those rules > (e.g. type restriction) defy what many users would expect. I agree that the standards sometimes defy my expectations. I also understand that appealing to behavior of "xmllint" doesn't mean that Xerces wrong. I'll try to quote the relevant parts of the specs when I open the ticket. - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Interaction between redefine+include breaks augmenting a base schema's element with new attributes
From: David Costanzo > Thanks Mukul, I'll open a JIRA ticket as you suggest. As I went to open the ticket in JIRA, I found that Mukul Gandhi already fixed it. https://issues.apache.org/jira/browse/XERCESJ-1591 Thank you, Mukul! The fix was made in the xml-schema-1.1-dev branch that has not been merged into trunk, which is why I could still reproduce the problem on the latest code and in the latest release. In looking at the release velocity, I see that the fix was made four years ago, Oct 2012 (just hours after it was reported!), the last Xerces release was made in Nov 2010, and the version which a recent HotSpot JVM (1.8.0_71) uses is Xerces 2.7.1, released in July 2005. So if I want the fix for my program, is my best bet to use a private build from a development branch? Are there any plans for another Xerces release? By the way, once a minimal repro scenario is constructed, this looks like an esoteric problem on the fringes of the XML standards, but this bug does have a practical, real-world impact. In the world of clinical research which includes testing new medicines, there's a standards body called CDISC. CDISC defines an XML standard for interchange of clinical data called ODM and states that a computing system that processes ODM can only claim conformance if it obeys several rules, one of which is "ODM files must validate against the ODM schema for the ODM version indicated in the ODM root element". My project manager has interpreted this as a requirement to validate all ODM documents. The ODM standard allows for "vendor extensions" and requires that they be implemented in a separate namespace. The extensions are added by redefining special "extension groups" which the ODM base standard defines for exactly this purpose. So to qualify as a "conforming system", my code must validate documents according to a schema that a vendor provides me. The ODM base standard has a top-level .XSD file that uses an xs:include and the vendor extensions are expected to use a xs:redefine of that. Because of this bug, Xerces 2.11.0 cannot validate ODM against a vendor's extension. I can make some simple changes to the vendor schema so that Xerces can validate with it, but then that casts doubt on whether it's really validating with the vendor extensions. - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
