current status of qt review

Hi all,

As an input to the telecon today, here is a list of the responses to our  
comments.

Best, Felix.


http://www.w3.org/Bugs/Public/show_bug.cgi?id=1333 (Reference to IRI)
Felix,
In meetings on May 19 and June 7, the Query and XSLT working groups  
considered
this comment. The working groups feel that it is undesirable to globally  
change
all occurrences of "URI" to "IRI" because many terms such as "base URI"  
are in
common use throughout the family of XML-related specifications. However,  
the
working groups agreed to make the following changes:
  (1) In the XPath and XQuery specifications, replace references to RFC  
2396 with
references to RFC 3986 and 3987.
(2) In the XPath and XQuery specifications, Section 2 (Basics), add the
following paragraph: "Within this specification, the term URI refers to a
Universal Resource Identifier as defined in RFC 3896 and extended in RFC  
3897
with the new name IRI. The term URI has been retained in preference to IRI  
to
avoid introducing new names for concepts such as 'Base URI' that are  
defined or
referenced across the whole family of XML specifications."
(3) In the XQuery specification, Section 2.4.5 (URI Literals), add the
following note: "The xs:anyURI type is designed to anticipate the  
introduction
of Internationalized Resource Identifiers (IRI's) as defined in [RFC  
3987]."
We hope that these changes will address your concerns. Please let us know
whether you find these changes to be an acceptable response to your  
comment.
Regards,
Don Chamberlin (for the Query and XSLT working groups)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1334 (time zones)
The XML Query WG and XSL WG considered this comment at our May F2F meeting.
We must respectfully decline to remove the Implicit Time Zone.
The XML Schema datatypes xs:date, xs:time, and xs:dateTime allow values  
both
with and without timezones. As a consequence of this, XML Schema says that
some values with timezone and some values without timezone are  
incomparable.
Our WGs considered this issue and decided that we must be able to use  
values
of these types in an order by clause, which requires us to have a full
ordering for these values.
We considered a number of alternatives:
- disallow comparison of values with timezones to those without timezones
- define pairs of subtypes that require a timezone and do not allow a
timezone, respectively. Comparison would only be allowed on these subtypes.
- infer Z if no timezone was specified
- allow every comparison operator to specify a timezone that would be used
for values without a timezone
We decided on the use of an implicit timezone (part of the dynamic context)
whose value is implementation-defined. A user who does not wish to use this
feature can use of fn:adjust-dateTime-to-timezone,
fn:adjust-date-to-timezone, or fn:adjust-time-to-timezone in their query to
apply a specific timezone to their values before they are used in a
comparison.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1335 (section on  
normalization)
This comment was discussed jointly by the Query and XSLT working groups on  
May
19, 2005. The working groups believe that each usage of the term  
"normalize" in
our documents is made clear by the context in which it appears. The working
groups decided not to make any changes to the XPath and XQuery documents in
response to this comment.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1339 (accessor to the data  
model should rely on IRI)
------- Additional Comments From Norman.Walsh@Sun.COM  2005-06-07 15:36  
-------
I think this should be closed per
http://lists.w3.org/Archives/Member/w3c-query-editors/2005Jun/0011.html
Which says, briefly, that we'll apply a systematic change to the documents
explaining why we use URI and how it relates to IRI.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1340 (value of CES during  
serialization)
Per the 7 June 2005 telcon, the QT groups have elected to reject this  
comment.
The [character encoding scheme] in the generated infoset has no value (it  
can't
have a value because we didn't start with an encoded sequence of octets.
The serialized data model *is* a sequence of octets and therefore has no
[character encoding scheme] property at all.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1342 (example with default  
value for currencies)
Per the 7 June 2005 telcon, the QT groups have elected to reject this  
comment.
The schema includes the comment
<!-- This example is for data model illustration only.
      It does not demonstrate good schema design. -->
and it's clearly a toy. Whilst I agree with the spirit of the comment,
getting the example right is tricky and requires meticulous attention
to detail. We're not inclined to change it for this reason

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1343 (regular expression for  
monetary data type) accepted

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1350 (changing URI to IRI)
Felix,
In meetings on May 19 and June 7, the Query and XSLT working groups  
considered
this comment. The working groups feel that it is undesirable to globally  
change
all occurrences of "URI" to "IRI" because many terms such as "base URI"  
are in
common use throughout the family of XML-related specifications. However,  
the
working groups agreed to make the following changes:
(1) In the XPath and XQuery specifications, replace references to RFC 2396  
with
references to RFC 3986 and 3987.
(2) In the XPath and XQuery specifications, Section 2 (Basics), add the
following paragraph: "Within this specification, the term URI refers to a
Universal Resource Identifier as defined in RFC 3896 and extended in RFC  
3897
with the new name IRI. The term URI has been retained in preference to IRI  
to
avoid introducing new names for concepts such as 'Base URI' that are  
defined or
referenced across the whole family of XML specifications."
(3) In the XQuery specification, Section 2.4.5 (URI Literals), add the
following note: "The xs:anyURI type is designed to anticipate the  
introduction
of Internationalized Resource Identifiers (IRI's) as defined in [RFC  
3987]."
We hope that these changes will address your concerns. Please let us know
whether you find these changes to be an acceptable response to your  
comment.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1352 (table on serialization  
parameters)
I have updated the serialization parameters table in the XQuery document  
to be
consistent with the table in the Serialization document. But I need help  
on one
of the parameters: "standalone". The XQuery document says the default for  
this
parameter is "none". The serialization document says the valid values
are "yes", "no", and "omit". This is a mismatch. The "standalone"  
parameter is
closely related to the "omit-xml-declaration" parameter, whose default  
value is
implementation-defined. I suggest that we also define the default value
for "standalone" to be implementation-defined.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1360 (normalization  
sensitivity for operations like e.g. concat and join)
The joint WGs agreed on the 6/7/2005 telcon to add an example to the  
discussion
of fn:concat that explains how fn:normalize-unicode can be used to  
normalize the
result of an fn:concat operation.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1465 (Security conditions in  
App. I 6) accepted

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1483 (test for surrogates)  
accepted

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1484 (Reference to UTS 18)
It was decided on the joint WG telcon on June 7, 2005 to close this  
comment by
adding a note to the F&O section 7.6.1 that says "It is recommended that
implementers consult [Unicode Regular Expressions] for information on using
regular expression processing on Unicode characters."

Received on Tuesday, 21 June 2005 14:49:03 UTC