location of DOM objects back in xml file

[foolproofplan]

I am currently having a problem with checks I am doing on a DOM tree
of objects that I have created from an xml file. If I run into an
error with something within my DOM tree, I want to be able to include
the location (line/column) of where this error occurs back within my
original xml file. The trouble is, the DOM parser does not send any
information back on where it is as it creates it's DOM tree. The code
I am working with appears to be using the xerces DOM parser. The only
two ideas I could come up with was either running a search back over
the xml afterwards for it or using some other type of DOM parser that
would include information about lines and columns. Any suggestions?
Thanks!

- Marc

 

[dick.deneer]

I am currently having a problem with checks I am doing on a DOM tree
of objects that I have created from an xml file. If I run into an
error with something within my DOM tree, I want to be able to include
the location (line/column) of where this error occurs back within my
original xml file. The trouble is, the DOM parser does not send any
information back on where it is as it creates it's DOM tree. The code
I am working with appears to be using the xerces DOM parser. The only
two ideas I could come up with was either running a search back over
the xml afterwards for it or using some other type of DOM parser that
would include information about lines and columns. Any suggestions?
Thanks!

- Marc

When you download xerces there is also a directory containing
samples.
In the directory DOM you will see the program DOMAddLines.java.

Regards,
Dick Deneer

 

[Joseph Kesselman]

error with something within my DOM tree, I want to be able to include
the location (line/column) of where this error occurs back within my
original xml file.

There is no standard place for a DOM to store tha information. Some
individual DOM implementations may offer a custom hook for the purpose
if you can find the appropriate parser option to turn on, but then your
code won't be portable to other implementations.

A more portable solution would be to write a SAX-drive DOM constructor
that uses the userData hooks or some similar mechanism to associate
nodes with information from SAX's Locator interface. Still not pretty.

Suggestion: Why not report your error in terms of an XPath instead?
Simple XPaths are easy to generate from a document instance, and while I
admit few editors (so far) are set up to let you click on them and jump
to that point in the document, they're actually significantly more
informative -- you're told immediately that the problem was in
/foo/baz[3]/murph[2] (or something of that sort), which -- assuming you
name your elements more informatively than I just did -- is probably
going to be a much more meaningful descripion of what went wrong than
"line 27 column 3".

 

[p.lepin]

Suggestion: Why not report your error in terms of an
XPath instead?

I just wanted to second this bit of advice and mention a
couple of reasons this might be a very good idea indeed:

1. XML is all about structured data. Might as well make use
of that structure.
2. The same document tree might be serialized very
differently indeed. Different serializations still
represent the same tree and are (or should be)
indistinguishable from the XML tools point of view.
Naturally 'line-column' locations do not necessarily
mean the same thing for different serializations. XPath
expressions still do.

In short, I think it's a better idea to use something that
is pretty much guaranteed to work and is semantically
loaded to boot instead of arbitrary 'line-column' pointers.

 

[foolproofplan]

error with something within my DOM tree, I want to be able to include
the location (line/column) of where this error occurs back within my
original xml file.

There is no standard place for a DOM to store tha information. Some
individual DOM implementations may offer a custom hook for the purpose
if you can find the appropriate parser option to turn on, but then your
code won't be portable to other implementations.

A more portable solution would be to write a SAX-drive DOM constructor
that uses the userData hooks or some similar mechanism to associate
nodes with information from SAX's Locator interface. Still not pretty.

Suggestion: Why not report your error in terms of an XPath instead?
Simple XPaths are easy to generate from a document instance, and while I
admit few editors (so far) are set up to let you click on them and jump
to that point in the document, they're actually significantly more
informative -- you're told immediately that the problem was in
/foo/baz[3]/murph[2] (or something of that sort), which -- assuming you
name your elements more informatively than I just did -- is probably
going to be a much more meaningful descripion of what went wrong than
"line 27 column 3".

I understand the usefulness of reporting an error in terms of an
XPath, however,
I am adding errors to an already designed system which outputs the
line and column.
I appreciate the suggestions though.

 

[foolproofplan]

When you download xerces there is also a directory containing
samples.
In the directory DOM you will see the program DOMAddLines.java.

Is there any code provided for C++? I have looked around and could
only find code for Java. May have to do a little "translating" on it.