This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Defining XSLT functions in XSLT 1.0



> I feel that if we continue discussing various options, if we come up
> with more proposals and so on, we are likely to talk ourselves dizzy
> rather than come up with anything concrete.  It's my hope that having
> a vote will (a) allow people who don't feel they can voice their
> opinion on the list to voice it otherwise and (b) satisfy those people
> who disagree that the final specification is based on user demand, not
> political reasons or personal preference.

OK, but we should be sure that the lurkers are adequately informed, IMO.  I do 
agree that the discussions are rushing off in all directions.  Maybe we should 
pick a few votes on issues that *have* been hashed out thoroughly rather than 
a comprehensive ballot.

> I've only posted the questionnaire here - if there are other places
> where you think it should be posted, then please feel free to forward
> it.

Is Eric listening?  'twould be great for xmlhack to report on the poll, as 
long as we could properly convery all the issues to people who don't spend 
ungodly amounts of time reading xsl-list.

> After voting's tailed off, which I think should be around the end of
> the week, I will take them votes, collate them and inform the list of
> the results. The use of the email address in the XML is only so that I
> can uniquely identify a voter, which lets you change your vote if you
> need to - I won't be using them for any other purpose.
> 
> Based on the decisions indicated by the vote, we can then construct a
> specification of a set of XSLT extension functions and elements,
> following the scheme that's voted for.  I'm happy to do a first draft
> of that.

Euge!  Excellent!  And people who didn't really understand all the issues 
enough for this first vote get to see the results plainly defined, and they 
can raise stertorous opposition, and we can have a second draft.

Perhaps you'll regret volunteering <g>.

> This specification may then be used by implementers who wish to
> support the specification of user-defined functions in XSLT 1.0.
> Implementers are under no obligation to do so. Stylesheet authors are
> under no obligation to write stylesheets that use them. Anyone else
> can come up with and use their own specification as they desire. As a
> community-led initiative, anything that happens happens because of
> pure good will on the part of those involved.

I hope implementors can see this as a solid opportunity to provide a coherent 
body of practice through which we can better influence the W3C process.  I 
think influence from implementors is important, and I do think the various W3C 
groups take it seriously, even though I have no qualms railign against them 
when think I see pitfalls developing.  With efforts such as this common 
extansion effort, I think we get to make a more coherent argument than, say, 
Uche Ogbuji raving about Java politics <gg>.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]