Comments on XPath (30th April)

2.3.2.2 Dereferences

  Either this should be removed or there needs to be a lot more
  justification placed in the document as to why it should be included.
  It appears to just be a cumbersome syntax for a highly restricted from
  of the function id().


2.6.1 Value Comparisons

  these are useful for defining the semantics of = and friends but it
  isn't clear they are really useful as user level syntax.
  If eq doesn't generate an error, you could have used = instead (unless I
  misread, which is possible)

  oh a general typographical comment on the specs that I just noticed at
  this point:
  Could glossary entries (like the bold "Atomization" here) be made into
  links to their definition.

2.6.4 Order Comparisons

  It is not at all clear these are desirable in XPath for example

  //purchase[parcel="28-451"] << //sale[parcel="33-870"]

  Could more simply be expressed as (the boolean value of)

  //purchase[parcel="28-451"]/following::sale[parcel="33-870"]

  I realise Xquery as currently spec'd doesn't have a full set of axes,
  but it certainly ought to and I assume if for some reason they are
  not in Xquery 1, user pressure will force them to be in Xquery 1.1,
  The axis notion of navigating round a document tree has been one of
  the more successful innovations in XPath.


2.7 Logical Expressions

The first step in evaluating a logical expression is to reduce each of
its operands to an effective boolean value 

  This is a horrible incompatibility with XPath1 which explictly states
  that the second argument is not evaluated if the result can be
  determined from the first.  This feature is _very_ often used, expressions
  such as
  function-available(...) and ...
  cheap-expression and //*[very-expensive-search]
  are very common, and with this new definition the first may well cause
  errors and the second get very slow.


true or error

  Having the specification being different from XPath 1 is bad enough,
  having it be unspecified is even worse. 

2.8 For Expressions

  The fact that for expressions mean that it possible in XPath to bind
  variables to items but not to sequences is a very strange state of
  affairs. Also the fact that there is no version of for that moves the
  context item (and so .) is going to lead to endless user confusion.

  However to comment on the specifics in the current draft:

A for clause associates one or more variables with expressions, creating
tuples of variable bindings drawn from the Cartesian product of the
sequences of values  

   Do you really need to bring in all this stuff on tuples, at the level
   of user visible behaviour isn't a for with multiple variables just
   the same as a nested set of for with one variable each?





[6]    QuantifiedExpr    ::=    ("some" "$" |  "every" "$") QName "in" Expr 
                                   ("," Variable "in" Expr)* "satisfies"  Expr 

   Why is the first Variable split into $Qname and not the second?
   isn't this

   [6]    QuantifiedExpr    ::=    ("some" | "every") Variable "in" Expr 
                                      ("," Variable "in" Expr)* "satisfies"  Expr 






[20]    CastExpr    ::=    ("cast" "as" |  "treat" "as" |  "assert" "as")  


  I'm glad Mike just indicated  in a reply to my comments on F&O that
  there will be some rationalisation here, and in the type constructor
  functions. (Personally I'd prefer to see none of these in XPath, but I
  assume that's too much to ask.)




2.12 Validate Expressions

  I do not think that this should be in XPath at all. Validation has
  little to do with querying a document structure, which is the purpose of
  XPath, and this ties Xpath even more to W3C schema (as opposed to some
  generic psvi typed input from any source).

  If you must have it (and I really hope it goes) why isn't it a normal
  function with () syntax rather than a magic form with its own {} curly
  brace syntax?




David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Received on Tuesday, 21 May 2002 09:54:48 UTC