Fw: PR transition request for XForms 1.1

As requested on the XForms 1.1 PR transition call this morning, I am 
forwarding this email thread to our list as part of the public record. 

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw


----- Forwarded by John Boyer/CanWest/IBM on 08/13/2009 09:39 PM -----

From:
John Boyer/CanWest/IBM
To:
ralph@w3.org
Cc:
plh@w3.org, chris@w3.org, Steven Pemberton <steven.pemberton@cwi.nl>, 
steven@w3.org
Date:
07/30/2009 05:30 PM
Subject:
Fw: PR transition request for XForms 1.1


Hi Ralph,

At Chris's request, I am forwarding my email from July 7 in which I sought 
to answer the questions you had asked about our "important changes" list. 
I had sent this email to Steven on July 4, since your questions arrived 
through him.  However, by July 7, I realized that I had better send it 
directly because my own vacation was coming up at the end of that week. 
Later the same day, I added an abridged version of the same to the SOTD. 

Despite not arriving as formal comments on www-forms-editor (and hence not 
appearing in the disposition of comments), the process document also calls 
for identification of "important" changes in the transition request, which 
is where the original list appeared.  The interpretation of "important" 
was the set of changes outside of the formal comments that PR reviewers 
would reasonably want us to explain why they are not substantive (or to 
say they are substantive and go to a second last call).  The 
interpretation of substantive was addition of, change to, or removal of a 
non-trivial behavior, which is in keeping with the CR phase being the 
demonstration of implementability and readiness to be considered for 
recommendation for broader adoption in software.  The changes we have made 
are important because they are changes, but they are trivial with respect 
to implementability and fundamental features and operations are unchanged. 
 The notes below explain why this is so in each specific case and also 
indicate whether the test suite was affected or changed in some way.

As further due diligence, Chris asked me today to identify any specific 
test suite tests that were affected or changed in some way.  I have added 
these below each of the notes using <note></note> tags.

Thank you,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw


----- Forwarded by John Boyer/CanWest/IBM on 07/30/2009 11:22 AM -----

From:
John Boyer/CanWest/IBM
To:
ralph@w3.org
Cc:
"Steven Pemberton" <Steven.Pemberton@cwi.nl>, plh@w3.org, chris@w3.org
Date:
07/07/2009 09:15 AM
Subject:
Re: Fwd: Re: PR transition request for XForms 1.1


Hi Ralph,

Steven forwarded to me the message from you (below).  He also told me that 
Chris would be on the call due to Philippe being on holiday, so I added 
him to the cc list.

In preparation for the call, I'd like to provide the following information 
in answer to your questions:

The important changes list appearing in #4 of the PR transition request 
can be added to the status of the document and in fact I will update the 
document later today to do just that.

All changes are based on a rigorous, year-and-a-half long implementation 
(CR) period, during which time we received implementer feedback and web 
community feedback, not just formal comments.  The working group takes 
very seriously its responsibility to be responsive to feedback from all 
channels, including issues that arise within the group since it contains a 
number of implementers.  Thus we take appropriate action on the spec 
regardless of whether it arises from a comment to www-forms-editor.  The 
disposition of comments reflects the comments on the specification, which 
are set to www-forms-editor, but in the interest of full disclosure, the 
important changes list contains additional entries beyond those.  However, 
none of these important changes represent substantive differences from the 
CR, and the justification of this claim for each is provided below.

1) The targetref and targetid attribute changes represent a simple change 
of spelling of how to activate the feature, not a removal of a feature nor 
any substantive difference in its implementability.  This was necessitated 
by web community feedback regarding the adoption of XForms tags into web 
page markup without the use of namespace qualification.  In the web 
community recently, XML namespaces have had challenges, and we are being 
responsive to the web community by avoiding an attribute name that is 
elsewhere used for a different purpose in web pages.  This amounted to a 
name change, which has been reflected in the test suite.  Moreover, we 
have even left the original spelling intact for "backward compatibility" 
to further mitigate any concerns.

<note>
Tests 11.1.t, 11.10.a, 11.10.b and 11.10.c were changed to use targetref 
rather than target in the submission element.
Tests 4.3.6.a, 4.3.8.a, 4.7.a, 8.1.5.c, 8.2.(2,3).(a,b,c), 
10.8.(1,2,3).(a,b,c), 10.8.(a,b,c,d,e), and 11.2.a were changed to use 
targetid rather than target in the dispatch action.  This action is used 
more heavily in the test suite than in practice to activate various 
features being tested with less human intervention.
Implementers were already passing these tests when the name was target, 
and the implementation of the fallback from one attribute to the other is 
both a trivial programming task and one designed to support a deprecated 
name, so testing of support for targetref and targetid was deemed 
sufficient for the test suite.
</note>

2) The xforms-link-error was removed as a formal event because all 
implementations produce an error according to the normal behavior of the 
web browser, to which the linking behavior is delegated.  The working 
group uniformly agrees that the user should be told of a link failure, but 
that it should be done in a way that is natural to the web user.  This 
change simply reflects what implementers are doing, and the test suite now 
reflects the more generalized behavior.

<note>
Tests 10.14.(a,b) and 10.14.1.(a,b) now simply state what should happen 
when the load action happens without trapping the xforms-link-error if 
they don't.  A test 10.14.c of load failure was removed since the 
conveyance of load failure is implementation specific (and for most 
implementations it will be according to the behavior of the browser 
hosting the XForm).
</note>

3) The card-number datatype definition was relaxed, so there exist no 
conforming documents that become non-conformant.  It is important to 
identify a datum as a card number, but this is so that the proper user 
interface can be selected by user agents.  The act of validating the data 
is performed via the card-number() function can be invoked to apply Luhn's 
algorithm, which cannot be expressed in terms of XML schema datatype 
patterns and also does not have the length restriction.  The test suite 
was amended appropriately.

