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

Re: Note from XSL WG on Extension Concerns

• From: Leigh Dodds <ldodds@i...>
• To: xml-dev@x...
• Date: Thu, 6 Apr 2000 20:22:00 +0100

[Thanks to Steve for posting an update on the status of
the XSL WG]

I thought I'd invite a little discussion, and jot down
some of the notes I've been making on this topic. Obviously
they'll have to be taken in light of Steve's comments.

Namespaces:

Obviously there will be a need to standardise on one or
more namespaces for extension functions. I'd suggest that
for Java based extensions one of two options should be
considered:

- Java/Sun Namespace e.g. java.sun.com/products/jdk/1.2/...classname...
- W3C Java Namespace e.g.
www.w3.org/XSLT/1999/Transform/Java/...classname...

(Personally I prefer the former.)

Language Binding:

Of the two XSLT processors I've had chance to look at
(Xalan and XT), the basic language bindings are largely similar.
Java int, long, etc are mapped to XSLT number; similarly
for boolean and String.

As far as result set fragments and node-sets are concerned
there's a difference. XT uses its own bindings, Xalan uses
the DOM API (i.e. Document Fragment and NodeList).

The latter seems a sensible choice for standardisation, as otherwise
a DOM-a-like API will be required. This seems to be the accepted
process - each spec usually supplies or defines a customised DOM version.

I can envisage that there are other features that an XSLT
processor might expose - such as access to in-scope variable bindings;
exposing XPath querying; and possibly even document parsing functions.

The latter would be useful if I was (for example) writing
an document() (see section 12.1 in spec) extension function which retrieved
documents using a non-standard mechanism, e.g. secure HTTP, whatever.
Having downloaded the relevant document it'd have to be parsed into a
suitable node-set for use by the processor. This requires
the ability to allow the XSLT processor to parse a secondary document.

These additional API functions could also form the basis for a
standardised XSLT processor API.

Standardised Extentsion:

The recent discussions highlighted two potential extensions ripe
for either adding to the XSLT core, or standardising in some way.
These are:

- multiple outputs
- result-set-fragment to node-set 'casts'

I assume that a revised XSLT spec would dictate the signature
of these methods, and expected processing but not provide
an implementation. Also presumably these would fall under
the normal XSLT namespace.


It will be interesting to see the next version of XSLT take
shape. Thanks to the WG for taking notice of the community concerns.

Cheers,

L.


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Follow-Ups:
  • Re: Note from XSL WG on Extension Concerns
    • From: Eric van der Vlist <vdv@d...>

• Prev by Date: DTDs/Schemata for dictionaries?
• Next by Date: Re: SAX Namespaces? ContentHandlers? Jobs.
• Previous by thread: RE: Note from XSL WG on Extension Concerns
• Next by thread: Re: Note from XSL WG on Extension Concerns
• Index(es):
  • Date
  • Thread