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]
Other format: [Raw text]

Re: Function arguments (was regexps once)


Hi David,

> taking the functions depending on context issue first, I think that
> is a different from the "functions return same result given same
> arguments" issue. One can argue that some built in functions take .
> as an argument but just as a top level syntax issue you can omit the
> .

I agree that you can think of the pertinent aspects of the focus as
being an additional argument to the function. I just wanted to bring
out the point because the only exising built-in function that returns
a node tree - document() - returns the same tree *across the
stylesheet* rather than *in a particular context*. This is important,
I think, because it's certainly won't be the case for extension
functions, and might not be the case for other built-in functions that
return node trees (e.g. current-match() as described).

> (It's not clear to me whetehr for user defined functions this
> implied . argument should always be there, or never, or only if the
> function uses a function that has that feature, or only if the user
> declares (somehow) that the function takes an implied . argument)

Yes, that's not clear to me either. A processor could check whether
the focus was important within a user-defined function by going
through all the content and checking whether . or position() or last()
was ever used within it to distinguish between them, I guess, but
getting that information up front (a use-context attribute or
something) might be easier on the processor.

> It maybe that a processor can recognise that some arguments are the
> same as some previous call and so reuse some previous result sitting
> in memory somewhere or it may not and it may work it out again. This
> doesn't matter so long as whatever it uses internally for
> generate-id (and thus == in xpath2) only uses some attributes that
> depend on the function arguments (which better not be a low level
> pointer to some in memory object if there's a chance there might be
> two of them considered equal, but that's an implementation issue...)

Ah, yes, good point. If the ID is something like
"foo-element-created-by-call-to-my:foo-with-argument-abc-in-context-bar"
then it will all work out OK.

> so I think the statement that
> generate-id(document(...)=generate-id(document(...) which only
> applies to document() at xpath1 because that's all there was should
> apply to any functions defined within xpath2, including xslt-defined
> extension functions.

Sure, but conversely, if you have:

<xsl:variable name="foo" select="document($x)" />

<xsl:template match="bar">
  <xsl:if test="document($x) == $foo">
    ...
  </xsl:if>
</xsl:template>

then under XSLT 1.0, the test in the xsl:if is always true. That
would not be the case with user-defined extension functions in XSLT
2.0 and might not be the case with any future built-in functions that
return node trees.

Actually the document() function in XSLT 1.0 gives the same tree based
on the *resolved URI* from its combined arguments. Assuming that the
current document, and the stylesheet are in the same directory, under
XSLT 1.0, the document() function returns the same thing with:

  document('file.xml')

and:

  document('file.xml', /)

and:

  document('file.xml', .)

and various other things as long as the first node in the node set in
the second argument is from the same document as the context node.

Again, it's not going to be possible to articulate those kinds of
semantics about user-defined extension functions. To support this kind
of thing I think you'd need each function definition to be able to
specify some kind of expression that gives a unique identifier for the
function call. So if you had a function that depended solely upon the
context node you could do:

<xsl:function name="foo">
  <xsl:call-id select="." />
  ...
</xsl:function>

whereas for something like the document function it would be something
like:

<xsl:function name="document">
  <xsl:param name="url" />
  <xsl:param name="node" />
  <xsl:call-id select="my:resolve-uri($url, $node)" />
  ...
</xsl:function>

and if it should always return the same thing no matter what, you
could have any literal value:

<xsl:function name="bar">
  <xsl:call-id select="'bar'" />
  ...
</xsl:function>

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 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]