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

["cutlass" <cutlass at secure0 dot com>]

From: "Michael Kay"

[comments snipped throughout]
> Jim Fuller (cutlass):
> Are you going to post a copy of this to xsl-editors (please)?
done

> 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

yes, its a logical and strong arguement to not duplicate functionality, but
at some point either the requirements for XPATH, XQuery and XSLT will
converge or diverge at some point.

I have noticed that XSLT/XQUERY destiny are intrinsically tied at the
moment, maybe its because a lot of requirements are the same ( and both have
the ability to address 100% of the XQuery use cases )....... and if this
happens we should nail our colors to the post of what name to use and just
have the WG streamline itself and work as an entire group for this one
thing.

i am certain that things will go much quicker for XSLT 3.0 ( hehe, my
personal choice for the name ) if convergance occurs.

personally i see convergance, but the questions will only get answered in
commercial implementations.

so in the spirit of MS word allowing one to do the same thing 20 different
ways, i have no problem with allowing both XPATH and XSLT to do the same
thing, for the time being ( though this makes more work for the
implementators ).


> 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"/>)

yes, and yes to Jeni's response.... hehe forgot we dont need named templates
anymore.....

> > '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?'
>
> 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.

i really dont feel comfortable with the thought that 2 vendors are going to
implement a
particular 3rd party function in the same way to the point where we will
want to have a
facility to map these functions together.

i like the idea of identifying a vendor's function vs. user function, but I
agree with JT that the namespace in any event should be different

> 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

using vendor function binds you to vendor implementation,

what possibly you are saying is that an automatic  function-available() call
is being made whereby branching may occur..

> 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.)

will employ time-space folding device and come up with a few and send to
xsl-editors

> > 14.6 Date-Time Format functions
>
> We decided administratively that since XSLT is concerned with producing
> human-readable output, and XQuery isn't, we would handle this requirement

this is reasonable assumption

> 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.

once again something that addresses most of the situations, i always thought
of XSL-FO as the possible repository of such formating, yes we want to do it
native within XSLT, but formating to me comes under XSL-FO.

> > <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...

hehe, yes yes

> 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.)

the point was unclear on my part, yes as a programmer i can create
pipelines, but i see great potential of formalising something for an XSLT
author, and this is attributed to the success of the Cocoon sitemap stuff;
its more syntatic sugar as one can definately create pretty much well the
same thing in Native XSLT. sometimes sugar helps with getting the concept
across.

> 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).

yup

> 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

no, i was unclear as always.

> used (by some implementation-defined API) to locate the result tree in

the keyword here is API, i would like to put the decision of serialization
into the hand of the XSLT author.

> 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.

this is a great boon and a logical break point

>
> Another possible candidate is evaluate(), if we decide to include that.

possibly the problem with evaluate is simply a matter of constraining its
scope to the generation of Dynamic XPATH statements which takes up most of
the use cases within XSLT.


thx for the comments,
jim fuller


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