Re: Straw poll on name of "streamlined syntax" spec

Hi Nick,

I agree with the various points that you make, but not your
conclusion. I think it's a good thing if we move away from the idea
that there is some 'other thing' that is distinct from XForms; I'd far
rather we simply say we have XForms, which supports a range of ways of
expressing things, some of them more appropriate in certain situations
than others.

One of the motivations behind the work was to ensure that there was a
neat transition from HTML Forms to 'full XForms'. That's as much a
part of the 'on-ramp' as making things easy to understand, because in
the past, if you wanted to use XForms you had to completely replace
your HTML Forms with XForms.

To address this motivation we needed a twin strategy.

The first side of the strategy is to ensure that 'XForms proper'
didn't have dumb limitations in, that helped no-one, and hindered
adoption. You mention the infamous 'make the model optional' example,
a debate which ran for a while on our list. :) But another example
that I like to give is that to get a range control in XForms, you need
to specify a datatype on the instance data...

...which means you need both an instance and a bind statement...

...and therefore a model element.

In other words you cannot use sliders when you are using lazy authoring!

This means that if you were writing a book on XForms, you'd have to
make the range control an 'advanced concept' that could only be
introduced in chapter 20 or 21. ;)

Anyway...assuming that we sort out these kinds of silly things, the
second side of the strategy was to try to make it so that an HTML Form
was at one and the same time, an XForm.

In my view the poster-child for this is being able to make the
following kind of tiny step from HTML Forms to XForms:

HTML Forms:

  <input name="fn" />

  <input name="sn" />

XForms:

  <input name="fn" />

  <input name="sn" />

  <xf:output value="concat('Hello ', fn, ' ', sn)" />

(Put aside whether you need the namespace prefix.)

The simple addition of one XForms element to an HTML Form, in this
way, is only possible if we can say that the entire XForms
infrastructure (MVC, dependency-graph, MIPs, and so on) was *already*
present in the HTML Form example. And that in turn is only possible if
we 'interpret' the already existing HTML elements and attributes for
forms, in an 'XForms way'.

So although it's true that we're adding @name to XForms for
consistency, the prior step is that we have to express the way that
@name works in 'XForms language'. And the way we decided to do that
was not to say that @name maps to @ref as I think you are saying, but
rather that @name maps to @bind plus a generated <bind> statement.

Anyway, I don't want to get into the detail of the features, so much
as to try to stress this two-fold approach.

In my view, the important aspect of this is that unlike our previous
work with XForms where authors and solution architects were forced to
make a 'leap' from HTML Forms to XForms -- and therefore either
rewrite their previous applications, or evolve their previous
applications using Ajax instead -- we are now saying that there is a
continuity between HTML Forms and XForms, and that people can use
small parts of XForms as they want.

Regards,

Mark

