Re: EXSLT 1.0 Proposed List

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Fuller wrote:
> this is an interesting thread, basically asserting that XSLT v1 + EXSLT
> = XSLT 2.0 with schema fun;
> 
> I must admit that I to am using XSLT 2.0 and mostly ignoring the schema
> stuff (seems to pleasantly go into the background, barring some
> non-intuitive implicit casting fun). There is also a serious performance
> gain using XSLT 2.0 which is making it a compelling answer to some hard
> XML processing problems.
> 
> a few musings, to broaden it past the typical XSLT 1.0 vs XSLT 2.0 arg;
> 
> * is it silly to see something like EXSLT inside of XQUERY and XSLT
> v2.0....not sure, esp if its just an EXSLT wrapper around native
> functionality.

Do you mean is it silly to have EXSLT 1.0 used from XSLT2/XQuery?  Or do
you mean is it silly to have a community standard for XSLT2/XQuery
extensions (let's call it EX2).  If the former, I do think it's not
silly but largely unnecessary.  EXSLT 1.0 as proposed does provide a few
things that X*2 doesn't, but that's a small proportion.  If you mean the
latter, my personal goal has always been that we get EXSLT 1.0 out (for
XSLT 1.0) and thus get it to a milepost, at which point we can make a
clearer decision about support for XSLT2.  My guess is that we'd end up
with a fork in EXSLT: one branch for XSLT1 and the other for XSLT2.

> * is it silly to envision EXSLT embedded in any XML markup ? to be
> processed by whatever XML processor acts upon it?

I guess no sillier than to envision XSLT embedded in other languages.
One could consider XUpdate to be such an embedded case, to some small
extent, so i don't think the idea is silly at all.  Then again, I don't
think it's an idea we should factor into any of the decisions while
developing EXSLT 1.0.  I think for maximum clarity we should think of
them purely as XSLT 1.0 extensions, and not as a general purpose
"microformat" (if you will).

> * it does make me a little nervous seeing something like XPATH bloat and
> throw lots of diverse functionality under a catchall fn: namespace

You mean XPath 2.0 makes you nervous?  Yes.  I agree.  I think we did
the right thing in EXSLT with introducing namespaces.  It's a bit of a
pain to have to declare the namespace for all the modules you use, but
the payback comes in modularity and clarity.  For one thing, I can look
at the top of any sane (using the Joe English defintion of sanity)
XSLT+EXSLT document and immediately see just what extension facilities
are being used.

> * could other efforts like exist.sourceforge.net striking could
> seriously benefit from a more standardized approach to function libraries

I don't know, but can we afford to be more ambitious right now than to
just wrap up a set of useful extensions for XSLT 1.0?

> * should we consider looking at XSLT 2.0 implementations (along with our
> existing EXSLT,MSXML, JS, XSLT1)?

Looking at them in what way?  I don't understand this question.

> I personally would like to see EXSLT broaden its appeal/usage; though I
> am unsure of what it means to XSLT v2...perhaps through  new modules 
> and  submissions there maybe more uptake...who knows. First things first
> and thats to knock what we have now into a good foundation.

Judging from everything I see, EXSLT already has quite broad appeal.  I
think if we start stretching to broaden it, we'll dilute our focus, and
that paradoxically, we could end up *losing* appeal that way.  IMO a lot
of the painful excess of XSLT2 comes from its trying too much to be all
things to all people.


- --
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD8iNe+753i3CmRSQRAhXpAJ4hisxMCacsPKhFdoirqXDJnG5G+gCcDN1W
XWmJhPZ6SSTgn4guD0+107Y=
=BH+T
-----END PGP SIGNATURE-----