Re: [xsl] Poluting XSLT??? (Was Re: Designs for XSLT functions )

[Jeni Tennison <mail@xxxxxxxxxxxxxxxx>]

Hi Dimitre,

> I'd rather see more professional discussion on the ways to extend
> XSLT with new and necessary functionality.

What would 'more professional' entail?  Which aspects of the
discussion would you like to see more of?

> I have the feeling that the real implementors are watching with
> amusement (if not bored already) this and other threads and just
> throwing in a few words from time to time.

I think that's rather unfair on implementers like Uche, Steve and Mike
who have said much more than a few words. Uche has explicitly said
that he will implement whatever we come up with and has offered a
namespace for the extensions. I get the impression that Mike will
implement it too 'cos he just loves adding extensions to Saxon ;)

I agree, though, that it would be very good to hear more from the
Xalan and MSXML teams about their thoughts on the extensions we're
discussing.  It would also be good to hear from more people who are
using extension functions at the moment to see which ones they find
useful, and which we should therefore definitely be able to support.

> In this particular case:
>
> 1. Sometimes ago I proposed a "xsl:reference-of" element
> 2. Other people think now of "xsl:append"
>
> These two new elements will behave essetially as "xsl:copy-of", but
> with a small variation -- will output the same node -- not its copy.
>
> Isn't it best to say that we only need the same "xsl:copy-of"
> element with a slightly changed syntax and behaviour? Like:
>
> <xsl:copy-of select="expression" create-reference="yes|no">
>
> This is just an example, which shows that in many cases it could be
> possible not to add new elements to XSLT.

That would have to be:

<xsl:copy-of select="expression" exsl:create-reference="yes|no" />

You can add extension attributes to XSLT but they have to be in a
non-null namespace (and not the XSLT namespace).

My arguments against a exsl:reference-of or exsl:append element is
that (a) I have yet to see a use case where they are absolutely
necessary and (b) they add a new data type to XSLT, something which I
think we should avoid unless absolutely necessary.

> Maybe we need a separate mailing list, dedicated to XSLT language
> evolution and development, where implementors will be the driving
> force and perform more analytical work than sociological surveys.
>
> I hate politics, especially when there's an attempt to mix it with
> technology.
>
> Any attempt to extend a language by voting reminds me of "popular
> movements", "party meetings" and the well-known results of these in
> history.

I remember when I lurked on XML-Dev during the development of SAX and
XSchema feeling I didn't have much that I could positively add but
still wanted to have a say. That's why I thought that allowing people
to vote on the issues that had been discussed would give those people
a say. Turns out that everyone was skipping over the discussion,
objects to voting on religious or political grounds or basically
doesn't really care ;( Ho hum. Live and learn.

I am also very much aware that as I try to draft a spec, I am making a
lot of assumptions about 'consensus' that actually means 'what I
think' and I want to avoid that especially because I'm well aware of
my limitations - lack of implementation experience, lack of general
programming experience and so on.

So anyway, I'll try another approach - writing a draft based on what I
think (naturally informed by the discussions we've had).  Perhaps that
will rouse implementers to say "but I can't implement that!" and
authors to say "but I can't write this!".

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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