This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: Unwrapping trees
- From: Norman Walsh <ndw at nwalsh dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Fri, 14 Jun 2002 07:55:03 -0400
- Subject: Re: [xsl] Re: Unwrapping trees
- References: <20020614102802.47168.qmail@web14508.mail.yahoo.com>
- Reply-to: xsl-list at lists dot mulberrytech dot com
/ Dimitre Novatchev <dnovatchev@yahoo.com> was heard to say:
| --- Jeni Tennison <jeni@jenitennison.com> wrote:
| I think that precisely defining the structure of the input is more than
| halfway progress towards a solution.
Yes. In this particular case, I'm exploring the ramifications of
"generalized linking" in DocBook: allowing basically any inline
element to be a link. That'd make just about arbitrary nesting
possible (but not, as per David's case, nesting of blocks inside
links, thankfully).
I see the options as:
1. Output <a href="1">foo <a href="2">bar</a></a>. Invalid HTML. Not a good
answer. (Making it valid HTML and having the browsers do the right thing
sure would be nice, though). Remarkably, PDF generated from FOs with nested
links seems to do the right thing.
2. Suppress inner anchors. So this becomes <a href="1">foo bar</a>. Valid HTML,
but quite a surprise for the author, perhaps.
3. Try harder to fix this. I could always write another extension function, I
suppose. But then I'll just get even more questions about why this doesn't
work with xsltproc.
4. Write the extension function in Python for xsltproc then figure out how to
get Jython supported in Saxon and Xalan so that I can reuse the Python
extension. Heh. The days just aren't quite that long, even if I get up at
an absurd hour. :-)
Be seeing you,
norm
--
Norman.Walsh@Sun.COM | The people who live in a Golden Age usually go
XML Standards Engineer | around complaining how yellow everything
XML Technology Center | looks.--Randall Jarrell
Sun Microsystems, Inc. |
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list