Re: Is XHTML a dead end?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Tim Bray <tbray@textuality.com> was heard to say:
| On Friday, September 27, 2002, at 01:09 PM, Eric van der Vlist wrote:
|
|>> For example... suppose we had some nice modern XHTML2 with
|>> properly-nested DIVs and so on, and hyperlinks scattered around.
|>> Suppose I wanted to produce a nested table of contents with just
|>> hyperlinks, losing all the other text; basically lose anything that's
|>> not a <div>, <h[0-8]>, or hyperlink.
|>>
|>> How would the approaches compare if the source were XLink vs HLink?
|>
|> In this case, the transformation would probably be easy enough that we
|> can try to do it in one pass with HLink as with XLink.
|
| Really?  Now we're getting somewhere.  I know this is asking a lot,
| but I am far from an XSLT virtuoso... could someone do the XSLT?
| Here's what I'd like: given an XHTML2 instance, produce another one
| that keeps only DIV tags, H1-H8 elements, and hyperlinks
| (a) in the case that they're identified by HLink
| (b) in the case they're identified by XLink (for complex links I think
| you just need the parts with xlink:type attributes, but if that's
| wrong let's discuss it).
|
| I think the outcome of this exercise would be real useful in helping
| us understand the real practical operational differences between
| deploying HLink and XLink in the field. -Tim

I was hoping someone else would step up to the plate on this one, as I
agree it's an interesting exercise.

Eric V. posted a stylesheet to do some XLink processing recently. It
contained lots of very generic matches (match="*" and match="@*").
Templates of that sort are problematic if you want to build a
stylesheet that can be extended, so let's look at a different example.

I have an experimental extension to my DocBook stylesheets that allows
XLink to be used on most inline elements. I deal with it roughly like
this (I'm simplifying a little, you're welcome to check out the XSL
stylesheets at http://sf.net/projects/docbook for all the details):

<xsl:template match="phrase">
  <xsl:call-template name="simple.xlink">
    <xsl:with-param name="content">
      <xsl:apply-templates/>
    </xsl:with-param>
  </xsl:call-template>
</xsl:template>

The idea is that this code will generate a link around the content of
the phrase element iff xlink:href occurs on phrase.

The simple.xlink code looks like this:

<xsl:template name="simple.xlink">
  <xsl:param name="node" select="."/>
  <xsl:param name="content">
    <xsl:apply-templates/>
  </xsl:param>

  <xsl:variable name="link">
    <xsl:choose>
      <xsl:when test="$node/@xlink:href
                      and (not($node/@xlink:type) or $node/@xlink:type='simple')">
        <a>
          <xsl:if test="@xlink.title">
            <xsl:attribute name="title">
              <xsl:value-of select="@xlink:title"/>
            </xsl:attribute>
          </xsl:if>

          <xsl:attribute name="href">
            <!-- In real life, this is more complex in order to deal with
                 xpointer schemes and the fact that #foo needs to be treated
                 specially -->
            <xsl:value-of select="@xlink:href"/>
          </xsl:attribute>
          <xsl:copy-of select="$content"/>
        </a>
      </xsl:when>
      <xsl:otherwise>
        <xsl:copy-of select="$content"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:variable>

  <!-- this is to unwrap nested <A> elements. (Not allowing nested anchors is dumb!) -->

  <xsl:choose>
    <xsl:when test="function-available('suwl:unwrapLinks')">
      <xsl:copy-of select="suwl:unwrapLinks($link)"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="$link"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

How could this be done in HLink?

Something like this does the same job:

<xsl:template name="simple.hlink">
  <xsl:param name="node" select="."/>
  <xsl:param name="content">
    <xsl:apply-templates/>
  </xsl:param>

  <xsl:variable name="hlinks"
                select="//h:head/hlink:hlink[@namespace=namespace-uri($node)
                                             and @element=local-name($node)]"/>

  <!-- Dealing with multiple matching HLinks would be...ugly -->

  <xsl:variable name="href">
    <xsl:for-each select="$node/@*">
      <xsl:if test="concat('@', local-name(.)) = $hlinks[1]/@locator">
        <xsl:value-of select="."/>
      </xsl:if>
    </xsl:for-each>
  </xsl:variable>

  <xsl:variable name="link">
    <xsl:choose>
      <xsl:when test="$hlinks and $href != ''">
        <a>
          <!-- Hlink doesn't seem to support titles... -->
          <xsl:attribute name="href">
            <!-- In real life, this would be  more complex in order to deal with
                 xpointer schemes and the fact that #foo needs to be treated
                 specially -->
            <xsl:value-of select="$href"/>
          </xsl:attribute>
          <xsl:copy-of select="$content"/>
        </a>
      </xsl:when>
      <xsl:otherwise>
        <xsl:copy-of select="$content"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:variable>

  <xsl:copy-of select="$link"/>
</xsl:template>

So I guess it's not much harder to process the links with XSLT. I
think there might be performance issues, but maybe more cleverness
with keys or something could reduce that.

I did find a few HLink questions when I was writing this:

1. How does one do titles?
2. It appears that hlink supports elements from any namespace, but
   it doesn't support namespace qualified attributes. (i.e., there's a
   namespace/element pair on hlink, but there's no locator-namespace for
   the locator attribute.
3. I think the "onRequestSecondary" is dreadful. Surely there need to be
   tertiary, etc. methods if there need to be secondary methods.
4. Prohibiting nested links is silly.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | Most human beings have an almost infinite
XML Standards Architect | capacity for taking things for
Sun Microsystems, Inc.  | granted.--Aldous Huxley
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE9nLUkOyltUcwYWjsRArhwAJ9ynQFRNcWvfTwHPDDvoj78aBAkMACeLe5X
pNC9R6Y9GcDi/Gtlo4dzo8U=
=v7IX
-----END PGP SIGNATURE-----

Received on Thursday, 3 October 2002 17:23:31 UTC