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 17:16:15 UTC