Re: [xsl] why not match text()? (fork from "Novice Question - matching entire text children")

Subject: Re: [xsl] why not match text()? (fork from "Novice Question - matching entire text children")
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 21 Dec 2010 12:16:58 -0500

On 12/20/2010 8:28 PM, Imsieke, Gerrit, le-tex wrote:
After cleanup, the result of

<xsl:stylesheet version="3.0"
xmlns:xsl = "";
xmlns:xs = "";>
<!-- 3.0 only because of round($arg, $precision) -->
<xsl:output method="text"/>
<xsl:template name="main">
<xsl:variable name="xsldocs"
<xsl:variable name="file-count" select="count($xsldocs)" as="xs:double" />
<xsl:variable name="text-in-pattern-count"
select="count($xsldocs/*/xsl:template[matches(@match, 'text\(\)')])"
as="xs:double" />
Files: <xsl:value-of select="$file-count" />
Matches: <xsl:value-of select="$text-in-pattern-count" />
Average: <xsl:value-of select="round($text-in-pattern-count div
$file-count, 2)" />


Files: 971
Matches: 971
Average: 1

The identical value of 971 for the matches seems to be purely
accidental. When looking for 'node()' instead of 'text()', match count
is 644; when looking for 'br', it is 187.

Very interesting. (Even if it could do with a bit more refinement, to exclude e.g. match="p[empty(text())]". Someone else can write the XPath parser to do that.)

It would also be interesting to see the distribution of these templates among stylesheets, and whether they cluster.

For example, do they turn up more often in near-identity transforms than they do in HTML or XSL-FO production transforms?

There were all kinds of problems during cleanup, ranging from unresolved
svn conflicts over unterminated elements (= abandoned work in progress),
illegal UTF-8 characters to symlinks. We need to think about
well-formedness checks on the file system level.
(These days one has to add: If mankind survives, i.e., unless JSON gains
Complete World Domination.)

I'm not worried about JSON. For them that wants it, it's useful. I still see XML/XSLT as the state of the art document production technology. And the fact that JSON is there on one side (breathing down XSLT's winsome neck), and XQuery on the other, actually just takes the pressure off XSLT to be all things to all people.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
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

Current Thread