RE: line number problem

It may be a slightly abstract, or abstruse, point but I think we should
be clear that when we are reporting an error, it is indeed against the
moki document's copy and not "the original". 

We shouldn't get too hung up on this but the point is presumably that
there may be "no such document" as the original, since it may be
dynamically generated and the "line number" may not be very interesting
from that point of view. Indeed, in a number of cases it will be "1" -
i.e. the original document is serialised as a character stream without
formatting - it's kind of what we recommend under MINIMIZE, after all.

Or to put it another way, the line number fulfils a secondary and not a
primary purpose. The point of it being there is to assist in the primary
purpose which is help a human find out what we are moaning about in the
results. 

So fwiw, I would be happy with reporting the line number relative to the
serialised moki copy and have error reporting tools do syntax
highlighting, or whatever, on that. From that pov an XPath expression
might even actually be more use. At least I think we should consider
putting it in.

Jo


> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Sean Owen
> Sent: 13 July 2007 14:02
> To: Jo Rabin
> Cc: Laura Holmes; public-mobileok-checker
> Subject: 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:15:17 UTC