Re: line number problem

Good point. I suppose I had imagined that the XSLT would operate on a
DOM that we manually build up in Java, and includes the real, original
DOM that was parsed from the source document including line number
info -- not a copy. Then the line-number-related methods should still
work.

But indeed, none of this works if you parse a moki document from
scratch in an XSLT since the original line number info is lost. Which
partially shoots its raison d'etre in the foot.

Better ideas? Unless what I sketched out above works, we're getting
more fenced in by using XSLT + moki by the day and think we need to
think hard about what this approach is gaining versus costing before
we go further.

Sean

On 7/12/07, Laura Holmes <holmes@google.com> wrote:
> Hey Sean,
> I wanted to run this by you before i went to the list with this issue:
>
> Again, I'm running into problems with recording line numbers. Here's the
> base issue: we are trying to call for line number reporting during the wrong
> part of the flow. We establish and record errors by analyzing the moki
> document. However, we only record line numbers in the original document
> parse. So, by the time we realize there is an error in the document
> regarding a certain best practice, we've already disassociated the
> information from the original document tree and therefore cannot report line
> numbers.
>
> Currently, the only time we have access to the line numbers is while
> creating the moki doc from the original source tree. One very ugly solution
> to this is placing a line number attribute to each feature we record in the
> moki document. We could also include a pointer to the original source tree
> in each resulting moki tree node, but that seems excessive if all we want in
> the line number. My concern is that this significantly changes the shape of
> the moki doc as it adds a lot more info and it also changes the java code a
> little. In order to record all the information we want, we'd have to add a
> line-number attribute to each node in the docContent and to other data we
> extract (like images, css, etc.)
>
> One other work around, but it's a complete hack, would be to retrace the
> origin of the error in the "XHTMLDocInfo/DocContent" of the moki doc, but
> that just seems really messy. Thoughts? Any brilliant ideas I'm not thinking
> of?
>
> Cheers,
> Laura
>

Received on Thursday, 12 July 2007 20:42:37 UTC