W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > July 2007

RE: line number problem

From: Jo Rabin <jrabin@mtld.mobi>
Date: Fri, 13 Jul 2007 10:22:51 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4483ADC@mtldsvr01.DotMobi.local>
To: "Sean Owen" <srowen@google.com>, "Laura Holmes" <holmes@google.com>, "public-mobileok-checker" <public-mobileok-checker@w3.org>

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 15:38:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT