Re: [xml] Question about error reporting when using key / keyref constraints in Schema

[cazic gmx net]

Hi,

> Von: GUY Fabrice <fabrice guy gmail com>
> Datum: Thu, 11 Aug 2005 17:21:27 +0200
> 
> >   maybe the line of the reference can be saved at the same time of the
> > value, that's what I did for ID in DTD validation when streaming. And
> > it is sufficient for the error report you don't need to keep a pointer
> > to the node.
> 
> For error report it is sufficient, but I suppose that for error
> catching (using for example xmlSchemaSetValidErrors) this mechanism
> won't allow to get the error node I need. So is it possible to save
> also the name of the element ? (knowing the name and the value of the
> element would be sufficient for me to get the error node, even if it's
> not very efficient)

The line number and the element name (and it should come with a
namespace as well) will not be sufficient in every case, since if
the instance does not contain line-breaks then the line number
should be 1 (or 0?) for all elements. One could argue that this
argument does not hold, since if an instance fails, then one needs
just to pretty-print it with a tool and validate again and then to
lookup the line. IHMO I don't think the people will really do this,
especially if processing massive instances streamwise, and thus
we will establish: "oh damn, the recipient rejected our message and
guess what he send us as a report", "hmm, line 1,
element {urn:this:stuff}td ?", "yes", "what was the size of the 
message", "1 MB", "OK, just forget it".
I vote for an XPath expression pointing to the error-prone node.
Maybe this cannot be done via Libxml2's standard error channels,
but at least via a schema specific error channel - possibly per
option. For non-cached nodes the XPath can be constructed on-the-fly,
for cached node information, like for the keyref stuff, someone
should come up with a smart memory-optimized approach.
Big words, but little energy on my side for this, until I'm finished
with implementing <redefine>s.
But as a first step, storing designations of distinct nodes in dicts
for keyref reports should be doable - if wanted and excepted - and
should not trouble memory that much.

Regards,

Kasimier