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

> 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.

OK, I see now what you're getting at. It's still something that affects the
core engine in a way that the current proposal doesn't, but I'll have a
think about the implications.

Mike Kay

  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
>
>


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