W3C home > Mailing lists > Public > www-archive@w3.org > May 2007

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 5 May 2007 17:24:54 -0700
Message-Id: <661679A7-7C39-4B8A-8EB1-B0F88B6720DD@apple.com>
Cc: www-archive@w3.org
To: John Boyer <boyerj@ca.ibm.com>

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  
- 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.

Received on Sunday, 6 May 2007 00:25:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:11 UTC