[F&O] IBM-FO-107: F&O editorial comments

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Hello,

     Following are comments on F&O that we believe to be editorial in 
nature.


------------------------------------------------------------------

Section 1.4

The type hierarchy diagram should include namespace nodes.  A namespace 
node is a distinct type of node in the Data model, so omitting it from the 
diagram is just confusing.  It also needs to be included in the last table 
in this section.

------------------------------------------------------------------

Section 1.4

In the third sentence of the first paragraph, xs:IDREFS is mentioned 
twice.

------------------------------------------------------------------

Section 1.4

In the type diagram, the line that connects xs:IDREFS, xs:NMTOKENS, 
xs:ENTITIES to xs:anySimpleType is also joined to the line from 
xdt:anyAtomicType to xs:anySimpleType.  The line from xdt:anyAtomicType 
also leads to item.  This makes it look like xs:IDREFS, et al. are 
subtypes of item, which is not the case.

The two lines into xs:anySimpleType from its subtypes should be separated 
to avoid that potential confusion.

------------------------------------------------------------------

Section 1.5

The title of this section should include xdt:untypedAny, for completeness.

------------------------------------------------------------------

Section 1.8

In the definition of "stable", "fn:current-date" should be 
"fn:current-date()", in order to be consistent with other functions in the 
list.

------------------------------------------------------------------

Section 3

The first paragraph indicates that errors must be raised through a 
reference to the fn:error function.  Some rationale as to why this is 
necessary should be provided.

------------------------------------------------------------------

Section 3.1

The example uses the prefix "xdt" for an F&O error, but Appendix D uses 
the prefix "err".

------------------------------------------------------------------

Section 4.1

The example indicates that if the first argument to fn:trace is of type 
xs:decimal, with the value 124.84, the string "124.84" is put into the 
trace data set.  However, the description of the function does not 
indicate that any items in $value are converted to xs:string.  Either the 
description of the function or the example needs to be corrected.

------------------------------------------------------------------

Section 5.1

In third sentence of the paragraph following the xs:unsignedInt example 
box, "that had a value equal to" should be "that had a typed value equal 
to".

------------------------------------------------------------------

Section 5.1

In fourth sentence of the paragraph following the xs:unsignedInt example 
box, "'atomize' the node to extract its value" should be "'atomize' the 
node to extract its typed value".

------------------------------------------------------------------

Section 7.1

In the second note, "is the of XML characters" should be "is the number of 
XML characters".

------------------------------------------------------------------

Section 7.3.1

In the first sentence of the second paragraph, "that that" should be 
"that".

------------------------------------------------------------------

Section 7.3.1

The seventh paragraph introduces the concept of a system defined default 
collation.  The term "system defined" is never defined.  Should this be 
"implementation dependent" or "implementation defined", instead?

------------------------------------------------------------------

Section 7.3.1

The second item in the numbered list indicates that fn:contains, et al. 
use the Unicode code point collation if no collation is explicitly 
specified.  This should provide some rationale.

------------------------------------------------------------------

Section 7.5

The last paragraph of this section ends "the system may reject it."  The 
term "the system" is not defined anywhere.  This should probably be "the 
processor".

------------------------------------------------------------------

Sections 7.5.1.1, 7.5.2.1, 7.5.3.1

"Unicode default collation" should be "Unicode code point collation".

------------------------------------------------------------------

Section 8.3.1.1

The following example would be helpful:

fn:not("false") returns false

------------------------------------------------------------------

Section 9.4.16.1

The second call to fn:get-day-from-date should return 1 rather than 01.

------------------------------------------------------------------

Section 9.4.18.1

In the fourth example, the result of evaluating

 fn:adjust-time-to-timezone(xs:time("01:23:00+05:00"),
                            xdt:dayTimeDuration("PT0H"))

should be the xs:time value 20:23:00-00:00.  The result of applying 
fn:get-hours-from-time to that value should be 20, rather than 16.

------------------------------------------------------------------

Section 9.6.1

The fourth paragraph begins, "A dynamic error is raised (invalid timezone 
value). . . ."  The name of the error should appear in square brackets, 
and be a link to Appendix D.  This error is missing from Appendix D.

------------------------------------------------------------------

Section 9.6.2

The fourth paragraph begins, "A dynamic error is raised (invalid timezone 
value). . . ."  The name of the error should appear in square brackets, 
and be a link to Appendix D.  This error is missing from Appendix D.

------------------------------------------------------------------

Section 9.6.2

The last paragraph before the examples begins, "If $timezone is not the 
empty sequence. . . ."  For the sake of clarity, this should probably be 
"If $arg has a timezone component and $timezone is not the empty sequence. 
. . ."

It's not strictly necessary to mention $arg in this paragraph, but it is 
not necessary to mention it in the previous paragraph either.  To mention 
it in one, but not the other is just confusing.

------------------------------------------------------------------

Section 9.6.3

The fourth paragraph begins, "A dynamic error is raised (invalid timezone 
value). . . ."  The name of the error should appear in square brackets, 
and be a link to Appendix D.  This error is missing from Appendix D.

------------------------------------------------------------------

Section 9.7.1

The third sentence of this section indicates that the difference between 
two values of type xs:dateTime can be viewed as the sum of an 
xdt:yearMonthDuration and an xdt:dayTimeDuration.  The reader might be led 
to believe that fn:subtract-dateTimes-yielding-dayTimeDuration yields the 
second part of that sum, but in fact it does not - at least not directly. 
This should be clarified.

------------------------------------------------------------------

Section 9.7.3.1

As was done with xs:subtract-times, a second example involving a value 
with no timezone and a value with an explicit timezone should be shown. 
For instance,

If the evaluation context provides an implicit timezone value of
+05:00, op:subtract-dates(xs:date("2000-10-30"),
                          xs:date("1999-11-28Z")) returns an
xdt:dayTimeDuration value corresponding to 336 days 

------------------------------------------------------------------

Section 9.7.11.1

Some other helpful examples:

op:subtract-yearMonthDuration-from-date(xs:date("2000-02-29"),
                                   xdt:yearMonthDuration("P1Y"))
returns the xs:date whose normalized value is Feb 28, 1999

op:subtract-yearMonthDuration-from-date(xs:date("2000-10-31"),
                                   xdt:yearMonthDuration("P1Y1M"))
returns the xs:date whose normalized value is Sep 30, 1999

------------------------------------------------------------------

Section 12.1

In the second paragraph, change "may" to "can" to avoid confusion with the 
RFC term.

------------------------------------------------------------------

Section 14.1.1

The seventh paragraph uses the words, "is chosen arbitrarily."  That 
should be changed to "is chosen in an implementation-dependent manner" or 
something similar.

------------------------------------------------------------------

Section 14.1.1

The eighth paragraph states, "If there are several such namespace nodes, 
it chooses one of them arbitrarily."  The clause "it chooses one of them 
arbitrarily" should be changed to "which is chosen is 
implementation-dependent."

------------------------------------------------------------------

Section 15.3.4

In the second note, "fn:max" should be "fn:min".  In addition, "lt" should 
probably be "gt".

------------------------------------------------------------------

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Received on Tuesday, 17 February 2004 20:45:43 UTC