Re: line number problem

Yes, good try. The moki DOM that is built up won't have line numbers
associated to it though, period. That can be output, then reparsed;
then I think we lose the original line numbers as we become dependent
on how the DOM was formatted when serialized.

The only solution I'm seeing here is to refer, at all times, not to
the copy of the source document in moki, but to the original parsed
document DOM that's held by PreprocessorResults. This can apparently
be done by returning a Document from some Java method then accessing
XPaths relative to that Document.

Hmm, not so bad. does it work? :)

Sean

On 7/13/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> I may be missing the point here, but if we know the line number of a
> problem relative to the moki document and if we know the line number of
> where the original source starts in the moki document, then ...
>
> Jo
>
> > -----Original Message-----
> > From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> > checker-request@w3.org] On Behalf Of Sean Owen
> > Sent: 12 July 2007 21:42
> > To: Laura Holmes; public-mobileok-checker
> > Subject: 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 Friday, 13 July 2007 13:01:40 UTC