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

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 by MailScanner, and is
believed to be clean.
--