Hi Michael,
Great, we already made this patch in Oxygen XML Editor a couple of weeks
ago.
It would also be nice if possible if the problems would be reported in
the order in which the invalid IDREFS were made in the XML document (in
document order).
Regards,
Radu
Radu Coravu
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
On 8/28/2012 5:14 PM, Michael Glavassevich wrote:
Hi Radu,
I agree it would be helpful to the user if Xerces reported multiple
IDREF errors. I'll take a look at this one.
Thanks.
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]
Radu Coravu <[email protected]> wrote on 28/08/2012 09:32:53 AM:
> Hi Mukul,
>
> I work for Oxygen XML Editor and we are updating the used Xerces library
> in order to benefit from the experimental XML Schema 1.1 validation.
> The patches we make to fix things in Xerces are different from the ones
> you would make to the Xerces code because we try to have as little
> modifications as possible in the patched classes.
>
> In the case of this bug, probably the method:
>
> org.apache.xerces.impl.validation.ValidationState.checkIDRefID()
>
> which is overridden in:
>
>
org.apache.xerces.impl.validation.ConfigurableValidationState.checkIDRefID()
>
> would be modified to be do like:
>
> > /**
> > * return null if all IDREF values have a corresponding ID value;
> > * otherwise return the first IDREF value without a matching ID
value.
> > */
> > public String[] checkIDRefIDs () {
> > List<String> brokenIDs = null;
> > Iterator iter = fIdRefTable.keySet().iterator();
> > String key;
> > while (iter.hasNext()) {
> > key = (String) iter.next();
> > if (!containsID(key)) {
> > if(brokenIDs == null) {
> > brokenIDs = new ArrayList<String>();
> > }
> > brokenIDs.add(key);
> > }
> > }
> > return brokenIDs != null ? brokenIDs.toArray(new String[0])
: null;
> > }
>
> Then in all places where it is currently referenced, have a loop which
> iterates all broken IDs and outputs a message.
> The problem is that the reported broken IDREFS will not be reported in
> document order as they are stored in a hash map.
>
> Regards,
> Radu
>
> Radu Coravu
> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> http://www.oxygenxml.com <http://www.oxygenxml.com/>
>
> On 8/28/2012 3:31 PM, Mukul Gandhi wrote:
> > Hi Radu,
> > You seem to be reporting few issues with Xerces, recently. This is
> > very helpful for our project. If you're in a position to submit any
> > patches for the issues, it'll speed up solving the reported errors.
> >
> > On Tue, Aug 28, 2012 at 5:37 PM, Radu Coravu (JIRA)
> > <[email protected]> wrote:
> >> Radu Coravu created XERCESJ-1581:
> >> ------------------------------------
> >>
> >> Summary: Report all id/idref problems when
> validating XML against DTD or XML Schema
> >> Key: XERCESJ-1581
> >> URL: https://issues.apache.org/jira/browse/XERCESJ-1581
> >> Project: Xerces2-J
> >> Issue Type: Improvement
> >> Reporter: Radu Coravu
> >> Priority: Minor
> >>
> >>
> >> By default when the first broken IDREF is found an error is
> reported and no other IDREF is checked.
> >> Because of this an use who has a lot of broken IDREFS would have
> to fix the problems one at a time and to run the validation after
each fix.
> >> Instead if would be nice if all broken IDREFS were reported as errors.
> >> So the method
> "org.apache.xerces.impl.validation.ValidationState.checkIDRefID()"
> could report all broken IDREFS and then you could build and throw a
> message for each one.
> >>
> >> So if the following XML would be validated with the Xerces sample
> "personal.xsd" the validation should report more problems than it
does not:
> >>
> >> <personnel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >> xsi:noNamespaceSchemaLocation="personal.xsd">
> >> <person id="Big.Boss">
> >> <name>
> >> <family>Boss</family>
> >> <given>Big</given>
> >> </name>
> >> <email>[email protected]</email>
> >> <link subordinates="one.worker two.worker three.worker
> four.worker five.worker"/>
> >> </person>
> >> <person id="one.worker">
> >> <name>
> >> <family>Worker</family>
> >> <given>One</given>
> >> </name>
> >> <email>[email protected]</email>
> >> <link manager="Big.Boss2"/>
> >> </person>
> >> <person id="two.worker">
> >> <name>
> >> <family>Worker</family>
> >> <given>Two</given>
> >> </name>
> >> <email>[email protected]</email>
> >> <link manager="Big.Boss3"/>
> >> </person>
> >> <person id="three.worker">
> >> <name>
> >> <family>Worker</family>
> >> <given>Three</given>
> >> </name>
> >> <email>[email protected]</email>
> >> <link manager="Big.Boss4"/>
> >> </person>
> >> <person id="four.worker">
> >> <name>
> >> <family>Worker</family>
> >> <given>Four</given>
> >> </name>
> >> <email>[email protected]</email>
> >> <link manager="Big.Boss5"/>
> >> </person>
> >> <person id="five.worker">
> >> <name>
> >> <family>Worker</family>
> >> <given>Five</given>
> >> </name>
> >> <email>[email protected]</email>
> >> <link manager="a"/>
> >> </person>
> >> </personnel>
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
