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 s.th.
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.
Exactly.
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
remains.
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.
Tobi
--
http://www.pinkjuice.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list