Re: My favourite XSLT enhancement requests

Alexey,

| Stylesheets with extensions will be portable only among processors that
| belong to the same class. In the example above we might have up to 64
| incompatible XSLT dialects! Is this a portability?

There is only one dialect of the XSLT language, that specified by the
XSLT Recommendation. It offers a language-neutral extension function
facility. Today, that language-neutral facility does not have any
specifics specified to allow implementors to *build* language bindings
that different processors could share for a common extension function
implementation language. The requirements communicate our intent
to fix this, and provide an initial set of concrete language bindings
as well. 

| How implementors that are using "less popular 
| languages" should proceed?

Similar to how DOM and SVG have approached the problem,
the WG would likely specify the language binding details
in a language-neutral way using IDL interfaces. These 
language-neutral specifics can then be mapped to any
of the languages/technologies you mentioned.

| How the popularity was measured? Is there any statistics available? Or
| there is some central authority that decides which language should be
| treated as popular? And who can predict what will become popular in one
| year?
|
| Were *all* existing XSLT processors considered? Or only those 
| developed by W3C members?

The members of the XSL Working group voted to include these two
primary languages in the requirements document. Feedback typically
includes user feedback from public mailing lists and from member
companies that bring their own customer feedback to the table.
The reason W3C puts out drafts for public review is to get
feedback on whether what the WG members voted is what the
public needs. 

| Why not to follow the commonly used practice: define the ABSTRACT,
| PLATFORM-INDEPENDENT model first, then specify bindings for all
| platforms needed by the user community?

Point taken that the requirements should more specifically call
out the provision of the platform-independent model as the
groundwork upon which to build language bindings. The intent
in the current working draft was that this was covered by
the requirement that:

(*) It MUST be possible to extend the mechanism naturally to
    support other languages in the future. 

But this could be stated more clearly by something like:

(*) A language-neutral IDL binding must be provided.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/

Received on Saturday, 16 September 2000 14:42:32 UTC