You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Henry Zongaro <zo...@ca.ibm.com> on 2006/10/17 20:53:35 UTC

Select-like attributes in extension elements?

Hello.

Somebody contacted me directly today about a problem they were having with 
evaluating an XPath expression in an attribute of an extension element. 
(This person is using Xalan-J Interpretive.)  I pointed out the 
ElemExtensionCall.getAttribute method,[1] which allows you to treat an 
attribute in an extension element as an AVT and get the effective value of 
the attribute.

He seemed happy with that, but wanted to know how to treat an attribute as 
an XPath expression which could be evaluated to a node set.  So far as I 
can tell, there is no simple API that exists.  Instead users have had to 
do things along the lines of what Simon Kitching describes in [2].  Is 
anybody aware of a simpler way of doing this?  If not, is anybody aware of 
whether the project has ever received a request for a new feature along 
these lines?

Thanks,

Henry
[1] 
http://xml.apache.org/xalan-j/apidocs/org/apache/xalan/templates/ElemExtensionCall.html#getAttribute(java.lang.String,%20org.w3c.dom.Node,%20org.apache.xalan.transformer.TransformerImpl)
[2] http://marc.theaimsgroup.com/?l=xalan-j-users&m=102400418815043&w=2
------------------------------------------------------------------
Henry Zongaro      XSLT Processors Development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


Re: Select-like attributes in extension elements?

Posted by Henry Zongaro <zo...@ca.ibm.com>.
Hi, Joe.

keshlam@us.ibm.com wrote on 2006-10-17 04:53:44 PM:
> Just making sure I understand the question: Is the user looking for 
> arbitrary XPath interpretation, similar to
> http://www.exslt.org/dyn/
> or are they specifically looking for the equivalent of select?

The equivalent of select.  It just surprised me that there seemed to be 
convenient APIs for treating the value of an attribute of an extension 
element as a fixed string or as AVT, but not as a single XPath expression 
returning its "natural" value rather than being always cast to a string.

> Of course all of this is going to be emphatically nonportable to 
> other processors, which makes me a bit nervous about investing too 
> much effort in it.

Agreed.  This was more of a "do we already have" question on my part, 
rather than a recommendation that we should add such a facility.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      XSLT Processors Development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com



---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org


Re: Select-like attributes in extension elements?

Posted by ke...@us.ibm.com.
Just making sure I understand the question: Is the user looking for
arbitrary XPath interpretation, similar to
      http://www.exslt.org/dyn/
or are they specifically looking for the equivalent of select?

We do have an implementation of exslt:dyn, though of course it works only
in interpretive mode and any interactive XPath evaluator would be likewise
constrained. If someone's looking for an "API", adding one to that code is
the best solution I can think of offhand.

Something more select-like (with hardcoded path), theoretically might be
implementable even in compiled mode, if there was some way for us to
recognize that this particular attribute was supposed to be a nodeset
retrieval request. I guess, since the extension behivor is specific to the
implementation, we could reserve a specific namespaced attribute (or
namespace alone, so multiple selects could exist?) to cue the processor
that this is our intent. This would be roughly equivalent to setting a
variable to a nodeset using select, then passing that variable into the
extension; just a bit less verbose.

Of course all of this is going to be emphatically nonportable to other
processors, which makes me a bit nervous about investing too much effort in
it.

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
  -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)