Thanks Gary. I've been meaning for a long time to fish through JIRA and start building release notes. Probably enough new function / enhancements to call it 2.12.0.
Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Gary Gregory <garydgreg...@gmail.com> wrote on 06/13/2016 05:03:33 PM: > I can probably help here and there. > > Gary > > On Mon, Jun 13, 2016 at 1:22 PM, Michael Glavassevich <mrgla...@ca.ibm.com > > wrote: > Regarding a new Xerces release, I think we'd certainly like to see one > happen, but it needs volunteers to help drive it. > > Thanks. > > Michael Glavassevich > XML Technologies and WAS Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > David Costanzo <david_costa...@yahoo.com> wrote on 06/10/2016 04:07:52 PM: > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