<note>
Tests 5.2.7.(a,b) were modified to remove tests of a length restriction. 
Although the datatype is not invoked in test 7.6.2.a, it should be noted 
that this test does test whether the Luhn algorithm is working on card 
numbers of lengths that would not have passed the length restriction we 
removed.
</note>

4) Regarding the definition of data validity, the non-empty when required 
component was added as a matter of conceptual simplification and reduction 
of exceptional language.  Validity has always applied to both UI controls 
and to the ability to submit completed data.  There has been no change to 
the conditions under which an XForm can submit data, nor to the 
requirements on UI controls to report problems.  There was concern prior 
to the implementation phase that it might be necessary to signify 
required-but-empty by means other than the indication of invalid, but 
those concerns were proven to be unfounded during the implementation 
phase.  Thus, since user interface controls are able to reflect the state 
of the model that will be enforced by the submission logic, there is no 
substantive change of behavior.  There was no reasonable change to the 
test suite as the UI controls have always been required to reflect when 
the user is required to enter information.

<note>
As mentioned, there was no change to the test suite as all reasonable 
forms are expected to behave in the same way.
</note>

5) The separator attribute default was changed to ampersand.  This is the 
separator for the tag-value pairs in a url encoded submission, and it is 
little more than an editorial oversight that the default was still 
expressed as semi-colon.  The default on the web is unequivocally the 
ampersand, and the semi-colon is only needed for a handful of web services 
that use it instead of the web default ampersand.  The test suite reflects 
this change.

<note>
Test 11.1.u was changed.
</note>

6) Implementation-specific eventing for document replacing submissions is 
identical in rationale to #2 above.  When the whole document is being 
replaced, the submission is delegated to the web browser, and thus it is 
the web browser's normal behaviors that govern what happens in the event 
of success or failure.  There are no known implementations that have ever 
supported xforms-submit-done and xforms-submit-error event handling in the 
case of a document replacing submission as those events are designed for 
use with instance data replacing submissions, which is already what is 
tested by the test suite.

<note>
No test suite changes for this.
</note>

7) Instance data replacement of submissions has been defined directly in 
terms of insert, delete and setvalue actions as a matter of architectural 
consistency with the rest of the XForms processing model.  Although it is 
widely understood that data mutations must occur according to the actions 
in order to ensure that the declarative implications of such mutations are 
enforced, some implementers found that the specification did not spell it 
out clearly enough, but as a result of not doing it this way, they found 
bugs in their implementation.  As such, it is an important change (i.e. 
noteworthy for implementers) but not a substantive change in that it was 
always necessary for correctness, which was clear to many implementers all 
along.  There are no changes to the test suite for this.

<note>
No test suite changes for this. 
</note>

8) The combine attribute for submission headers was found to be necessary 
by implementers during the implementation phase in order to be specific 
about how to combine the author's headers and, where permitted by the 
protocol implementation, how to combine with those provided normally by 
web browsers.  This was an adjustment of the feature based on 
implementation experience and affected the test suite, and so it was 
important.  However, the substantive change would have been removing 
submission header control as this would have impacted the ability to 
interact with REST services.  Due to the adjustment, our ability to meet 
the requirement to access REST services via XForms submissions is 
maintained.

<note>
The affected tests are in Section 11.8.  The octets of the test suite 
tests themselves were not modified, but the interpretation of what 
constitutes a pass from several implementers was affected due to the use 
of automation techniques on the test suite.  The issue arose from the 
implementer of the FF plugin, who simply wanted to know which flag setting 
to use for merging the XForms headers with those of the user agent 
(append, prepend or replace).  The working group does not view these 
possibilities as materially affecting interoperable implementation because 
they are very common programming tasks.  The tests require that the proper 
headers are available in the submission and that has not changed.
</note>






From:
"Steven Pemberton" <Steven.Pemberton@cwi.nl>
To:
John Boyer/CanWest/IBM@IBMCA
Date:
07/01/2009 03:55 AM
Subject:
Fwd: Re: PR transition request for XForms 1.1





------- Forwarded message -------
From: "Ralph R. Swick" <swick@w3.org>
To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
Cc: plh@w3.org, w3t-archive@w3.org
Subject: Re: PR transition request for XForms 1.1
Date: Mon, 29 Jun 2009 22:23:24 +0200

When (what week?) would you like to have the transition call?

I think Philippe is resigned to having to attend a call during his
vacation.
I hope you have coordinated some expectations with him.

Content-related question in-line below.

At 11:38 AM 6/24/2009 +0200, Steven Pemberton wrote:
...
>          4. Report of important changes to the document (since CR)

I don't see these changes called out in the draft CR document.

>                * targetref and targetid attributes added with the aim of 
 
> eventually
> phasing out target attribute
>                * xforms-link-error event removed in favour of 
> implementation-specific
> means of indicating a linking error
>                * card-number datatype relaxed to allow any number of 
> digits to
> accommodate application implementation requirements which arose during
> implementation phase (e.g. Canadian social insurance numbers)
>                * Non-empty when required was applied to validity 
> conditions of UI
> controls, not just submission.
>                * separator attribute default corrected to ampersand for 
> urlencoded
> submission serialization
>                * Implementation-specific eventing for submissions that 
> replace the
> document
>                * Defined submission data replacement directly in terms 
> of XForms data
> mutation actions (insert, delete, setvalue)
>                * Added combine attribute to submission/header element to 
 
> address
> implementation experience feedback concerning how to merge headers
> produced by XForms processing with those produced by the user agent.

Some of these might be claimed to be substantive.  Which of them
are in response to comments (and therefore could be connected
to the Disposition of Comments)?  Which of them have impact
on the test suite and implementation report?