[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: is XSLT 2.0 implementable? (was: N : M transforma

Subject: Re: is XSLT 2.0 implementable? (was: N : M transformation)
From: Tobias Reif <tobiasreif@xxxxxxxxxxxxx>
Date: Tue, 04 Feb 2003 16:48:58 +0100
Re:  is XSLT 2.0 implementable? (was:  N : M transforma
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



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.