This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1289 - String variables in the stylesheet
Summary: String variables in the stylesheet
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows 2000
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-03 11:18 UTC by David Carlisle
Modified: 2005-05-11 09:41 UTC (History)
0 users

See Also:


Attachments

Description David Carlisle 2005-05-03 11:18:19 UTC
The stylesheet has lots of variables initialised using the (equivalent) forms
  <xsl:variable name="DOT">.</xsl:variable>
  <xsl:variable name="SLASH"><xsl:text>/</xsl:text></xsl:variable>

It's something of a FAQ over on xsl-list that this is rather inefficient
as it makes a result tree fragment (or document node in XSLT2) that is more
expensive than a string to build, and has to be repeadedly coerced to a string
when used. Efficiency isn't really the main concern here, but as a stylesheet
appearing in a rec-track document it might be used as an example code
and also, as the only normative definition of xqueryx it may be reasonably
expected to be used in running XqueryX implementations as a first pass
converting XqueryX input to Xquery. If the stylesheet were converted to XSLT2
this would become more of a problem, as XSLT2 is rather less inclined to
automatically coerce between different types.

  <xsl:variable name="DOT" select="'.'"/>
  <xsl:variable name="SLASH" select="'/'"/>

would declare these things as strings.

There are also one or two variables that are "dead code" for constructs that are
no longer used. For similar reasons these ought to be dropped, eg

  <xsl:variable name="CDATA_BEGIN">

David
Comment 1 Jim Melton 2005-05-11 00:39:58 UTC
Your comment identifies items for which the specification is not erroneous, but
for which best practices would indicate specifying the items differently.  We
will attempt to make the changes you've indicated and implied, but will not make
them if the disruptions to the document become too great. 

Please let us know if you agree with this resolution of your issue, by adding a
comment to the issue record and changing the Status of the issue to Closed. Or,
if you do not agree with this resolution, please add a comment explaining why.
If you wish to appeal the WG's decision to the Director, then also change the
Status of the record to Reopened. If you wish to record your dissent, but do not
wish to appeal the decision to the Director, then change the Status of the
record to Closed. If we do not hear from you in the next two weeks, we will
assume you agree with the WG decision.
Comment 2 David Carlisle 2005-05-11 09:41:16 UTC
I'm happy to leave fixing (or not) these to the editor's discretion and am
closing the report as requested.