RE: [xsl] xslt/xpath 2.0 comments ( long )

["Michael Kay" <michael.h.kay@xxxxxxxxxxxx>]

Jim Fuller (cutlass):

Are you going to post a copy of this to xsl-editors (please)?

Some observations attached.

Mike Kay

>
> ------------------------------------------------
> issue 1.2: a look at the transquery method

> www.transquery.org ) currently
> being proposed by Evan Lenz  addresses this issue
> ------------------------------------------------
> Jeni Tennison proposal of dealing with 'sequence constructors
> ' ( xsl:item
> and amended xsl:function syntax ) sends my spidey sense
> reeling, not quite
> sure if i can vocalise my concern.
> I foresee that sequences will be a 'unique' concept for
> people to adjust or
> learn( just after they've learned how to deal with trees) , i
> also foresee
> that the new XPATH syntax, though wildly expressive; will
> once again make it difficult for newbies.

Well, obviously any new feature is also something new to learn, and this is
something where we have to get the balance right. Because we've provided
sequences as an extension of the 1.0 node-sets, one can argue that we
haven't actually increased the number of concepts as much as it would seem.

Jeni's argument that we could do sequence manipulation in XSLT rather than
in XPath is something that we'll revisit in the WG. Personally, I would hate
to duplicate the functionality at both levels, and I'd like to have as much
syntax shared with XQuery as possible so long as it doesn't compromise the
design integrity of the language.

[comments snipped]
>
> 7.1.1 Passing Parameters to Templates
>
>
> ' Issue (add-type-to-with-param): Should we add a type attribute to
> xsl:with-param, for symmetry with xsl:variable and xsl:param? '
>
> +1 to this, makes sense
>
> ' Issue (with-param-verbosity): Should we introduce an
> alternative and less
> verbose syntax for passing parameters when invoking a template? '
>
> I was under the impression that one would be able to call a
> template using
> function like syntax; my:template(param,param,...)

No, there's no proposal to do that. Arguably, named templates are now
redundant, since you can always replace a named template with a function
(that returns a temporary tree), and call it as <xsl:copy-of
select="my:function(params)"/>; this would suggest that the case for
introducing a less verbose syntax for call-template is now rather weaker. (I
think the idea behind the issue was to allow a template named "my:tmpl" with
parameters x, y, and z to be called as <my:tmpl x="1" y="2" z="$v+3"/>)
>
> otherwise, is this where we could abuse sequences and place
> the param in a
> sequence?
>
> <xsl:call-template name="my:template">
> <xsl:with-param select="($x,$y)"/>
> </xsl:call-template>
>
> which may mean an option with <xsl:with-param/> would have
> no-name, and the
> sequence represents the physical order of <xsl:param/> within function
> template.
>
> ------------------------------------------------
> 7.3.1 Defining a Stylesheet Function
>
> 'Issue (user-functions-vs-vendor-functions): Should
> user-defined functions
> override vendor-defined functions of the same name, as
> specified here, or
> should it be the other way around?'
>
>  the vendor, at the very least, should implement their function with a
> namespace attatched, why would there be any overloading of
> functions, which
> could also be yet another bad thing with respect to security.
>
> If a user wanted to override saxon:evaluate() with their own
> function named
> saxon:evaluate(), i think an error should be thrown.

That would imply that if the user writes an emulation of saxon:evaluate in
order to allow a stylesheet written for Saxon to run under (say) Sablotron,
then the stylesheet containing this emulation will fail when it's run under
Saxon.

The alternatives: choosing the vendor's version of saxon:evaluate() in
preference to the user's version means that the stylesheet may produce
different results when run under different processors. In theory, a vendor
could return anything he liked in response to any extension function call by
arguing that he was calling his own implementation (sounds perverse, but
these things happen when it comes to running benchmarks and conformance
tests). Choosing the user's version in preference means that instead of
emulating saxon:evaluate(), the user would have to write a wrapper function
that makes the decision whether to call user code or to call the vendor's
version. This to me seems the cleanest solution.
>
> ------------------------------------------------
> 13.3 Examples of Grouping
>
> typographical error in xsl:value statement within 1st solution
>
> <xsl:value-of select="current-group()/@name" separator=",">
>
> should have closed ending
>
> <xsl:value-of select="current-group()/@name" separator=","/>

Thanks for spotting this.

> ------------------------------------------------
>
> +1 should allow grouping with other datatypes, this is not
> such a serious
> point for now, but i can see in the future an expansion of
> datatypes being
> included ( possibly all X Schema, etc ),  using grouping on
> dates would be
>  immediately useful.
> ------------------------------------------------
>
> 14.5 Dynamic XPath Expressions
>
> ++1
>
> definately require an eval() function along the lines of the
> currentsaxon:eval(); dont care where it lives... and in
> general this is
> no-brainer, admittedly its something that appeals to the less
> experienced user, but hey why not ?

We really need this kind of comment to go to xsl-editors; preferably with
some reasoning as to why you need this function. (Though I think we already
recognize that it's a useful capability for many users; the concerns are
about implementability in some environments, and also about potential misuse
of the facility.)
>
> ------------------------------------------------
>
> 14.6 Date-Time Format functions
>
>
> This is probably best served as within XPATH, instead of
> XSLT, which i believe is being proposed. Though i would like to see
> something
> lightweight and address 80% of the problems, then the
> xsl:number monster.

We decided administratively that since XSLT is concerned with producing
human-readable output, and XQuery isn't, we would handle this requirement
within the XSL WG for the moment, and then consider moving the solution into
the shared function library later. But the solution is likely to be a simple
function that can be called from XPath expressions.
>
> ------------------------------------------------
> <xsl:apply-tranformation/ >
> originally suggested by David Carlisle 10 Jan 2002

Actually it's been suggested by various people in various forms over a
period of time...
>
> I always thought that xsl:transform would be a better term,
> but keeping( and
> its used up already ) in step with the other 'apply' terms
>
> something like;
>
> <xsl:apply-transform source="$y" stylesheet="$x"/>
> with assoc. function form; apply-transform($y,$x)
>
> having this would allow for sophisticated pipelines of
> processing to be
> created, sort of what goes on with some xslt app engines like
> Cocoon and
> AxKit
>
> this gives the opportunity for getting away from the serialisation to
> physical file model that is being introduced/forced with the
> xsl:destination
> and
> xsl:result:document.

The whole idea of xsl:destination and xsl:result-document was to separate
the description of the result tree from any concerns about serialization. If
it's picked up in the right way by implementations (and by the JAXP API, for
example), then it enables a pipeline of transformations to be constructed by
the application (using one stylesheet for each transformation) in which the
result trees from one transformation can be referenced by URI independently
of their format and independently of whether or not they have been
serialized. (But this concept of enabling a pipeline of transformations to
be controlled from the application doesn't diminish the potential value of
being able to invoke a transformation from within a stylesheet.)
>
> ------------------------------------------------
>
> 17.1 The Principal Result Tree
>
> 'Issue (destination-element-name): Is it possible to find a
> better name for
> the xsl:destination element? The name xsl:principal-result has been
> suggested.'
>
> I am not convinved about the inclusion of a seperate element
> is necc., could
> this not be dealt with as an attribute to either xsl:stylesheet or
> xsl:output ?

