RE: [xsl] XSLT/XPath 2.0: a USEFUL way to provide lexical info

Subject: RE: [xsl] XSLT/XPath 2.0: a USEFUL way to provide lexical info
From: "Matt G." <matt_g_@xxxxxxxxxxx>
Date: Sun, 06 Jan 2002 21:38:20
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Reply-To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: [xsl] XSLT/XPath 2.0: a USEFUL way to provide lexical info
Date: Sun, 6 Jan 2002 20:01:00 -0000

I think, as a user, I'd rather see a "lexical" XPath axis
(pair?), to let me hop back & forth between the tree w/ the
lexical constructs and without.  I think this would be much
easier to use, and its use could be better encapsulated within a
small number of templates.

It's a nice idea in principle, but I have some difficulty seeing how to flesh out the detail. The two main lexical components, entity references and CDATA sections, occur in the middle of character data, so it's not obvious how you would represent them on a separate axis.

Maybe I'm misunderstanding you, but I think the solution I was proposing is fairly straight-forward: preserve the same data model as in Appendix F of the 2001-12-20 XSLT 2.0 WD, but simply add an axis pair for hopping between two different trees--one which has the elements corresponding to lexical constructs, and the traditional one. If you're already in the lexical tree, then the 'lexical-tree' axis does nothing, however the 'structural-tree' axis would take you back to a traditional view of the document. Also, if a processor doesn't support this feature then both axes would do nothing.

For example, copying a tree fragment from the lexical tree should preserve the entity references. I don't know whether you want to force the user to also manually create the entity definitions, in the result tree, or just have the processor be smart about copying definitions for which there are references. Either is usable, and I imagine that when users are concerned about preserving entity references, they will simply copy all the entity definitions into the result tree.

Jeni is right that this would more than double the memory required to parse a document. But so what? Make it optional, and maybe processors will provide a switch to enable support for it, so you don't incur the overhead when you don't need lexical info.

Matt Gruenke

Join the world?s largest e-mail service with MSN Hotmail.

XSL-List info and archive:

Current Thread