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

[Tobias Reif <tobiasreif@xxxxxxxxxxxxx>]

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