=?ISO-8859-1?Q?Re:_[xml]_Question_about_error_reporting_when_using_key_/_?= =?ISO-8859-1?Q?keyref=09constraints_in_Schema?=


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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]