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

Re: XSLT 1.1 comments

Subject: Re: XSLT 1.1 comments
From: "Steve Muench" <Steve.Muench@xxxxxxxxxx>
Date: Wed, 14 Feb 2001 13:45:49 -0800
Re:  XSLT 1.1 comments
|   Extension functions specify particular functionality
|   be carried out, and do not specify an implementation.

This holds for built-in extensions.

In addition to supporting built-in extensions, many popular
processors support a built-in extension element that
allows users to create their own user-written extension 
functions in any namespace.

This latter case is the case that <xsl:script> is trying
to standardize. Binding a user-written implementation to
a namespace. The <xsl:script> element could just as well
be called:

<xsl:associate-user-written-extension-function-implementation-with-namespace/>

|   Scripts are embedded code of a completely different language
|   with it's own interpreter, etc.

|   Thus, enumeration of additional required
|   functionality is a very hard problem.

What's needed is to specify the various contracts
at the boundary points between the XSLT processor
and the extension function implementation language 
environment. These are the concrete details provided
in XSLT 1.1 for IDL/DOM2, Java/DOM2, and ECMAScript DOM2
bindings.

| Making a template and calling a template are just too verbose.  
| This seperate issue can be solved by an additional namespace "xf"
| with the following behavior:
| 
| Anywhere, except as a child of "xsl:template",
| 
|   <xf:func x="y" />    is equivalent to   <xsl:call-template name="func">
|                                             <xsl:with-param name="x"
|                                                select="y" />
|                                           </xsl:call-template>
| 
| and when a child of xsl:template,
| 
|   <xf:func x="y">      is equivalent to   <xsl:template name="func">
|     ...                                     <xsl:param name="x"
|   </xf:func>                                    select="y" />
|                                             ...
|                                           </xsl:template>

This approach would appear to have problems
passing literal result-tree-fragment arguments
to templates...
  
   <xsl:call-template name="foo">
      <xsl:with-param name="content">
        <ul>
          <li>One</li>
          <li>Two</li>
        </ul>
      </xsl:with-param>
    </xsl:call-template>

Your example would imply this would be:

   <xf:foo content="<ul><li>...</li></ul>"/>

Which wouldn't parse due to the angle-brackets
inside the attribute.
______________________________________________________________
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/



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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.