On Tue, Nov 18, 2008 at 11:42 AM,
<Nick_Van_den_Bleeken@inventivegroup.com> wrote:
>
> I'm not sure that what is in the stream lined syntax document (or (X)FormsA)
> is only about making XForms easier to use (the on-ramp) . Maybe I'm seeing
> it to blak&white but I also saw the document as making it possible to take
> existing HMTL forms and letting an XForms processor process those documents.
>
> I see two problems with thinking that the constructs defined in the stream
> lined syntax document will make XForms easier to use:
>
> - Some attributes are introduced solely because they were present in HTML
> forms even if they were replaced by other constructs in XForms.
> You have for example
> * a type attribute that controls the 'type' of the control in XForms we do
> this based on a combination of the element name and the data type of the
> data node. It even gets 'worse' because when the type contains special
> values radio or checkbox (case insensitive) it triggers special
> initialization behavior.
> * The checked attribute is 'duplication' of the value attribute in another
> 'value-space' it is just a translation that happens on form initialization
> (remark: HTML form authors would expect this mapping to also work when the
> form is running)
> * The multiple attribute just duplicates out select versus select1 element
> names
> * The name attribute is like our ref attribute but doesn't change the inline
> evaluation context. Handy, but I think the difference is going to confuse
> our 'simple' users.
> * ….
> In my opinion these examples show that this specification isn't solely at
> making XForms easier to learn, it even makes live for experienced XForms
> authors more complicated (they have to learn more techniques to accomplish
> the same goal)
>
> - Today a lot of web form authors are using one or multiple of the very
> popular toolkits (Dojo, YUI, JQuery,…). These toolkits provide the authors a
> lot of handy new elements and attributes. Some of those toolkits even
> support a Declarative and Programmatic model. If the goal is to make the
> transition from 'today's web forms' to XForms really easy, i.e. just enhance
> the document you have today with XForms features. This caused me to start
> doubting if this document achieves what 'we' (maybe this should be just 'I')
> think it is achieving. Making the transition from 'today's web forms' to
> XForms easier.
>
> I always thought XForms 1.2 was about making common and/or simple forms easy
> to write in XForms. Make the model optional, allow the user to override the
> properties of the submission in the submit control (or even make the
> submission element in the model optional, so an implicit submission), allow
> MIPs to be specified on the UI controls as a shortcut of writing the binds,…
> These things make writing an XForms document easier for both new authors and
> experienced authors, if we design it right it will feel natural and doesn't
> needs to break our MVC model, you can think of it as an MVC on top of
> another MVC.
>
> I know it is a bit late to come with such a drastic comment, but the
> original name suggested that it was 'just' something to make life easier for
> 'plain old HTML form authors' (sorry to call them like this but I can't find
> a better naming) and now it is becoming more and more just 'pure XForms'.
> And I want to keep fighting for XForms because I think we can make it an
> even better language by keeping it simple and making things that are common
> even simpler then they are…
>
> Regards,
>
> Nick Van den Bleeken  -  Research & Development Manager
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email: Nick_Van_den_Bleeken@inventivegroup.com
>
> public-forms-request@w3.org wrote on 17/11/2008 19:19:02:
>
>>
>> Using XForms 1.2 for just the streamlined syntax by itself is
>> tempting, though it would require either
>>
>> 1) that we either merge the "XFormsA" material into the full spec, or
>>
>> 2) that we publish "XFormsA" as a separate module and also a rev of
>> the full XForms spec that only makes the changes needed to support
>> "XFormsA"
>>
>> The latter of the above approaches has several advantages:
>>
>> i) the "XFormsA" content is highlighted to the web community as a
>> primer or on-ramp, rather than being lost in and amongst the full spec
>> ii) as a module, "XFormsA" may be viewed as a conformance profile (a
>> bit like "Basic" except perhaps not a proper subset of full)
>> iii) as a module, implementers of XForms full could decide whether
>> or not to implement, which has been important to some in the past.
>>
>> Assuming the latter approach is preferable, it so happens we still
>> need a name for the module, to distinguish it from the full spec.
>>
>> Note that we never really got off the ground with XForms 1.0 Basic
>> because, quite frankly, it is so close in functionality to XForms
>> full that it may as well be called a full implementation.  In fact,
>> in 1.1, the conformance section already allows the 1.0 Basic
>> limitations to be included in a "full" processor, so there is no
>> future for XForms 1.0 Basic.
>>
>> On the other hand, it has been proposed in this thread that this new
>> streamlined syntax might more reasonably be called "XForms Basic".
>> This has all the earmarks of what is typically known in our business
>> as ... a good point.  It beats the name "XForms 1.2 Transitional"
>> and it gets around the problem that the spec wants for both
>> attributes and script functions.
>>
>> So, the go-forward plan could be
>>
>> "XForms 1.2" as a very small rev of XForms 1.1
>>
>> "XForms 1.2 Basic" for the streamlined expression of data-rich web
>> applications
>>
>> John M. Boyer, Ph.D.
>> STSM, Interactive Documents and Web 2.0 Applications
>> 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
>> Blog RSS feed: http://www.ibm.
>> com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>>
>>
>>
>
>>
>> From:
>>
>> Charles F Wiecha <wiecha@us.ibm.com>
>>
>> To:
>>
>> "Mark Birbeck" <mark.birbeck@webbackplane.com>
>>
>> Cc:
>>
>> John Boyer/CanWest/IBM@IBMCA, public-forms@w3.org, public-forms-
>> request@w3.org, "Ulrich Nicolas Lissé" <unl@dreamlab.net>
>>
>> Date:
>>
>> 11/17/2008 07:34 AM
>>
>> Subject:
>>
>> Re: Straw poll on name of "streamlined syntax" spec
>>
>>
>>
>>
>>
>> So how about making this just XForms 1.2 and pushing the other 1.2
>> stuff into 1.3 or 2.0...Charlie
>>
>> Charles Wiecha
>> Manager, Multichannel Web Interaction
>> IBM T.J. Watson Research Center
>> P.O. Box 704
>> Yorktown Heights, N.Y. 10598
>> Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
>> wiecha@us.ibm.com
>>
>>
>> [image removed] "Mark Birbeck" ---11/17/2008 10:03:48 AM---Hi Uli, >
>> I prefer XFormsA and oppose to FormsA
>>
>> [image removed]
>> From:
>>
>> [image removed]
>> "Mark Birbeck" <mark.birbeck@webbackplane.com>
>>
>> [image removed]
>> To:
>>
>> [image removed]
>> "Ulrich Nicolas Lissé" <unl@dreamlab.net>
>>
>> [image removed]
>> Cc:
>>
>> [image removed]
>> "John Boyer" <boyerj@ca.ibm.com>, public-forms@w3.org
>>
>> [image removed]
>> Date:
>>
>> [image removed]
>> 11/17/2008 10:03 AM
>>
>> [image removed]
>> Subject:
>>
>> [image removed]
>> Re: Straw poll on name of "streamlined syntax" spec
>>
>> [image removed]
>> Sent by:
>>
>> [image removed]
>> public-forms-request@w3.org
>>
>>
>>
>>
>>
>>
>> Hi Uli,
>>
>> > I prefer XFormsA and oppose to FormsA
>> >
>> > Even more I'd prefer something like XForms Basic, but that's already in
>> > use for a profile. I find the uppercase "A" a bit awkward, but a
>> > lowercase "a" is even more awkward, and "-a" is expected to perform
>> > badly in terms of Google searches. Maybe XForms Compact could do the
>> > trick.
>>
>> I agree with you 110%. :)
>>
>> When we first started talking about this, I always saw the project as
>> more of an "XForms-lite", or "XForms Tiny" type thing. Those kinds of
>> names -- and your "XForms Compact" -- convey the sense of the spec
>> being an easy on-ramp, at the same time that it is part of the big,
>> happy, XForms, family.
>>
>> If I had to pick a preference, I'd probably go for XForms-lite.
>>
>> But I would also flag up the fact that we don't necessarily need a new
>> name at all.
>>
>> This is because most web developers have not even heard of XForms. So
>> creating a new document that describes a set of 'on-ramp' features,
>> does not necessarily require us to come up with a new name for this
>> spec. In fact, this new spec could just be an XForms Primer, or some
>> such, that prioritises the on-ramp features in the interests of
>> gaining wider interest in XForms amongst web developers and the Ajax
>> community.
>>
>> Regards,
>>
>> Mark
>>
>> --
>> Mark Birbeck, webBackplane
>>
>> mark.birbeck@webBackplane.com
>>
>> http://webBackplane.com/mark-birbeck
>>
>> webBackplane is a trading name of Backplane Ltd. (company number
>> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
>> London, EC2A 4RR)
>>
>>
>>
>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content, and is believed to be clean.
>> --
>
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
> --
> This message has been scanned for viruses and
> dangerous content, and is believed to be clean.
> --
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 18 November 2008 12:12:31 UTC