[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RFC XSLT Standard - "Further support for variable
5.1 (xsl:output) is already done in the XSLT 2.0 WD (in fact, it was done in XSLT 1.1). I must admit I thought we had changed xsl:message to allow an AVT (4.1) and was surprised to discover that we hadn't. I think there will be some resistance from members of the WG to changing those attributes whose values are QNames of objects defined in the stylesheet (mode, template name, use attribute sets). Compiled languages generally don't keep their symbol tables around at run-time. There's also the problem of keeping namespace declarations around at run-time (though the key() function sets a precedent). It's also hard to think of many languages (COBOL is the only one that comes to mind) that allow a function or subroutine to be called by supplying its name as a string. XSLT is moving in the direction of stronger typing, allowing more detection of errors such as supplying the wrong number or types of arguments to a template or function, and this proposal therefore runs against the grain. Nevertheless, I'm personally sympathetic to moves that make the language more dynamic. In an interpretive system like Saxon it's very little effort to implement. Some of the existing dynamic features (such as the attributes to xsl:sort) probably cause more difficulty than the changes proposed here. Michael Kay Software AG home: Michael.H.Kay@xxxxxxxxxxxx work: Michael.Kay@xxxxxxxxxxxxxx > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Peter Bray > Sent: 06 March 2002 04:13 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > Subject: RFC XSLT Standard - "Further support for variable / > parameter expansion of XSLT attributes" > > > > > Greetings All, > > I thought I would propose a set of concrete changes for your > comment with respect to the XSLT standard and the idea of > > "Further support for variable / parameter expansion of XSLT > attributes" > > The syntax is that of Mulberry Technologies excellent "XSLT and XPath > Quick Reference" http://www.mulberrytech.com/quickref/index.html. > > Most these changes are out of my experience trying to merge HTML and > XSL:FO Style Sheets where the common processing out weighs the > generation of appropriate tags for the results file. > > Deferred Processing: The term I'll use to indicated at a level of > indirection or abstraction has been added to the style sheet to defer > the generation of tags to a common routine (eg. named templated) > > I welcome all feedback on the validity and usefulness of > these recommendations and hope the list can come up with something > which further improves XSLT and is acceptable to the W3C Working Group > on XSL and by the XSLT implementation community. > > Regards, > Peter Bray > Sydney, Australia > > > > Change Set 1 > ============ > > Change Instance 1.1 > > Element: xsl:apply-templates > Attribute: mode > > Current Defn: qname > Purposed Defn: {qname} > > Reasoning: When deferring processing to common routine, the > routine can lose it generality if mode parameters are > required to any embedded <xsl:apply-templates>. > > Example: Desired Code (Not currently possible) > > <xsl:template name="generateTableRow"> > <xsl:param name="label"/> > <xsl:param name="match"/> > <xsl:param name="count"/> > <xsl:param name="mode" select="''"/> > > <xsl:if test="count($count) > 0"> > ... > <xsl:apply-templates select="$match" mode="$mode"> > > Comment: Unfortunately an <xsl:choose> has to be placed around > the <xsl:apply-templates> "call" and each mode has to > be manually coded / enumerated. > > Notes: The empty-string as a parameter to the > attribute "mode" > should be treated as if the "mode" attribute was not > present. > > Change Set 2 > ============ > > Change Instance 2.1 > > Element: xsl:element > Attribute: use-attribute-sets > > Current Defn: qnames > Purposed Defn: {qnames} > > Reasoning: The <xsl:element> tags allows the dynamic > determination of > the tag name (name="{qname}") but then fails to allow > the developer > to specify dynamically the associated attribute set. > Dynamic tag > generation is very useful in merged HTML/FO style > sheets, but as > nearly all FO tags require attributes to control > final output, the > usefulness of <xsl:element> is diminished. > > Notes: This change has already been implemented in xsltproc (from > libxslt). If not already supported (and I believe it is) > <xsl:attribute-set> must support the definition of empty > attribute sets. > > Change Instance 2.2 > > Element: xsl:attribute-set > Attribute: use-attribute-sets > > Current Defn: qnames > Purposed Defn: {qnames} > > Reasoning: Consistency with Change Instance 2.1 > > Notes: I personally don't feel that this change would add > a great deal > of flexibility to XSLT, but I'm likely to be proved > wrong here. > But I do feel that "consistency" in a "language" is extremely > important. > > Change Instance 2.3 > > Element: xsl:copy > Attribute: use-attribute-sets > > Current Defn: qnames > Purposed Defn: {qnames} > > Reasoning: Consistency with Change Instance 2.1 > > Change Set 3 > ============ > > Change Instance 3.1 > > Element: xsl:text > Attribute: disable-output-escaping > > Current Defn: yes|no > Purposed Defn: {yes|no} ie: allow variables / parameters > > Reasoning: Flexibility in merged style sheets > > Change Instance 3.2 > > Element: xsl:value-of > Attribute: disable-output-escaping > > Current Defn: yes|no > Purposed Defn: {yes|no} ie: allow variables / parameters > > Reasoning: Consistency with Change Instance 3.1 > > > Change Set 4 > ============ > > Change Instance 4.1 > > Element: xsl:message > Attribute: terminate > > Current Defn: yes|no > Purposed Defn: {yes|no} ie: allow variables / parameters > > Reasoning: Flexibility and ability to write debugging and > assertion style named templates. > > Change Set 5 > ============ > > Change Instance 5.1 > > Element: xsl:output > Attribute: all attributes > > Current Defn: as appropriate to attribute > Purposed Defn: {as appropriate to attribute} > ie: allow variables / parameters > > Reasoning: Currently if you manage to write a single merged style > sheet, you must then create trivial wrappers for each intended > output style and set the values of each attribute of > <xsl:output> appropriately, before including the merged style > sheet. > > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|