Re: [xsl] is XSLT 2.0 implementable? (was: N : M transformation)

Subject: Re: [xsl] is XSLT 2.0 implementable? (was: N : M transformation)
From: Tobias Reif <tobiasreif@xxxxxxxxxxxxx>
Date: Tue, 04 Feb 2003 16:48:58 +0100
Kienle, Steven C [IT/0200] wrote:

Tobias Reif wrote:

If they were paying, either for the specs or for the products, then they
might have more ability to influence the outcome...

If it's true that $s rules the development of the specs (XSLT etc) more than anything else, then that's a very sad state of affairs IMHO.

Payment can be in items other that $s. A developer pays in effort to
develop or update an XSLT processor.

Yes, but "paying [...] for the products" describes paying $s (or else) to the developers of the implementation, AFAICS.

Two issues are mixed here:
a) Some specs are indeed influenced way too much my $s or corporate interest.
b) Implementers should, instead of saying "It's too much / too complex work so I won't do it" and not provide feedback, provide constructive feedback to the XSLT WG.

If the spec is going to make upgrading
the processor too much effort, he has two choices:  Not do it or send
feedback to the WG.


There are more than enough ways to get feedback to the
WG; and I am fairly sure most, particularly those on this list, will not
ignore the comments simply because they are not from the $ paying members.
I've lost count of the number of times Michael Kay on this list has asked
people to provide him with use cases, etc. I have no idea how many did, but
I sure he wasn't asking just to be difficult.

The key is to not just say "It's too difficult;" but to say "I think this
section/point/feature is asking too much of developers and is likely to
prevent adoption of the new standard in new versions of XSLT processors."

Exactly! That's what I've been saying all along in this thread.

Back it up with constructive critiques and the standard can actually be
affected; just screaming "I can't do that; I give up!" and the specs

Absolutely and obviously true. As I said, I hope that all implementers who have any issues with or objections to the draft spec or parts of it should provide technical, reasoned, and informed feedback to the WG/authors and/or to the editor; that's the only way we will see XSLT 2.0 implemented. Parts of the current XSLT 2.0 look great, so it's worth it.



XSL-List info and archive:

Current Thread