- From: Sean Owen <srowen@google.com>
- Date: Tue, 19 Jun 2007 15:48:46 -0400
- To: "Roland Gülle" <roland@7val.com>
- Cc: public-mobileok-checker@w3.org
On 6/19/07, Roland Gülle <roland@7val.com> wrote: > After thinking a bit more at returning line and column direct from XSLT, > I think we need more than only the Saxon line-number() or Xerces > function. > > The document we transform with the XSLT is the moki document, > so we will get the position in the moki document. > We can return the URI (or internal ID) and (original) XPath and solve > this in a separate process, > or call an own function with the URI and XPath that get the line and > column information from the original document. > > So... only XSLT (1.0 or 2.0) will not solve this problem, there is > Java code needed (and you know - I'm not the Java guy). > Maybe with a small XSLT (and a Xerces process?), > where the XSLT gets the XPath dynamic from the function and the > source document represented by the URI. Yes, ideally the underlying Document / DOM representing the original source document includes line number information. It looked like Xerces provided this, but it actually doesn't. DOM Level 3 doesn't say this is coming as part of the spec either. I agree with Roland, Saxon's line number support only helps XSLT transforms, not parsing. Maybe we can "parse" documents with an identity transform to get line info. Or maybe Saxon's counterpart parser, Aelfred, also has this magic. Laura is looking at these. Beyond that... I'm not sure what we can do except concoct some kind of SAX parser that finds nodes and positions, locates the matching DOM node and somehow annotates it by replacing it with a wrapper implementation that also includes position info. Not impossible, but not nice. I think we should pursue this if Aelfred can't help us out. Sean
Received on Tuesday, 19 June 2007 19:48:59 UTC