Re: [xsl] Re^4: ?XSLT Repository?

Subject: Re: [xsl] Re^4: ?XSLT Repository?
From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx (by way of B. Tommie Usdin)
Date: Mon, 20 Aug 2001 09:04:19 -0400
From: "cutlass" <cutlass@xxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [xsl] Re^4: ?XSLT Repository?
Date: Mon, 20 Aug 2001 09:11:47 +0100

David Marston writes

> I agree that it's out-of-scope for the W3C. I think that some people see
> it as an OASIS project because it can then have more validity and
> visibility. In other words, OASIS is already set up for coordination
> among several contributing engineers/designers, and specializes in XML
> development. Under SourceForge, it may get lost among the thousands of
> projects seeking contributions.

i can see your point.

> I should also mention Apache. The Apache XML project occasionally adds
> a new piece, like the XML canonicalizer that is now under consideration.
> A stylesheet library would probably not sit well with the rest of Apache
> XML, which is more about processors, servers, and similar modules of
> executable code.

and AxKit was just added i believe, yes there is a possible direction

>
> If you have one stylesheet or set of templates that you think is a good
> example, also consider sending it to Dave Pawson for the FAQ.
> .................David Marston

i agree that this probably has something to do with the XSLT FAQ,

though i think prior to embarking on this effort there is some work in the
following to be reviewed;

- what level of programming idiom are we addressing with such a library ?
ex. date-format functions or generic templates or SVG framework?

- what future XSLT parser optimisations are going to effect the development
and implementation of such a library ( i.e. compiled stylesheets )?
Currently processing with XSLT parsers is not 'up to speed' for some of the
more real-world problems out there.

- will SOAP and XML-RPC calls replace some local functionality requirements,
ok i'm not saying to create a soap service for formatting dates, but with
larger scope programming idioms i can see a lot of central processing being
employed. At any rate the possibility now exists to easily ( remember DCOM )
hive off certain processing requirements through a more distributed
structure ( and possibly component marketplace ).

- someone on the list very cleverly ( must have remembered their physics
courses) remembered taylor series to perform mathematical calculations
without of course having to 'escape' to javascript et al; i would love to
avoid these types of mechinations when developing pure XSLT templates, and
would expect the <script> debate to finally be resolved with XSLT 2.0, i
have to say i am biased towards the EXSLT effort on this one, and agree with
Steve Ball that this type of thing should not overlap on top of a XSLT
library, gotta review the req again on this one, brain is still on vacation.

- maybe thinking in terms of a library is a bit constraining or
fundamentally not a semantic
match to what we want ? is this a trully datacentric approach, maybe we
should be creating more XML schemas ( or schematron type approaches ).
or more importantly ( this is what i discovered via creation of our internal
framework creating standard frameworks of functionality, rather then a
library.
a very simple example would be the website dtd from Neil Walsh

- if we look at the docbook xslt stuff as a leading example ( no knocks on
it NW...i like it personally ) of a complicated library of functions
    : a library may introduce deep recursion into a relatively simple
application
    : it is inherently difficult to deal with different library versions,
its all or nothing, might be nice for the parser to have a 'lookahead'
function to include just those imported stylesheet functions.
    :docbook lack of namespace, is a good example of why such a library
would need generic namespace handling throughout all functions

ok its easier to criticise, but i think one of the strengths of XSLT is to
easily incorporate a 3rd party template and have the template do something
for u. This is great for short term, but when making architecture level
decisions, its important to delve into the critical paths a little bit.

will have a think

cheers, jim fuller

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


Current Thread