jaxen

Namespace for extension functions

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.1
  • Fix Version/s: None
  • Component/s: function
  • Labels:
    None
  • Number of attachments :
    0

Description

As near as I can tell there's no rule in XPath 1.0 that requires extension functions to be in a namespace. That is, the function library is not limited to functions defined in the XPath spec. The list there is minimal, not exclusive. However, in XSLT there is a requirement that extension functions not defined in either XPath or XSLT be in a namespace:

The argument must evaluate to a string that is a QName. The QName is expanded into an expanded-name using the namespace declarations in scope for the expression. The function-available function returns true if and only if the expanded-name is the name of a function in the function library. If the expanded-name has a non-null namespace URI, then it refers to an extension function; otherwise, it refers to a function defined by XPath or XSLT.

In other words, if Jaxen provides the org.jaxen.function.ext functions to an XSLT implementation the XSLT implementation is in error. On the other hand, it would be possible for the XSLT implementation to define its own function context that doesn't include the ext functions. It would even be possible for the XSLT implementation to map the org.jaxen.function.ext functions to to a different namespace URI.

My gut is that we should fix XPathFunctionContext so that the extension functions are registered in a namespace such as http://functions.jaxen.org/ but I'm not 100% convinced that's necessary. It might cause problems for people already using these functions. We could have a deprecation cycle in which both namespaced and nonnamespaced functions were available. That is, we could register the extension functions twice. once with and once without namespaces.

So the first question is, what, if anything should be done here?

The second question is if we change the namespace, when should we do it? For 1.1 or 1.2?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
peter royal added a comment -

I'm not sure its necessary to do anything. I believe the docs could handle what functions were not part of the XPath 1.0 spec, just as XSLT does. Putting them in a namespace would add more confusion to users I think, as they would then have to setup a NamespaceContext in order to assign a prefix to be able to use the functions effectively..

Show
peter royal added a comment - I'm not sure its necessary to do anything. I believe the docs could handle what functions were not part of the XPath 1.0 spec, just as XSLT does. Putting them in a namespace would add more confusion to users I think, as they would then have to setup a NamespaceContext in order to assign a prefix to be able to use the functions effectively..
Hide
Permalink
Brian Ewins added a comment -

Just for completeness, there are some relevant jaxp requirements also:

"All implementations are required to support the javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING feature. When the feature is true, any reference to an external function is an error" (p135)

Implying that we need to make a distinction between builtins and extensions that is not made at present.

"XPath functions are resolved by name and arity. The resolver is not needed for XPath built-in functions and the resolver cannot be used to override those functions.
In particular, the resolver is only called for functions in an another namespace (functions with an explicit prefix)...If you wish to implement additional built-in functions, you will have to extend the underlying implementation directly." (jaxp 1.3 p147)

the implication here is that we can resolve any functions users supplies via_jaxen_apis in any namespace as if they were builtins (ie jaxp is less restrictive than xslt), but we can't resolve functions the user supplies via_jaxp in the default namespace.

My thinking is that this all means we can't layer jaxp on jaxen as it stands, but we'll require an internal layer which makes the distinction between builtins and user-supplied functions. The jaxen 'personality' would just access builtins so as to be backwards compatible; the jaxp layer, by contrast, will not expose the builtins at all. (ok ok I keep promising a branch for this. I will definitely do this at the weekend)

Which doesn't address the original issue, I guess. In jaxp we'll be able to offer 'features' which could include xslt-compatible processing: we'd register non xslt functions into an extension namespace. Theres probably something similar we can do for 'pure' jaxen.

BTW the bugifix on this the other day:
http://cvs.jaxen.codehaus.org/changelog/jaxen/jaxen/src/java/main/org/jaxen?cs=MAIN:elharo:20050917105950
wouldn't it be better to put code in QualifiedName.toString(), and change the throw to throw new UnresolvableException( "No Such Function " + key );? I'm sure we could use that elsewhere too.

Show
Brian Ewins added a comment - Just for completeness, there are some relevant jaxp requirements also: "All implementations are required to support the javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING feature. When the feature is true, any reference to an external function is an error" (p135) Implying that we need to make a distinction between builtins and extensions that is not made at present. "XPath functions are resolved by name and arity. The resolver is not needed for XPath built-in functions and the resolver cannot be used to override those functions. In particular, the resolver is only called for functions in an another namespace (functions with an explicit prefix)...If you wish to implement additional built-in functions, you will have to extend the underlying implementation directly." (jaxp 1.3 p147) the implication here is that we can resolve any functions users supplies via_jaxen_apis in any namespace as if they were builtins (ie jaxp is less restrictive than xslt), but we can't resolve functions the user supplies via_jaxp in the default namespace. My thinking is that this all means we can't layer jaxp on jaxen as it stands, but we'll require an internal layer which makes the distinction between builtins and user-supplied functions. The jaxen 'personality' would just access builtins so as to be backwards compatible; the jaxp layer, by contrast, will not expose the builtins at all. (ok ok I keep promising a branch for this. I will definitely do this at the weekend) Which doesn't address the original issue, I guess. In jaxp we'll be able to offer 'features' which could include xslt-compatible processing: we'd register non xslt functions into an extension namespace. Theres probably something similar we can do for 'pure' jaxen. BTW the bugifix on this the other day: http://cvs.jaxen.codehaus.org/changelog/jaxen/jaxen/src/java/main/org/jaxen?cs=MAIN:elharo:20050917105950 wouldn't it be better to put code in QualifiedName.toString(), and change the throw to throw new UnresolvableException( "No Such Function " + key );? I'm sure we could use that elsewhere too.
Hide
Permalink
Elliotte Rusty Harold added a comment -

QualifiedName is only used in SimpleFunctionContext and SimpleVariableContext. A little unusually the qualified name does not actually include the prefix. We could push it into QualifiedName but it's really only useful for error reportin in these two classes

Show
Elliotte Rusty Harold added a comment - QualifiedName is only used in SimpleFunctionContext and SimpleVariableContext. A little unusually the qualified name does not actually include the prefix. We could push it into QualifiedName but it's really only useful for error reportin in these two classes

People

  • Assignee:
    Unassigned
    Reporter:
    Elliotte Rusty Harold
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: