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

[Peter Bray <pdb_ml@xxxxxxxxxxxx>]

Greetings All,

	Could the change set 1 - 3 be part of an official extention to the
XSLT 2.0 Core. Being an official extension means that syntax and
semantics are defined for all implementations. But being an extension
means that the compilation based engine writers (and others) just
choose not to support a given extension that their engine can not
handle.

	Also I believe there is syntax in XSLT 2.0 to support a style sheet
saying what extensions it uses, just making it clear to the reader that
such non-core features are in use.

	I think this would be (what is called) a "WIN-WIN" situation ;-)

Peter

 --- Michael Kay <michael.h.kay@xxxxxxxxxxxx> wrote: > 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: [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
>  

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list