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

RE: Image size error reporting

From: Jo Rabin <jrabin@mtld.mobi>
Date: Fri, 13 Jul 2007 21:20:33 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B4483BA1@mtldsvr01.DotMobi.local>
To: "Sean Owen" <srowen@google.com>, "Laura Holmes" <holmes@google.com>
Cc: Roland Gülle <roland@7val.com>, "public-mobileok-checker" <public-mobileok-checker@w3.org>

This doesn't appear to have the air or elegant simplicity that one would hope!

I'm really sorry, I just don't have time to think or contribute on this in advance of next week's F2F meetings - but wonder if we should defer any major work till we have talked this though on some upcoming call.

> -----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 18:16
> To: Laura Holmes
> Cc: Roland Gülle; public-mobileok-checker
> Subject: Re: Image size error reporting
> On 7/13/07, Laura Holmes <holmes@google.com> wrote:
> > Let me make sure I understand:
> >
> > Re 1 & 2. After we build the moki document, from the DOM tree of the
> > original  document,  the moki is represented as a Java Document tree. At
> > this point, we invoke the java Transformer Factory to use the XSL files
> to
> > translate the moki document into a results document. You want to
> > reparse/rebuild the moki dom tree into a Saxon tree so that we can gain
> line
> > numbers from that tree when we feed it to the Transformer Factory? This
> > would be performed by getting the String representation of the moki
> Document
> > tree and then reparsing that string using Saxon.
> Yes. I think we need to take the Document, serialize it as a String or
> temp File or whatever, then reparse the whole thing back into a
> Document using Saxon. It's a bit redundant but then presumably the
> resulting Document contains line number information relevant to the
> moki document itself.
> > Re 3. From the resulting moki document, we can get line numbers using a
> > helper function. This helper function:
> > - determines value a = the line number in the moki doc of the location
> of
> > the original content of the xhtml file
> > - determines value b = the line number of the node where the error
> occurred
> > - returns the relative line number: b-a
> Exactamundo.
> > There are only a couple extra cases I anticipate. 1) I don't know
> exactly
> > how the CSS is being processed/represented.  If we want to report line
> > numbers of errors in CSS (which I think we decided we wanted to),  is
> the
> > original text of the CSS contained in the moki? If it is, that should be
> a
> Yeah but I think the CSS case is easy. There's no XPath for CSS; it's
> all got to be parsed out in Java anyway. I think our needs vis-a-vis
> CSS are so simple that this is fine (but I'm not sure anybody is on
> board with me here?). The CSS is in the moki doc, and can also easily
> be parsed into an array of Strings, one per line. Line number is
> trivial to determine then in any Java code testing CSS.
> > pretty simple fix. 2) We don't include all of the xhtml for the
> docContent
> > of the moki. We only record docContent starting at the beginning of the
> html
> > tag, which leaves out encoding and doctype. Seeing as how this
> information
> > is at the top of the file, I don't think it would be hard for the user
> to
> > find and correct, but we could also include these lines into the
> docContent?
> Fair point. I think this is why we want a "raw" copy of the response,
> including everything, as well as a copy of the nodes somewhere within
> moki (which won't include DOCTYPE or XML header, no). I don't think
> it's a big deal if line numbers are reported relative to the latter,
> which is already not quite the same as the original doc.
> Sean
Received on Friday, 13 July 2007 20:21:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:18 UTC