RE: F&O WD

Jeni:
Thanks for your comments.  We are all at a W3C meeting this week.  Will get back to you next week.
Ashok

 -----Original Message----- 
 From: Jeni Tennison [mailto:jeni@jenitennison.com] 
 Sent: Mon 5/13/2002 4:01 AM 
 To: Jonathan Robie 
 Cc: public-qt-comments@w3.org 
 Subject: F&O WD
 
 

 Hi Jonathan,
 
 I promised some more detailed comments on the F&O WD, so here you are.
 As usual, these come from my perspective as an XSLT user rather than
 anything else. I've ignored the constructors and casting sections,
 since I know they're under review anyway.
 
 I guess my guiding principal is that if a function is just a shorthand
 for something that can be implemented without a recursive function,
 then it shouldn't be included in the core set of XPath 2.0 functions.
 Both XQuery and XSLT have methods of defining extension functions, so
 I think that it's more important to focus on the functions that are
 impossible or difficult to implement in XQuery/XSLT rather than those
 that are simply convenience functions.
 
 Cheers,
 
 Jeni
 
 ---
 
 The new functions, added on to XPath 1.0, are the following. I've put
 * by the ones that I think should stay, - by those that I think should
 go, and + by those on which I'm equivocal:
 
   - node-kind() -- I've hardly ever seen a problem that's required
     this functionality. I think it would be more flexible to use the
     "instance of" operator to work out what kind of node you're
     looking at; it would be easy enough to define your own function to
     give you the name of the node type on the rare cases that's
     required. In other words, you should be able to get at the type of
     a node and the type of an atomic value in the same way.
  
   + node-name() -- This used to be the name() function; I wonder
     whether it would be possible to merge this with the name()
     function. It would be great if that could be done so that the
     name() function works in the way that people think it works, such
     that "name() = 'pfx:name'" is equivalent to "self::pfx:name"; this
     would be backwards-incompatible with XPath 1.0, but would be more
     intuitive for users.
 
   * data() -- Certainly required now, but as with a lot of these
     functions, I wonder whether it would be helpful to have it follow
     the pattern of existing functions, like name() and string(), and
     have it return the typed value of the context node if it doesn't
     have an argument passed to it. I know that the F&O document
     purposefully tries to avoid overloaded functions, but for users,
     both those used to XPath 1.0 and those coming new to XPath 2.0, it
     will be confusing that different functions work in different ways
     depending on which version they were introduced in.
 
   * base-uri() -- Certainly very useful; we often get questions asking
     how to get the URL of the file that's being used as the source of
     the transformation.
 
   - unique-ID() -- I've never known anyone to have to get hold of the
     value of the ID attribute on a given element. If they do, they
     know the name of the attribute and can get its value through
     normal mechanisms. I'm also worried that this function will get
     confused with the generate-id() function.
 
   * compare() -- We do need this facility although not as much as
     you might think, in my opinion. I have to say that personally I
     find a return value of -1, 0 or 1 difficult to work with: I always
     get confused about which way round the arguments are related. It
     would be great if there was an alternative design, but I doubt
     that there is and since we'll rarely have to use different
     collations, I don't think that's too much of a problem.
 
   - normalize-unicode() -- As far as I understand the character
     model for the WWW, all text on the Internet should be normalized,
     and specifications should require unicode normalized (NFC) text. I
     can't recall ever seeing someone need to do unicode normalization;
     I suspect that such operations would be better done at a lower
     level in the application (normalize early) and that the data model
     should dictate that text is normalized.
 
   * upper-case() and lower-case() -- There's definitely a strong
     requirement for these, although allowing case-insensitive
     comparisons (which I think is supported with collations?) will go
     most of the way towards supporting the usual reason for
     case-changing. As I think I might have mentioned before, I believe
     that technically there should be a title-case() function as well,
     since the title case version of a letter is not always the same as
     the upper case version of a letter (ref.
     http://www.unicode.org/unicode/reports/tr21/)
 
   + string-pad() -- Repeating the same string is a fairly common
     operation, although it is one that's particularly easy to
     accomplish now with a user-defined function and a simple
     iteration. I therefore don't think that this function is vital,
     and if you want to save space, I think it should be dropped.
 
   * match() and replace() -- I think that you know that we need more
     regular expression support than this; I believe that you're
     working on that and that I've already commented on it.
 
   + duration/dateTime functions -- I've already commented on these in
     a separate thread. I think that this is the poorest section of the
     spec. The kinds of things that people want to do with dates are:
 
       - reformat them (which I believe is being supported separately
         in XSLT 2.0, though it's not there yet)
 
       - get a date from the common "seconds since
         1970-01-01T00:00:00Z" representation (for all its faults)
 
       - perform calculations between them
 
     Dates have a fixed format, so it's not hard to extract individual
     components from a date; I don't think that the set of functions to
     do so are necessary. It's harder to extract information from a
     duration because it doesn't have a fixed format, but not
     drastically so, and I think it's really very rare that you need to
     know get that kind of information from a duration.
 
     One thing that *is* difficult, and is useful, is to get values
     like "the number of seconds represented by this duration" (i.e.
     the reverse of dayTimeDuration-from-seconds()) -- it's useful
     because that enables you to perform calculations with durations
     (adding them, dividing them) that you can't do otherwise.
 
   * 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. These are certainly handy
     functions, though.
 
   * resolve-URI() -- I imagine this will be very handy.
 
     URI manipulation is, I think, the primary reason for the
     requirement for string manipulation functions like
     subtring-after-last() or index-of-last(). Perhaps a
     get-file-name() method would be useful; I'm not sure.
 
   + deep-equal() -- I wouldn't personally say that this was a
     high-priority function. My guess would be that people would use it
     for the common task of moving through two documents to see where
     differences lie between them, and in that context I think it would
     be very expensive. But others might have use cases that I'm
     unaware of.
 
   - 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.
 
   - if-absent() and if-empty() are shorthands for:
     if (not($node)) then $default else $node and
     if (not($node) or not($node/node())) then $default else $node
     I don't find these expressions so burdensome that they require
     shorthand functions, especially not compared to some of the other
     functionality that's currently missing from the spec.
 
   * index-of() -- definitely required, though I have no doubt that
     people will use it like:
 
     $nodes[index-of(for $n in $nodes return string(), 'foo')]
 
   - 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, although it's true that the
     casting of empty sequences to boolean false can be non-obvious for
     beginners.
 
   - exists() -- seems to be equivalent to not(empty($seq)) or exactly
     equivalent to boolean($seq). I don't think this is necessary;
     empty() is more useful if you didn't want to use boolean() in the
     way that it's been used in XPath 1.0.
 
   + distinct-nodes() -- This obviously doesn't arise in XSLT 1.0
     because it's impossible to create a node set that contains more
     than one of a particular node. Given that node sequences are (or
     should/can be) created with duplicates automatically removed, I
     doubt that this will come into play very often; there aren't any
     use cases for it in the XQuery use case document either. On the
     other hand, the equivalent expression (distinct-nodes($nodes) is
     the same as union(() | $nodes)) is a bit of a hack and might not
     get you precisely what you want (since it also reorders into
     document order), so it's probably best to be on the safe side.
 
   * distinct-values() -- This functionality is required (and
     lacking) in XSLT 1.0, but the grouping facilities in XSLT 2.0 mean
     that it wouldn't be nearly as important there. I can see places
     where it would be handy, though (for example to write things like
     "there are 4 groups...", and to allow me to apply templates to
     distinct nodes in order to get more flexibility in my stylesheet).
     Since this function is likely to be much more heavily used than
     distinct-nodes(), I think it should be shortened to distinct().
 
   - insert() -- I can't really see the point, given that there's a
     concat(), a subsequence() and an index-of() and I don't think that
     there will often be times when you need to insert items into the
     middle of a sequence.
 
   - remove() -- Again, I don't see why this is needed, given that you
     can use a predicate to do the same thing: $target[position() !=
     $position].
 
   * subsequence() -- I imagine would be useful.
 
   + sequence-deep-equal() and sequence-node-equal() -- I'm not sure
     about sequence-deep-equal(), for the same reason I'm not sure
     about deep-equal(). The most useful, I would imagine, would be a
     plain sequence-equal() that compared the two sequences to see if
     they were the same on an item-by-item basis, with nodes being
     assessed based on identity, and values being assessed on their
     value.
 
   - avg() -- I'm not personally convinced (since the equivalent
     expression of sum() div count() really isn't difficult).
 
   * max() and min() -- Definitely. This is a requirements that's
     probably even greater than date formatting or regular expressions.
     It would be even more helpful if there was a quick way of getting
     to the node(s) that has the min/max value, rather than just
     getting the value itself. I imagine we're going to see rather a
     lot of $nodes[. = max($nodes)] otherwise, although I guess that
     could be optimised.
 
   - idref() -- As I've said elsewhere, id() turns out to be hardly
     used in XSLT because of the issues to do with requiring a DTD be
     present for the link to be any use. Where you need a reverse link,
     you can generally set up a key instead. I'd rather see keys from
     XML Schema supported than a specific idref() function introduced.
 
   - filter() -- I think this is potentially very useful, but, like
     copy() and shallow(), it has to do with creating nodes, which
     means that it shouldn't live at the XPath level.
 
   - collection() -- I don't really understand how this is different
     from the document() function.
 
   * input() -- Sounds reasonable.
 
   - context-item() -- I assume that this is not a real function, but
     actually just a backup for the shorthand '.'? It should say so.
 
   * current-dateTime() -- Definitely required; XForms calls this
     function now(), which has the advantage of being short and
     avoiding the mixed case convention difficulties.
 
 Aside from those mentioned above, functions that are missing are:
 
   * tokenize(), which people ask for all the time, particularly for
     splitting strings into lines or words
 
   + possibly sqrt(), sin() and cos(), which are particularly useful
     when creating graphic formats such as SVG and aren't that easy to
     implement in XSLT
 
   * random() (create random numbers) and more usefully, I think,
     randomize() (randomly alter the order of items in a sequence),
     both with obvious side-effect issues; again these are impossible
     to implement using XSLT
 
   * function-available() to support the idea that XPath function
     libraries could be provided by particular implementations.
 
   * system-property() to support getting information about the XPath
     implementation version and so on.
 
 FWIW, on the issues front:
 
   14: (operator-function-signatures) I agree, some of the
       signatures are confusing; I read the spec as indicating the
       required types for the functions, such that if you're using
       XPath the casting to those types is done automatically.
 
   20: (operator-codepoint-vs-character) I agree that the spec
       should be clear about whether it's talking about code points or
       characters, but I think that the character model spec recommends
       talking about character strings rather than code unit strings
       (ref. http://www.w3.org/TR/charmod/#sec-Strings)
 
   21: (operator-function-return-types) In my opinion, the return
       type of a function should be fixed, and not change based on the
       actual type passed as the argument of a function.
 
   37: (semantic-contains) I think that adding linguistic/semantic
       contains is a huge effort for very little benefit, at least for
       XPath 2.0. I can see that XQuery might want it, but I wouldn't
       want XSLT to be burdened, as the primary task of XSLT is
       transformation rather than querying.
 
   44: (operator-collation-specification) I think that XPath 2.0 should
       follow the pattern of XPath/XSLT 1.0 and use qualified names
       rather than URIs, for consistency and because it makes them
       easier to use.
 
   63: (operator-augment-index-of) I find the distinction between
       performing operations on nodes vs. performing operations on
       their values fiddly. In the case of index-of(), it strikes me
       that it wouldn't be difficult to perform index-of-value() if you
       had support for an index-of() that matched by node identity or
       simple type value (by creating a sequence of the node values and
       getting the index of the value you were after).
 
   66: (operator-docorder-function) Like distinct-nodes(), the
       requirement (or lack of it) for this function isn't yet apparent
       because it's not an issue in XSLT 1.0. Personally, I don't think
       that it will be used that often, but it may be best to be on the
       safe side as it wouldn't be particularly easy to replicate this
       functionality without removing duplicate nodes at the same time.
 
   67: (operator-remove-dupes) Since location paths do remove
       duplicates, and there thus isn't any backwards incompatibility
       with XPath 1.0, I don't think there's any reason for count() or
       sum() to remove duplicates.
 
   73: (operator-compare-between) I don't think that a
       compare-between() function is required.
 
   77: (operator-string-from-char) chars aren't data types in XML
       Schema -- are they in XPath? If not, then this issue isn't
       relevant.
 
   94: (operator-within-window) As with (semantic-contains), I don't
       think this is a high priority for XPath 2.0.
 
  108: (operators-always-normalize) I don't think that we should need
       to worry about unicode normalization within XPath 2.0.
 
  136: (function-datetime-timezone-conversion) In XML Schema, the
       timezone isn't part of the value space of a dateTime. Adding a
       timezone to a dateTime is essentially a formatting function.
 
  139: (need-fuller-definition-of-error-behavior-and-handling) Yes. We
       need to be able to test if an item is an error, and then be able
       to get information about that error, most importantly an error
       message that describes it and probably some information about
       the context in which the error occurred (e.g. what the context
       node was). I'm sure that you already have something on the cards
       here. Another point of confusion is that the empty sequence is
       sometimes used as a kind of error value, but at other times an
       error object is returned. I haven't yet worked out what the
       underlying heuristic is there, assuming that there is one.
 
  141: (does-string-equality-use-codepoint-or-default-collation) I
       think it should use the default collation, like the other string
       manipulation functions.
 
  142: (what-should-floor-ceiling-round-return) For compatibility, this
       should really return a xs:double (I believe). However, I think
       that returning an xs:integer, with an empty sequence used
       instead of NaN, would also be reasonable.
 
  143: (need-tokenize-function) As above, we definitely need a
       tokenize() function, preferably one that defaults to breaking on
       whitespace.
 
  144: (should-concat-accept-sequence-arguments) It would be useful,
       but highly incompatible. Perhaps a separate concat-sequence()
       function should be invented. (In XSLT 2.0, you can achieve
       the same effect with an xsl:value-of and an empty separator
       attribute, but since XSLT shouldn't be used for general sequence
       construction (apparently), this isn't ideal.
 
  150: (should-comparison-that-return-indeterminate-results-be-supported)
       As I've said before, yes. This is far more important than
       supporting matching of 'nearby' strings and so on, in my
       opinion.
 
  151: (comparison-functions-for-other-date-and-time-types) Yes, there
       should be comparison functions for other date and time types,
       although a basic rule about how the comparisons are carried out
       would be better than listing every possible combination of
       comparisons.
 
  152: (parameterized-extraction-functions-for-date-and-times) I view
       the extraction functions as superfluous, in the face of
       substring() and the prospect of a format-date() function. If you
       have them here, then I do think that they should be
       parameterised.
 
  154: (second-order-distinct-function) Like the other second-order
       functions, it would be great, but I don't think it's worth
       entering that territory at this stage.
 
  157: (boolean-from-string-legal-literals) Absolutely.
 
  162: (can-the-node-parameter-to-root-be-omitted) As I mentioned
       above, I think that having single-argument functions default to
       using the context item is a very useful tactic, and one that
       XPath 1.0 users are used to exploiting. It would be good, for
       consistency, if the new functions supported this shorthand.
 
  164: (for-complex-types-what-should-data-return) I don't have a
       strong opinion either way, but it should be consistent with the
       description of the typed value accessor in the data model. Since
       the string value is readily accessible in other ways, I think
       data() should probably not return the string value of the
       element if it has a complex type with complex content.
 
  166: (current-dateTime-convenience-functions) On the principal of
       having as few functions as possible, I don't think these
       convenience functions are necessary. They are easy to define for
       people who want them.
 
  168: (should-id-take-a-list-of-strings) id() definitely should be
       compatible with id() in XPath 1.0, and therefore accept a list
       of IDs.
 
 ---
 Jeni Tennison
 http://www.jenitennison.com/
 
 

Received on Tuesday, 14 May 2002 11:59:15 UTC