[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Kienle, Steven C [IT/0200] wrote:
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.
Exactly.
Exactly! That's what I've been saying all along in this thread.
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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 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.If they were paying, either for the specs or for the products, then they might have more ability to influence the outcome...
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] is XSLT 2.0 implementable, Kienle, Steven C [IT | Thread | RE: [xsl] is XSLT 2.0 implementable, Elliotte Rusty Harol |
[xsl] ANNOUNCE: XSL-FO DTD is conve, xsl-list | Date | Re: [xsl] is XSLT 2.0 implementable, Charles White |
Month |
Keywords