The aim here is to separate things that concern the result tree from things
that concern serialization. (I can see us adding other attributes concerning
the result tree, for example something that says it should be validated
against a particular schema).
>
> Though this function and xsl:result-document are useful they
> constrain to
> the creation of physical files, with no abstraction for
> future pipelining to
> lets say an xml repository, which i suspect will have
> something to do with
> either a new attribute on <xsl:output/>.....

Perhaps you are assuming that because these elements assign a URI to the
result tree, the result tree must be stored on disk and therefore must be
serialized? That's an incorrect assumption. The idea is that the URI can be
used (by some implementation-defined API) to locate the result tree in
memory. Unlike the XSLT 1.1 facility, and many current implementations, the
idea is that the processor should be able to produce multiple result trees
even if it doesn't support serialization.
>
> ------------------------------------------------
>
> 19 Conformance
>
> 'Issue (conformance-modules): Should we introduce multiple conformance
> levels or modules, recognizing that serialization is a separate
> specification to which processors may or may not conform?'
>
> I was originally all for something like this; but now XPATH
> dependancy and
> some radical core changes within XSLT make it hard to see
> where the breaks
> occur. Maybe instead of identifying some of the more
> experimental aspects as
> non-core or advanced functions....hmmm

One candidate for a separate conformance module is serialization. Instead of
making the whole serialization spec use the word "should" rather than
"must", it would be better to say that implementations can choose whether to
implement serialization, but if they do, they must implement it as
described.

Another possible candidate is evaluate(), if we decide to include that.
>
> I am glad that the language binding has been recognized as a different
> kettle of fish and requires a seperate spec.... has this WG
> been formed yet?

No, I don't think anyone is actively pursuing this. I'd personally like to
see a Java binding in a future version of JAXP. The binding for 2.0 is going
to be considerably more complex than the 1.1 binding because of the increase
in the number of data types.


Mike Kay


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