Re: [xsl] Re: Getting info of runtime failure in saxon environment

[Wendell Piez <wapiez@xxxxxxxxxxxxxxx>]

Hi,

To what Mike said I'll add only a few points:

1. This discussion isn't on topic for XSL-List, so we should probably
take it to another venue or off list.

2. In the situation you describe, the culprit is clearly the process
that generates data that cannot be parsed by a conformant XML parser,
and yet represents it (wrongly) as "XML". Ideally, your defense would
be "this is not XML, for which the specification is clear and
well-understood: give me XML". If you can't do that, your problem is
not really a technical one and you need to approach it as a user
support issue (helping them to fix their data or processes) -- even if
the people responsible write code and don't consider themselves to be
"users".

Karl, I know you know this and I'm not unsympathetic. But this is part
of why the question is off topic. It's kind of like they have a
machine that is sending letters in the mail (remember those) with
incomplete addresses, and you are trying to run the post office.

3. Your search engine is a much better source than I am to help with
the question of lightweight XML editors. I live and breathe oXygen
these days, but some would say it's no longer very lightweight,
although they do have a "Developer" release that is lighter than the
full product. Nevertheless there are still free editors to be found.

So ask your friendly search engine for "free XML editor
Java|Linux|Mac|Windows|whatever" and see what you get. I just did a
little of this and what I saw looked promising. (However, I think you
probably want an editor that can process XML in batches, which
freeware may not often do.)

You can also integrate a call to an off-the-shelf parser into most
plain text editors, although these will often run into the problem
Mike just mentioned since they're not built for this job.

Cheers, Wendell


On Wed, Feb 27, 2013 at 5:41 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> Note that the reason some parsers fail to provide location information for
> an encoding error is that in a properly layered architecture you need to do
> decoding before you start recognizing line endings, which means that the
> information about line numbers is typically not available at the point where
> the decoding error is detected. The layer that does know about line endings
> can intercept the error and add line number information, but the decoding
> layer may well be "reading ahead" by several thousand characters, making the
> location information unreliable. So Firefox is either smart, or lucky. Or
> wrong.
>
> Michael Kay
> Saxonica
>
>
> On 27/02/2013 09:36, Karlmarx R wrote:
>>
>> Further, while so far IE browser was used, just now I tried with firefox,
>> and surprisingly, that seesm to give line num, column details! which I think
>> should meet their requirement.
>> eg:
>> XML Parsing Error: not well-formed
>> Location: file:///C:/IT.....abc.xml
>> Line Number 130, Column 1:
>>
>> But still any additional replies to my previous questions would be of
>> great help going forward.
>>
>> Thanks.
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^