- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 5 May 2007 23:54:32 -0700
- To: John Boyer <boyerj@ca.ibm.com>
- Cc: www-archive@w3.org, connolly@w3.org
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