Source XML line numbers

[bibach]

Greetings, Adepters...

I'm looking for a way to simplify the job of tracking down locations
in source XML files that are causing errors in downstream processing.
The error messages I get indicate the line number within the XML
file, but it's hard to match this up with the location without loading
the file into a text editor, and I'd rather be able to do this all
inside Editor.

I've done some digging in the documentation, but haven't found
anything promising, yet. Is anyone aware of any facilities for getting
line number information from Editor's parser, or would I have to run a
separate parser, such as the Xerces parser via the Java interface, to
get this information?

Thanks!

-Brandon 🙂

[jdreystadt]

The best access you have is from the parsererrorhook. Write an ACL
function that looks like:

function parser_hook(err, msg, file, line) {
# use this info as needed
response("err=$err, msg=$msg, file=$file, line=$line")

# return -1 if you want to suppress the display of the error
return 0;
}

And then arm the hook with the following ACL.

add_hook('parsererrorhook', 'parser_hook')

Then read in your file.



John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-

[bibach]

Hey, John...

Thanks for the tip. However, I don't think this is going to be
applicable in this case, as the errors are not parse errors. These
files are well-formed and valid, having been maintained in Editor.
These are errors raised by a downstream processing application which
indicates the line number in the XML source so that the user can
correct the problem and run the file again. Long story short,
parsererrorhook would never fire for this file.

-Brandon 🙂

[ebenton]

Could you modify the DTD or Schema to use Editor to enforce the rules that the downstream process is picking up? Or are these all just #PCDATA content causing the errors? Maybe the users don't want this, but you could have a different DTD/Schema for your purposes.

[bibach]

Unfortunately, no, the errors are of a sort that can not be caught by
a DTD or Schema, no matter how tightly it is constructed.

-Brandon 🙂

[steve.thompson4]

Maybe an example of one of the errors would help?


Steve Thompson
+1(316)977-0515

[jdreystadt]

The only other thing I can suggest, and it might be a bit tricky, is to have an external process that inserts processing instructions at or near the appropriate line numbers. Something like a Perl script that would look at your XML files as text, go to the right line number, and then insert a PI marker if the line looked like all text or immediately after the first ">" it found. This would fail if you have much CDATA in your documents but might work well enough to be useful.

John Dreystadt
Software Development Director
Arbortext - PTC
734-352-2835
-

[berard]

I'm not sure if this would be helpful or not, but it's just a thought I had.
When using external XML writers, you can typically define whether or not
output formatting is applied to insert indents before each child element to
make it easier to read in a text editor. With that type of formatting, you
should be able to discover line numbers by running an xpath or tree
traversal to count ancestors and ancestor-siblings.

That said, I'm not sure if Arbortext can output in this way. I know that
there are line-break conditions that may cause problems, as well as file
size/performance issues when using full-formatting.

Another potential problem if you don't explicitly format is that Arbortext
might keep too many elements on a given file-line, ultimately making line
reporting useless anyway.

keith

On Mon, Sep 21, 2009 at 3:11 PM, Brandon Ibach <
brandon.ibach@single-sourcing.com> wrote:

> Greetings, Adepters...
>
> I'm looking for a way to simplify the job of tracking down locations
> in source XML files that are causing errors in downstream processing.
> The error messages I get indicate the line number within the XML
> file, but it's hard to match this up with the location without loading
> the file into a text editor, and I'd rather be able to do this all
> inside Editor.
>
> I've done some digging in the documentation, but haven't found
> anything promising, yet. Is anyone aware of any facilities for getting
> line number information from Editor's parser, or would I have to run a
> separate parser, such as the Xerces parser via the Java interface, to
> get this information?
>
> Thanks!
>
> -Brandon 🙂
>

[bibach]

Hey, John...

This sounds like a good approach. Thanks!

-Brandon 🙂