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]
Other format: [Raw text]

RE: RFC XSLT Standard - "Further support for variable / parameter expansion of XSLT attributes"


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@ntlworld.com
work: Michael.Kay@softwareag.com

> -----Original Message-----
> From: owner-xsl-list@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Peter Bray
> Sent: 06 March 2002 04:13
> To: xsl-list@lists.mulberrytech.com
> Subject: [xsl] 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


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