This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Support of XPointer


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@mulberrytech.com
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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]