At 08:28 AM 10/18/00 +0200, Eric van der Vlist wrote:
As mentioned by James Clark [1] and per the XSLT 1.0 specification [2],
"document() already supports XPointer" and the support of XPointer by
XSLT is a matter of implementation by the different XSLT processors.
Could the XSLT processors authors (or supporters) let us know what is
the status of XPointer support in their products ?
This is interesting because it touches on something I've come up against.
It really amounts to a feature idea for XSLT/XPath (2.0?), but, since (as I
understand it) XPointer is a superset of XPath, it seems to be directly
related to this question. (I also second the motion to hear what
implementors are doing with XPointer.)
I've developed some stylesheets for analytical text processing work that I
think are really cool, but that quickly push up against limitations in the
XPath data model. Basically I'd like to "see into" text nodes.
An example: I have a concordancing program that generates an HTML page of
hits on a string. It uses the contains() function to assess whether a
string occurs within an element, snagging the element when it does. So far,
so good. But if I want to mark up those strings (say, turning them all red
in my output), things get a bit tricky. I run a recursive function over the
text node, pulling out each string as I get it. (See below.)
Wouldn't it be nice if I could select out just these strings for
processing? Or match on them? I understand this will probably mean creating
node sets on the fly (because I'd be breaking up text nodes into pieces),
but apparently XSLT 1.1 will let me do that.
This would presumably require some kind of extension to XPath. Is there
anything in XPointer that could be brought to bear on this? Is it something
the Powers That Be are ready to think about for the primary source tree,
not just something addressed by document()?
The benefits would be huge effectively broadening the scope of the kinds of
processing that could be done nicely with XSLT. Data mining, adding markup
based on analytical work, up-conversion from flat formats, etc. etc. Not to
mention supporting string-replacement much more easily than requiring all
that ingenious (but abstruse and heavy-duty) code our fellow list-members
have been ambitious enough to compose....
Now don't all go saying "Perl" to me....! I think XSLT is great; it
reflects the way I think about markup so I want to be able to do as much as
I can in it.
Cheers,
Wendell
-----
This is a function that will find and wrap all occurrences of a string in a
given text node in some kind of markup (to be provided by the
"displayfound" template that this one calls). Wouldn't it be nice if this
were all built in? Maybe so I could select out more than one different
string value at once, say?
<xsl:template name="segmentfunc">
<xsl:param name="procstring">
<!-- the string to be processed. Trimmed recursively until
all occurrences have been isolated and passed to
'display'. -->
<xsl:value-of select="."/>
</xsl:param>
<xsl:choose>
<xsl:when test="$find and contains($procstring, $find)">
<xsl:value-of select="substring-before($procstring, $find)"/>
<xsl:call-template name="displayfound"/>
<xsl:call-template name="segmentfunc">
<xsl:with-param name="procstring"
select="substring-after($procstring, $find)"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$procstring"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list