your outstanding comments on F&O and XLST 2.0 (was: Re: transition request: XPath 2.0, XQuery 1.0, XSLT 2.0, et al. to Proposed Recommendation)

On Fri, 10 Nov 2006 13:09:31 +0100, you wrote (in message
http://lists.w3.org/Archives/Member/w3c-archive/2006Nov/0068.html):

 > * C. M. Sperberg-McQueen wrote:
 >> Each comment received before the beginning of October has been
 >> formally addressed by the Working Groups;

 > http://lists.w3.org/Archives/Public/public-qt-comments/2006Jan/0052
 > has, as far as I can tell, not been formally addressed by the
 > Working Groups.

Thank you for the correction; my apologies for the misstatement.

As regards your message 0052 of 11 January of this year, sent to the
XML Schema, XML Query, and XSL Working Groups, I think that I am at
least partially responsible for its not being tracked as a comment
against the Candidate Recommendation draft of the XPath Functions and
Operators document; my apologies. From time to time, I have made it my
practice to review comments which are not made in Bugzilla but
received only as email to the comments list for the
query/transformation specifications.  So I should have copied your
comment into Bugzilla so that it could be tracked in the normal way.

After rereading the discussion thread starting from your message, I
surmise that I did not do so because I did not realize that your
message was intended as a CR comment against Functions and Operators.
I interpreted it instead as an open-ended request for enhancement to
the regular expression language defined by XML Schema, also sent to
the other two working groups since they are interested parties in
anything that affects the XML Schema regular expression language.  My
apologies for my failure of understanding.

Alerted by your email of last Friday to the correct interpretation of
your email of last January, the XML Query and XSL Working Groups
discussed your proposal at their joint meeting today.

It was pointed out that several of your examples appear to be
expressible in the existing regex language (using, for example, the
character category Cc for control characters, or the character
category Co for private use characters, or the character block
PrivateUse for the private use area), but several members of the
Working Groups were inclined to regard your email as suggesting a
useful enhancement of the regular expression language and something to
be considered for a future version of XML Schema and a corresponding
future version of Functions and Operators.  The functionality you
describe does not appear to be necessary to meet the requirements
agreed on for the current version of Functions and Operators, however,
and so the Working Groups concluded that the change proposed is out of
scope for version 1.0 of that spec.

Some WG members suggested that implicit in your comments is the
proposition that the regular expression language defined by XML Schema
should be usable as a general-purpose regex language for Unicode data
streams, and that if the XML Schema regex language is to fill that
role, it should perhaps be spun off into a separate specification;
others were not persuaded by this idea, but I record it for
consideration by those who may read this email thread.

In the end, the Working Group determined to treat your email of
January as a request for enhancement, to be considered as a possible
requirement for future version(s) of Functions and Operators, but not
to introduce the suggested change into version 1.0 of that spec.

Please let us know whether you are satisfied with this action on your
suggestion of 11 January.


 >> There have been no formal objections raised against any of these
 >> documents since their publication as Candidate Recommendations.

 > For
 > http://lists.w3.org/Archives/Public/public-qt-comments/2006Jan/0084
 > I've been waiting to a response to the former issue in order to
 > consider whether the Working Group's response is acceptable to me.

The Working Groups reviewed their action of last March on this issue,
tracked as Bugzilla issue 2732
(http://www.w3.org/Bugs/Public/show_bug.cgi?id=2732) and reaffirmed it
this morning.  The suggestion made is out of scope for version 1.0 of
the Functions and Operators spec, and should be considered as a
request for enhancement for future versions, if any.

I thank you for clarifying the status of your response on this issue;
my statement that there had been no formal objections was based on the
theory that if an issue is closed in March (as bug 2732 was) and
nothing is heard from the originator by October, it's usually safe to
interpret the originator's silence as consent.  As illustrated here,
"usually safe" does not mean "always safe".


 > For
 > http://lists.w3.org/Archives/Public/public-qt-comments/2006Jan/0083
 > I have not received an official response either; that Michael Kay's
 > re- sponse is not acceptable to me I have explained in the ensuing
 > thread.

The Working Groups also re-considered this question, and reaffirmed
the XSL Working Group's earlier decision that this is an editorial
comment, with action to be left to the discretion of the editor, who
chose in this case to make no change to the text.

On this question, I will note (speaking here for myself, not for the
Working Groups) that in my experience, native speakers of German are
more apt than native speakers of English to find the use of the word
"both" confusing in passages like the one you commented on.  The
distinction made in German between "jeder" and "beide", as in

   Jedes Element (or: Jedes dieser Elemente) ist fakultativ.
   Beide Elemente sind fakultativ.

is (I believe) somewhat more consistent than the similar distinction
in English between "each" and "both", as in

   Each element is optional.
   Both elements are optional.

Over the years, I have come to believe that when an English speaker is
ALWAYS careful to distinguish "each" and "both" in sentences like
these, it's because they have learned German and are re-importing the
German distinction into their English usage.  That's certainly the
case for me.

Whether my linguistic speculation is correct or not, however, it is
the view of the XSL Working Group (and of the XML Query Working Group,
for what it's worth) that the passage is not inaccurate or misleading
as written, and that the issue is clearly editorial, not substantive.
On the question of possible improvements to the flow of the passage,
different readers may well have different feelings.  Like many Working
Groups, the XSL Working Group chooses in most such cases, and in this
case, to trust to the stylistic sense of the editor.

I am sorry that we have not found a way to accommodate your
suggestion, but in the last analysis we have to trust our own ear for
clarity and correctness, and your proposed amendment to the text has
not persuaded our ears.


If I do not hear from you otherwise before the director's call on this
transition request (scheduled for Thursday of this week), I will
report that you are making a formal objection on each of these three
decisions by the Working Groups, and ask the director to review the
Working Group's decision on them.

Thank you.

--Michael Sperberg-McQueen
   W3C staff contact, XSL Working Group
   Alternate staff contact, XML Query Working Group

Received on Wednesday, 15 November 2006 04:39:54 UTC