xml/xsl 2.0 comments

finally went through with fine tooth comb the specs,

here are some general comments, errors, etc ( will refine with comments made
from xsl-list )

------------------------------------------------
issue 1.2: a look at the transquery method ( www.transquery.org ) currently
being proposed by Evan Lenz  addresses this issue, though admittedly and
probably
rightly so is created from the 3rd party authors point of view ( no
additions, or special
elements added to XSLT, other then a globally agreed upon xsl:param )

------------------------------------------------

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.

The reasoning for streamlining the language is sound, i.e. 'why does XPATH
have to reproduce all this functionality when it can be found in XSLT' (
albeit with some small adjustments ); i dont see that this proposal is
mutually exclusive to the proposed XPATH implementation; sometimes so
whereby Jeni's tome of a description is spot on with respect to the addition
of xsl:item and the updated xsl:function ( with resulting removal of
xsl:result), i dont think there requires any backpressure on the XPATH;
heterogenity is a good thing, even when reproducing the exact same
functionality; so what i hope for is that the proposed syntatic additions
and changes exactly replicate XPATH functionality.

------------------------------------------------

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

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.

------------------------------------------------
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=","/>
------------------------------------------------

+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 ?

I will aggregate some common use cases for this, to further prove this
point.

------------------------------------------------

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.

------------------------------------------------
<xsl:apply-tranformation/ >
originally suggested by David Carlisle 10 Jan 2002

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 point is that an XSLT author, not a Java or c++ coder should also be
able to constuct
pipelines of processing.

------------------------------------------------

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 ?

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

------------------------------------------------

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

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
?

thats it for now, checking out regexp stuff now, and thx to all the
informative threads over the past few
weeks, has made interesting reading.

cheers, jim fuller

Received on Wednesday, 16 January 2002 05:52:33 UTC