F&O doc various comments

Dear WG,

As if the list of issues is not yet long enough, here are a few more
things you may want to consider:

It is not clear to me at all what implicit coercions on parameters are
done.  Can I use "person[age > 14]" or do I have to use
"person[age/data() > 14]" or (if I have no schema) "person[(cast as
xs:integer age/xf:string()) > 14]"  This may be out of the scope of this
document (although it does mention coercions on the operands of
arithmetic operators).

2. "permits lightweight operations wherever possible".  I don't agree.
Due to the type of literals and arithmetic operator results, almost all
integer values will have type xs:integer and have to be treated
internally as "big integers" (unlimited range) as the implementation
cannot be sure of their values.  Even if the user casts all results to
xs:int explicitly, the implementation has to check for overflow on all
arithmetic operations.  Compiling to code that simply uses machine ints
that wrap around on overflow (like Java, most C implementations, etc do)
is not possible.  I suggest giving literals like [0-9]* type xs:int and
defining arithmetic on long, int, short, byte as in Java.

2.5 Compatibility issue: For documents without a schema, I can no longer
(as in XPath 1.0) use "//person[age > 14]", because I cannot compare a
string with an integer.

3.3.1.4 The 2nd example suggests that the constructor parses character
references.  This is highly surprising.  So is it not a no-op after all?

3.4.2.4 The "only if" part in the last example is incorrect.

3.5.12.3 The collation may allow more matches starting at the same
codepoint with different lengths.  It should specify shortest or longest
match to start the result after.

10.2.5.3 Comparing attributes of an element in order is not the way to
go, as (according to the Infoset) attributes have no order.  I suggest
comparing them as sets.

10.2.5.3 "We assume value equality over simple values is defined."  It
would be better to actually define it.  Then, why not allow value-equal
for all values?  This would also benefit the definition of
xf:sublist-before, xf:index-of, etc, which can become more generic.

10.2.5.3 also needs to define equality of other nodes like comments and
PIs.

10.2.8 The copy function seems inappropriate for XPath.  I thing XPath
(unlike XQuery) should not construct new nodes.

11.2.1.3 As long as you have not specified the result of using a
sequence in a predicate, this definition is not useful.  I suggest you
consider simply dropping TO and using xf:sublist.

11.4.1.4 misses some text.

11.4.4 In index-of, it seems more consistent to use value-equal (like
value-distinct and sequence-value-equal do) instead of comparing the
string values of nodes.

11.4.8.3 mentions both using value-equal (which uses deep equality) and
comparing the typed values of nodes (which does not use deep equality).
Which is it?

11.4.9.3 "must be a sequence of comparable objects".  Where is this
defined?

11.4.9.3 "if the value of $srcval is a sequence of nodes compared
according to their string values".  Does this imply that nodes actually
are compared according to their string values?

11.4.21.3 This is not a specification of the semantics.  I suggest
"returns its argument sequence in non-determistic order".

11.5.2.1 Suggest using "node*" as parameter type in the signature.

11.5.3.3 "The specific element in a collection of redundant duplicate
elements that is retained is implementation-dependent."  A useless and
therefore confusing remark, as it is impossible for a query to tell the
difference.  (Because the duplicate nodes are by definition identical.)

11.6.5 and issue 67: As sum takes a sequence of _numbers_, eliminating
duplicates is ridiculous.

12 1st paragraph suggests that constructors take only literals.  This is
not stated anywhere and I see no reason for it.

12.1 Text (1st sentence below table) says base64binary cannot be
converted to string, table says "Y".  I suggest allowing it, as the
conversion is obvious (take the base64 encoded representation) and
useful.

12.1 Token is a subtype of normalizedString.  However, casting to the
latter removes #xD, while casting to the former doesn't.  This seems
inconsistent, as now a token can contain #xD which makes it illegal as a
normalizedString, its supertype.

12.4.1 bullet 4 and 5.  These make no sense.  I presume someone used '<'
instead of &lt; in the XML source or something like that.

12.4.2 I have not been able to find the conversion to base64binary in
the XML Schema spec.  Please give a more specific pointer.

12.5.2 According to the signature this xf:string takes a node, but the
text only mentions simple types as argument.

Issue 3: A '<' before a '{' should also start an element constructor,
not be an operator.

Issues 39, 40, 51 seem to have been resolved in the published version.

Issue 60: The copy function only has side effects if you specify that
different calls to the function also produce results with different
identities.  Of course, you will then also have to specify when exactly
a function is called (this is far from obvious).

Issue 77: Huh?  Individual characters are not in the data model, have no
literals and no constructors.  How could I ever use one in the proposed
constructor?

Issue 87: Description does not fit title, but seems to have been copied
from previous issue.

Issue 93: I don't understand how to use a collation in a substring
function.

Issue 95: Why not simply use "if empty($e) then $s else data($e)"?

Issue 97: Huh?  value-equal is defined to use deep equality (as IMHO it
should), not "to ignore nested markup".

Issue 98: Even though they can be easily defined using item-at($l,1) and
sublist($l,2), I think head() and tail() are more important than many
other functions in the document.  If, e.g., I want to take the product
of a sequence of numbers, this is impossible with "for".  I have to
define a function that does something like "if empty($l) then 1 else
head($l) * product(tail($l))".  Similarly for any function that operates
on a sequence in a way that is more complicated than processing each
element by itself like "for".

Issue 108: This is specified in
http://www.w3.org/TR/charmod/#sec-NormalizationApplication section 4.3.
Functions that modify text (like concat()) must perform normalization.
Functions that pass data (like data() calls with type string) must not.

Regards,
Bas de Bakker
X-Hive Corporation

Received on Tuesday, 28 August 2001 09:59:04 UTC