Re: F&O WD

Hi Mike,

>>     As I think I might have mentioned before, I believe
>>     that technically there should be a title-case() function as well,
>
> I Have Always Thought Title Case Was A Style Used Only By American
> Newspapers.

I was more thinking for capitalising the words at the beginning of
sentences (or lines in a poem, say) than capitalising the whole
string, although I'm sure that in some cases that would be useful too.

>>   * get-local-name() and get-namespace-uri() -- Makes me wish that
>>     the structured data types such as QNames, dates, durations and so
>>     on could be treated as virtual elements, so you could do
>>     $qname/local-name or $date/year. 
>
> Yes; I'd like to see a consistent approach to component extraction too. I
> have proposed naming the functions, for example, QName.local-name(),
> DateTime.month(), but I seem to be the only one who likes the idea.

I certainly prefer that naming scheme to the get-component-from-type()
pattern. It would be even better if you didn't have to define
functions for every single component, but had a separate method for
accessing components, in my view, especially if external objects are
allowed (as they are in XPath 1.0).

>>   - root() -- I think that root($node) does the same thing as
>>     $node/ancestor::node()[last()]. Given that the function is
>>     possible with very little effort, and that you rarely need to get
>>     from a node to the root node of that document, I don't really see
>>     the point of this function.
>
> XQuery still has no ancestor axis. This function is actually there
> because there is still a debate about the meaning of a leading "/":
> does it mean root(), or does it mean input()? The traditional XSLT
> meaning is root(), the traditional XQuery meaning is input().
> Providing both functions ensures that both capabilities are
> available unambiguously while we resolve what "/" should mean.

Right. I was commenting from an XPath standpoint. It will be extremely
bad news if / doesn't mean the same in XPath 2.0 as it did in XPath
1.0.

>>   - empty() -- empty($seq) seems to be equivalent to
>>     not(boolean($seq)); as with other shorthands for easy expressions,
>>     I don't think this one's necessary
>> 
>>   - exists() -- seems to be equivalent to not(empty($seq))
>
> I quite like the improved readability that you get from empty() and
> exists().

As I said, I think that improved readability shouldn't be the only
reason for introducing a function. We can get improved readability,
for those that want/need it, through libraries of function
definitions, without having to increase the set of core functions in
XPath 2.0.

>>   * function-available() to support the idea that XPath function
>>     libraries could be provided by particular implementations.
>
> XQuery isn't prepared to accept dynamic binding of function names,
> without which function-available() is meaningless. So this will
> remain an XSLT-only function.

Wouldn't it still be useful in cases where different XQuery
implementations support different (extension or even core) functions,
so that people can write queries that can be used across XQuery
implementations?

>>   * system-property() to support getting information about the XPath
>>     implementation version and so on.
>
> Yes, that would be an interesting one to migrate. The current XSLT
> spec has the disadvantage that it relies on run-time resolution of
> namespace prefixes, which XPath otherwise does not require.

If you defined system-property() as accepting a QName argument,
presumably (?) the automatic casting in XPath 2.0 would enable the
QName strings to be cast to QNames, as in xf:QName-from-string(), so
the function could be backwards compatible without requiring any more
run-time resolution of namespace prefixes than is there already.

Cheers,

Jeni

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

Received on Monday, 20 May 2002 08:06:46 UTC