XForms 1.1 CR draft; reference implementations? Also, xforms-ouptut-error issue resolved

Hello all,

In preparation for the face-to-face, I have converted the status of the 
XForms 1.1 document to CR.  The status section is important to consider as 
you think about resolving to transition to CR.  In the status, you will 
see that it currently says "no features at risk" and "no preliminary 
interop report".  Consider the features at risk because if we list any, 
and then they do not get implemented, then we can remove them without 
going back to last call.  But if we remove features not listed as at risk, 
the director must send us back to last call.  Regarding the preliminary 
interop report, it seemed justified not to have one due to wide deployment 
of XForms 1.0. 

The issue of providing a reference implementation is important.  I need 
working group members to consider whether they can provide an 
implementation report. The W3C rules for advancement are very slightly 
more relaxed than they were for XForms 1.0.  We must only show two 
interoperating implementations of every feature.  It is not required that 
we have one full implementation.  However, if only two companies agree to 
provide a reference implementation, then both must be full implementations 
or we lose features.  Hence, the more the merrier, but you don't have to 
pass every test in order to add some value.  You may be asked to add some 
features so that we can get complete test coverage (or again we would lose 
features), but it is less stringent if we get lots of implementation 
reports.  Please send email to this list as soon as you can to indicate 
whether you intend to provide an implementation report.  This isn't a 
contract, but only send if you are sure at this time that you will be able 
to do it.

Finally, as a separate note, this CR draft also contains the text for 
resolving issue 60, which provided an inadequate definition of when 
xforms-output-error might occur.  I found it necessary to merge bullets 4 
and 5 in xforms-refresh (which was also needed more generally anyway), at 
which point it was easy to clarify that this error can occur on output 
creation or refresh if the data is inappropriate for the mediatype (e.g. a 
non-image given when the declared mediatype is image/*).

Best regards,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
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

Received on Tuesday, 30 October 2007 15:00:42 UTC