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

Re: Time for an exslt for 2.0?

Subject: Re: Time for an exslt for 2.0?
From: "M. David Peterson" <m.david.x2x2x@xxxxxxxxx>
Date: Thu, 12 May 2005 06:04:40 -0600
Re:  Time for an exslt for 2.0?
Is this something that is possible to accomplish via the existing
EXSLT project path?  The impression I have is that maybe the interest
in this particular area has dropped off but I don't want to offend
anybody in that group by suggesting that this is the case.  Just that
this is the impression that I get.

What are the proper next steps for this?  It seems obvious that if its
possible to work through the existing project space then this would be
ideal.  Is this a possibility?

On 12 May 2005 12:35:52 +0100, Colin Paul Adams
<colin@xxxxxxxxxxxxxxxxxx> wrote:
> >>>>> "David" == M David Peterson <m.david.x2x2x@xxxxxxxxx> writes:
>
>    David> Are you thinking along the same lines in which the original
>    David> EXSLT project (assuming that my understanding as to why the
>    David> original project was started) was focused towards, in
>    David> essence adding to the mix the instructions and functions
>    David> that were left out of the spec for various reasons or had
>    David> since been realized as necessary?
>
> Not necessarily instructions and functions - anything that promotes
> writing portable stylesheets.
> The two issue I mentioned are cases in point.
> Dmitre added saxon:memo-function="yes" attributes to some of his
> prime-number-calculating functions. When I looked at these, I promptly
> realised the benefit, and implemented my own attribute in gexslt with
> identical semantics. But this meant coding BOTH attributes within the
> function definition. As Dmitre pointed out, for two processors this is
> just about OK, but if more and more implementations were to do the
> same thing, it would be frightfully messy to read, and a real pain to
> have to keep adding new attributes for each new processor.
> And having a standard way of accessing environment variables is
> another pure gain on portability (otherwise, if you need this
> facility, yopu are going to have to do a lot of unecessary coding with
> xsl:use-when - it's possible, but a nightmare for maintenance).
>
> Then there are things in the XSLT 2.0 spec. that are left entirely to
> the implementation (such as collation names - this is actually under
> discussion on the qt-comments list at the moment). It might be useful
> to have a set of standard collation names with known properties.
> --
> Colin Adams
> Preston Lancashire
>
>


--
<M:D/>

:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist

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.