Re: HTML forms, XForms, Web Forms - which and how much?

Hi Simon,

SP: Sure, but when something can be done with either an existing concept 
or 
with a new concept, then using the existing concept seems preferable to 
me.

JB: Why would we ever write a language that allows one to say C = A + B; 
when we already have

LOAD AX, 1000
LOAD BX, 1004
ADD AX, BX
STO AX, 1008

???

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





"Simon Pieters" <zcorpan@gmail.com> 
Sent by: public-html-request@w3.org
04/30/2007 08:04 AM

To
mark.birbeck@x-port.net, public-html@w3.org
cc

Subject
Re: HTML forms, XForms, Web Forms - which and how much?







On Mon, 30 Apr 2007 14:29:28 +0200, Mark Birbeck <mark.birbeck@x-port.net> 
 
wrote:

>> Not that it does the same thing, but my point is that an author who 
>> knows
>> HTML4 can understand how the WF2 markup works without even reading the
>> spec. I think this is important, since most authors won't read the 
spec.
>
> If your argument was correct, then everyone would learn about mark-up
> simply by reading other people's mark-up, which is obviously not what
> happens. Most authors will read _articles_ by other authors, so I
> think this really is a red herring.

Wow. I really did assume that most authors learn by looking at (and 
copying) other people's source code. It's what I did, at least, and what 
people I've talked to did. (I didn't say everyone, and I didn't say that 
they do so exclusively.)

But for the sake of argument, let's assume that an author who already 
knows about HTML4+JS (doesn't matter how he learnt it) was reading an 
article about new forms stuff. The article contains markup examples. With 
WF2, by just looking at the markup examples, he can understand what the 
markup does, without reading the rest of the article. With the XFT example 
 
this is not the case because HTML4 doesn't have similar constructs.

> However, when designing languages it is certainly a good idea to
> follow the 'principle of least surprise'. For example, if we called
> the XForms attribute 'onvalue' or 'oncalculate', but made it so that
> the contents of the attribute were not an action handler, then that
> would be confusing. But hopefully that hasn't been done in XForms.

Indeed.

>> [...]
>> calculate="": Hmm... what's put inside looks like it could be JS, but 
>> the
>> attribute doesn't look like an event handler attribute. Is it? Which
>> events does it listen to? When do they fire? Can any JS be inserted 
>> here?
>> Is it JS to begin with?
>>
>> There's nothing in HTML4 that is similar to this.
>
> I agree with that. It certainly means that clear explanation is
> necessary, but it doesn't mean we should limit functionality to only
> those things that can be created using existing concepts.

Sure, but when something can be done with either an existing concept or 
with a new concept, then using the existing concept seems preferable to 
me.

> Anyway, not
> every attribute in HTML is an event handler, so why would one assume
> that @calculate is?

Every attribute that takes JS as value is an event handler attribute in 
HTML4, AFAICT.

>> Even I, who have read the XFT document, can't tell how calculate="" 
>> really
>> works or what can be put inside. How should we expect authors who won't
>> read the spec to understand it?
>
> See the first point, above; it's true that authors may not read the
> spec, but they will need to read _something_. It's simply not true
> that authors read mark-up and nothing else.

Authors do what's simplest. If they can look at or copy someone else's 
markup and also understand what it does, then why would they need or want 
to read articles or specs?

>> Shorter markup does not imply greater understanding among authors. I 
>> think
>> it is a mistake to introduce non-event-handler-but-still-JS-attributes 
>> to
>> HTML.
>
> I definitely agree, but I don't think we were discussing
> _abbreviation_ of mark-up, so much as how easy it was to mark-up some
> given behaviour. I picked a simple example that showed some output
> that was based on the values of some other data, which I felt was a
> common use-case. But I wasn't looking for the shortest way of writing
> it--I was trying to show that XForms can convey this at least as
> succinctly as any of the other proposals around, as well as providing
> a much greater level of functionality when the author needs it.

Ok.

-- 
Simon Pieters