RE: XSLT/XPath 2.0: a USEFUL way to provide lexical in

Play the video

Subject: RE: 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:  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. http://www.hotmail.com

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

Current Thread
XSLT/XPath 2.0: a USEFUL way to provide lexical info Matt G. - Sun, 6 Jan 2002 03:16:29 -0500 (EST) Jeni Tennison - Sun, 6 Jan 2002 08:46:40 -0500 (EST) Michael Kay - Sun, 6 Jan 2002 15:00:35 -0500 (EST) <Possible follow-ups> Matt G. - Sun, 6 Jan 2002 16:37:28 -0500 (EST) <= Michael Kay - Mon, 7 Jan 2002 04:47:23 -0500 (EST)

<- Previous	Index	Next ->
RE: XSLT/XPath 2.0: a USEFUL , Michael Kay	Thread	RE: XSLT/XPath 2.0: a USEFUL , Michael Kay
Re: the problem with include , Matt G.	Date	RE: the problem with include , Matt G.
	Month

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Subscribe in XML format

RSS 2.0
Atom 0.3

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >