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

Binding XSLT script functions to implementation (was ANNOUNCE: Petition.

• From: "Arnold, Curt" <Curt.Arnold@h...>
• To: "'xml-dev@l...'" <xml-dev@l...>
• Date: Fri, 02 Mar 2001 10:23:24 -0700

> It is very clear to me that the above stylesheet will work
> if and *only* if the the XSLT processor has built-in java
> capabilities.  So, although you may be right about not 
> "embedding Java", this is close enough to the same concern, 
> it is an "embedded Java package name".

It isn't clear to me that a C++ processor might not already be
aware of an compatible implementation of date:format() and ignore the definition in the transform.

The <xsl:script/> within the transform is roughly equivalent to
an internal DTD subset (if embedded) or a external DTD subset (if referenced).  The namespace URI and function name are roughly equivalent to the Public ID.

I think it would be rare that any server would trust any script that is embedded or referenced within a transform and would only support those scripts that were already known to it for the same reason
you would not blindly try to validate with a DTD or schema that you did not control.

However, the nature of this preloading of known functions must vary between platforms.  What you would expect is that the processor would allow you to intercept resolution of script functions in the
same manner XML parsers allow you to intercept resolution of external entities.

I do not see the ability to provide an embedded or reference script interferes with the ability to resolved the URI/function name pair through other mechansisms.

• Prev by Date: RE: XML Meta-Architecture (Technetcast program of Henry Thompsonkeynote)
• Next by Date: Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1
• Previous by thread: Re: XML Meta-Architecture (Technetcast program of Henry Thompsonkeynote)
• Next by thread: is that a fork in the road?
• Index(es):
  • Date
  • Thread