This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]