W3C home > Mailing lists > Public > www-forms-editor@w3.org > April 2007

Comments on XForms 1.1 from XSL and XQuery Working Groups

From: Michael Kay <mike@saxonica.com>
Date: Mon, 23 Apr 2007 22:49:32 +0100
To: <www-forms-editor@w3.org>
Cc: "'XQuery'" <w3c-xml-query-wg@w3.org>, "'XSL WG'" <w3c-xsl-wg@w3.org>
Message-ID: <01ab01c785f1$4701c7a0$6401a8c0@turtle>

The following comments were discussed and approved by a joint meeting of the
XQuery and XSL Working Groups last week. Text between (: and :) is a
personal gloss designed to help you understand the discussion that took
place.

   Section 5.1

   A. It seems odd that xs:double is not included in the core subset
   since it's the only numeric data type supported by XPath 1.0

   Section 5.2.3
 
   B. dayTimeDuration and yearMonthDuration are now available in the
   XML Schema namespace. We encourage you to adopt these new types.

   Section 5.2.7

   C. It's not clear which of these data types allow empty content and
   which don't. What is meant by "the indicated datatypes"? Also,
   there should be a more formal definition of these types, for
   example they could be defined either as a union of the base type
   with a zero-length string, or as a list of zero-or-one items of the
   base type. Such a definition affects the semantics of XPath
   expressions applied to values of these types. We do not understand
   paragraph 2, which appears to contradict paragraph 1.

   Section 7

   D. "XPath expressions that are not syntactically valid": should
   cover all static errors, not just syntax errors. (Other static
   errors include, for example, references to functions or variables
   not present in the context, and type errors detected statically).

   7.1

   E. "A future version of XForms is expected to use XPath 2.0". We
   think it would be more appropriate to use XPath 2.0 in the current
   version.

   Even if you choose not to use XPath 2.0 now, we think you should
   consider laying the groundwork for a transition to XPath 2.0 in the
   current version. (: We noted that there are a few areas where transition
   to 2.0 will cause some compatibility problems - some of these are noted
   below. In these areas in particular we think it would be useful if
   XForms 1.1 provided alternatives to the current 1.0 syntax in a way
   that eases transition to XPath 2.0 later :)

   7.4

   F. The XPath 2.0 specification provides a much more formal and
   comprehensive description of the evaluation context, which would
   provide a more solid basis for this part of the specification.
   (: You could use this as a guide even for XPath 1.0 :)


   7.5.1

   G. The concept of "dynamic dependencies" needs further
   explanation. It's very hard to understand what this section is
   saying. We believe you need a precise definition that states when
   there is a dynamic dependency.

   "there are restrictions on model binding expressions that create
   dynamic dependencies" -> you should tell us precisely what these
   restrictions are, and what an implementation should do if these
   restrictions are violated.

   7.6

   H. Clearly there is a need to provide backwards compatibility with
   XForms 1.0 in the set of additional functions provided. (It's a
   shame that these weren't defined to be in their own
   namespace). However, we would also like to see some kind of
   migration strategy that moves users forward to the XPath 2.0
   replacements for these functions where these exist. For example,
   xs:boolean() in XPath 2.0 is identical to boolean-from-string() in
   XForms.  (On a point of detail, the values "true" and "false" in
   XML Schema are case-sensitive whereas this function is described as
   case-insensitive).

   A possible migration strategy might start by putting these
   functions in a separate namespace, and giving users some way to
   select the function namespaces they want to use in their
   application.

   We have not actually checked how many of the additional functions were
   already defined in XForms 1.0.

   7.7.2

   I. The if() function poses particular problems because if() is not
   allowed as a function name in XPath 2.0 for syntactic reasons.

   If your functions were namespace qualified, this would be no
   problem. This is an example where thinking of your transition
   strategy to XPath 2.0 would be important.

   7.8.8

   J. The random() function poses semantic problems because it is not
   a pure function. Users of this function will have expectations, for
   example that the function call will not be moved out of a
   predicate, which the XPath formal semantics cannot guarantee.

   Functions that depend on anything beyond their parameters don't fit
   the design of XPath.

   This is a hard area. We're quite willing to work with you on
   designing this. (: We note that this function is new in XForms 1.1
   so there are no compatibility requirements here :)

   7.9.3

   K. The decode() function needs to define an additional error, for
   the case where the data can be decoded as a UTF-8 character string
   but that string contains a character not allowed in XML.

   The name of the encode() function is much too generic, and should
   be renamed to something that indicates its purpose more clearly. In
   the description of the encode() function, "The data string is
   serialized as UTF-8" is ambiguous - it might mean (a) the parameter
   must be UTF-8, or (b) the function serializes the input string as
   UTF-8.

   Also, UTF-8 is hard-coded. There are other possibilities.

   The phrase "string of data" is redundant; you can simply say
   "string".

   In XPath 2.0, you would probably want to have two functions - one
   would return the base64 binary representation, the other would
   return the hex binary representation. Conversion of the binary to a
   string would be done by the string() function.

   These two functions are candidates for incorporating into XPath 2.N
   core. We would be interested in working with you on the design of
   these two functions.

   7.10.4

   L. The seconds-from-dateTime() function poses a particular problem
   because XPath 2.0 offers a function with the same name and
   different semantics.

   You should define whether leap second are taken into account, and
   if so, specify how.

   7.11.1

   M. Typo: "more that one instance"

   7.11.4

   N. The two-argument id() function poses particular problems because
   its semantics are very similar but not identical to the
   two-argument id() function in XPath 2.0

Please note, the Working Groups were only able to review the sections of the
document that appeared related to XML Schema and XPath.

Regards,

Michael Kay
Received on Monday, 23 April 2007 21:49:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:15 GMT