Re: [off] Re: Forms Task Force Charter Requirement

On May 5, 2007, at 10:47 PM, John Boyer wrote:

>
> Maciej,
>
> I think I understand now why we have been in disagreement.
> You articulated that using something (XForms) as the basis for  
> review pretty much means adopting the text of the thing. And that  
> adopting both WF2 and XForms as the bases for review means  
> something along the lines of "concatenating" or merging them.
>
> This is very literal and not at all what "basis for review" means  
> to me.  A document to be used as a basis for review is one that  
> will be carefully scrutinized for content that should be used to  
> influence the creation of something new.

My understanding of "basis for review" in this case is:

- A copy of the text that become a basis for review will be checked in
- This text becomes a W3C Editor's Draft
- The text is modified by the editors in response to review comments  
from the group and others
- Once sufficient review has been done, the text is published as a  
W3C First Public Working Draft

Note, however, that the text being checked in and edited further does  
not imply a committed decision to anything in the text.

This is what the Apple/Mozilla/Opera proposal on which Dan based his  
proposed resolution clearly stated. Although it's true that the  
resolution itself is less clear on this point.

I would appreciate if Dan could clarify whether indeed it is expected  
that the review text will be checked in and edited as the basis for a  
future FPWD.

> Parts of the new thing *may* (in the RFC 2119 sense) look very  
> similar to parts of the documents used as the bases of review, but  
> they may also not.  In this case, using XForms and WF2 as the bases  
> for HTML5 Forms means (to me) that in cases where the two took  
> different paths to satisfy the same requirement, then the  
> underlying requirements which caused the divergence would be  
> examined to pick the best way forward, and if at all possible that  
> way would include the ability to map the solution onto the XForms  
> architecture.

This would imply that we'd start editing with a document that had an  
empty Forms section. It also seems like a request to rehash every Web  
Forms 2 feature from scratch, despite the existing design and  
implementation experience with WF2, and even if there is no technical  
objection to a given feature as such. I would find that unacceptable  
as it would cause needless delay and I do not see how it would  
improve the quality of the finished product. Instead I'd like to  
focus on changing the parts of WF2 that do have some technical  
objection.

> XForms is really a misnomer since it is a Turing-complete XML data  
> processing language.  Therefore, alignment with XForms architecture  
> is theoretically possible as long as the chosen solution is  
> computable.  However, the semantics of "alignment" to XForms  
> includes a degree of practicality (e.g. superlinearity of  
> transformation is not really practical).

I'm not sure what this means exactly.

> Anyway, given that my definition has a lot to do with your #2, it  
> seems that we are in violent agreement on how to proceed with  
> XForms, quite apart from the difference in how we understand the  
> words "basis for review" and its implications for what we think  
> will be happening with WF2 as a result of this questionnaire.

It sounds like we now agree (roughly) on what should happen with  
XForms, but not on what should happen with WF2. Do you have a  
compromise to propose?

> I think it would now be unreasonable to complain further about the  
> author of our charters for any ambiguities that have arisen given  
> how this has been going.
>
> And finally, it does seem that Dan should be made aware that there  
> is a fairly serious divergence of understanding on the meaning of  
> "basis for review" which affects the answer to the questionnaire.

Indeed. I hope he can clarify.

