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 <muk...@apache.org> 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 <david_costa...@yahoo.com.invalid > > 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
