XOM API for Processing XML with Java

[Tatu Saloranta <cowtowncoder AT yahoo.com>]

--- Ed Davies <edavies AT nildram.co.uk> wrote:

> John Cowan wrote:
> > If xml:id errors were marked "fatal", then *every*
> implementation would
> > have to treat them as fatal.  However, there is
> nothing stopping XOM from
> > (a) treating the errors as fatal in every case, or
> (b) providing a switch
> > the user can set to "Ignore xml:id errors" or
> "Treat xml:id errors as
> > fatal", or (c) providing a hook such that elements
> with xml:id errors
> > are passed to the hook, or ....
> 
> Daniel Veillard wrote:
> >   And that's how we end up with software expecting
> id('1234') or 
> > id('foo bar') to work in XPath. I still think it's
> a disaster to
> > let this go though while we had the opportunity to
> block it and
> > force the cleanup for xml:id
> 
> 
> If John's choice b) is selected then the switch
> should be "Ignore
> xml:id errors"; the default should be to treat the
> errors as
> fatal for the reason Daniel Veillard gives.  It's
> always easier
> to loosen the rules when it's found to be necessary
> than to
> retrospectively tighten them.

While true, it's good to remember that ALL non-fatal
errors (and not obeying normalization rules for
character types in non-validating mode is just a plain
[validation] error, not a fatal [well-formedness]
error) usually get treated this way. I don't like it
much myself, but had to make woodstox stax parser work
this way, since Xerces does it; and the xml test
suites also cleary expect such tame response to
validity problems (xmltest and saxtest are full of
such use cases).
Of course, what SAX/StAX parsers do does not
necessarily mean XOM has to use the lowest common
denominator... but doing something different will be
surprising for many users ("hey, xmltest says this is
just fine, why does XOM crap on it?").

As to XPath, I'm not sure it can be argued that such
thing should be forced to match/work: how (and if)
malformed value is normalized is probably not fully
defined (could be left as is; spaces inside could be
removed; perhaps it'd be ok to change it to "foobar"
for all I know). So while parser would not necessarily
throw an exception, behaviour of an xpath/xslt
processor could be best-effort at best, meaning
matches (if any) were based on pure luck?

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com