>
>
> 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
>
>
>
>
> Maciej Stachowiak <mjs@apple.com>
> 05/05/2007 05:24 PM
>
> To
> John Boyer/CanWest/IBM@IBMCA
> cc
> www-archive@w3.org
> Subject
> Re: [off] Re: Forms Task Force Charter Requirement
>
>
>
>
>
>
> On May 5, 2007, at 4:41 PM, John Boyer wrote:
>
> >
> > Maciej,
> >
> > mjs> You've stated that you are unwilling to drop your Formal
> > Objection
> > unless you get exactly what you asked for. Since I disagree that  
> what
> > you asked for is good, if you are unwilling to budge, I don't see  
> how
> > compromise is possible. Unless you think compromise consists of me
> > just agreeing with your existing position.
> >
> > I think what you want is that WF2 be used as *the* basis for
> > review.  What I want is that XForms also be
> > used as *a* basis for review along with WF2.
>
> I don't think it makes sense to adopt XForms as a basis for review
> and further editing for the following reasons:
>
> - It is a W3C standard being actively maintained by another working
> group.
> - It defines a wholly separate language in a different namespace.
> - It defines elements and attributes which, if placed in the HTML
> namespace, would be incompatible with existing HTML elements with the
> same names.
>
> For these reasons, it cannot as-is be a basis for anything in HTML.
> It would be like adopting SVG or MathML as a basis for review - even
> if we wanted to add graphics or math capabilities to HTML, it would
> not be right to start by appending those specs to the end of the HTML
> spec. Instead, selective features would be moved and recast as parts
> of HTML, instead of separate languages.
>
> We also know based on past experience that XForms is unacceptable to
> browser implementors. However, the XForms working group declined so
> far to take that feedback into account in the XForms spec. Adopting
> something as a starting point that is known to be unacceptable to
> many of the likely high-volume implementors seems like an
> unproductive way to proceed, as we'd have lots of work to do to
> remove the problems before we had anything publishable.
>
> My original position was that the HTML WG should completely ignore
> XForms and the Forms Task Force. However, I have moved to a
> compromise position that I think is a reasonable middle ground, as
> described below.
>
> Possible sound ways to proceed to include more XForms capabilities in
> HTLM Forms would be:
>
> 1) Adopt as a basis for review something based on XForms but that is
> rewritten to be a set of HTML elements, and with incompatibilities
> with classic HTML removed. However, no one has written a document
> like that, and we don't have time to wait for it to be written. So I
> don't think this is a practical option.
>
> 2) Consider XForms as a potential source of designs for additions to
> HTML Forms, without literally adopting the text. WF2 already did this
> to a large extent, but I am seeing it happening even more, such as
> with the review and likely revision of the repetition feature.
>
> 3) Define more clearly what we mean by architectural consistency, so
> regardless of the starting point we know that the endpoint satisfies
> the requirements.
>
>
> I expect #2 will happen regardless of official decision by the group,
> but I would not object to making it a formal resolution of the group.
> I already proposed a way to do #3. I think these are reasonable
> middle grounds between adopting the text of XForms and completely
> ignoring it. Do you have other possible compromise proposals?
>
>
> Your other Formal Objection was to Dave and Ian as editors, and your
> proposed alternative is to add someone from the Forms WG as a co-
> editor for the Forms section. I also disagree with that, as I think
> it would lead to a lot of arguing and slow down work; and because I
> think editors should be chosen based on their qualifications and
> experience, not based on being members of an external Working Group.
>
> My proposed compromise for that is that the HTML WG and Forms WG
> together in the Forms Task Force co-edit a Forms Architectural
> Consistency Requirements document which XForms and HTML Forms both
> then satisfy. I think this will accomplish the desire for closer
> alignment with less likelihood of conflict delaying progress. Do you
> have a different proposed compromise?
>
> > Your writings imply you believe I am being rigid and exclusionary;
> > this makes no sense given that what
> > I want includes what you want and what you want excludes what I  
> want.
>
> I think what you want is impractical - concatenating WF2 and XForms
> does not result in a single specification that we can edit further.
> However, XForms should definitely be mined as a source for feature
> ideas that can be cast into a more HTML-friendly form.
>
> > You can feel free to publish this to the list if you like, but it
> > seemed unimportant to bore the whole group
> > with this until we can sort out between us why you and I are not
> > seeing eye to eye.
>
> I cc'd www-archive for the record.
>
> Regards,
> Maciej
>
>
>

Received on Sunday, 6 May 2007 06:54:43 UTC