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

Hi Mark,

Personally I’m a bit struggling with this twofold strategy the strategy of 
making XForms easier and better readable is one that I think is really 
important. Being able to mix HTML Forms with XForms and nicely integrating 
the two, i.e. being able to incrementally add XForms concepts to an HTML 
Forms document is also a nice thing to have. But I don’t know if we need 
to import all attributes and elements from HTML Forns to XForms to 
accomplish this. I even think that this is a ‘dangerous’ strategy because 
I think if we follow this strategy we are doomed to be always one step 
behind. Because if we imported the elements and attributes from HTML forms 
to XForms an author can’t use XForms in his document that uses HTML forms 
+ LIBXYZ because LIBXYZ has a way to express read-only but doesn’t has 
calculates which he wants to use from XForms. It will be even worse if 
there is a really popular language form XYZ that also has form 
capabilities but lacks some of the features we have in XForms. Should we 
then also import those elements and attributes in XForms? 

Personally I think it should be much nicer if we have a specification 
(like the one that John has written) that says how you could map all the 
form related concepts of a specific language to XForms and allow the 
author to add ‘XForms Core’ constructs (elements, attributes) to the 
markup. If the rules are well defined I don’t see a problem here. Someone 
else can do the same for HTML Forms + Toolkit XYZ, yet another person can 
do it for language XYZ that has basic native support for forms but lacks 
some of our features.

I’m not sure if someone else is sharing these concerns, but as I see a 
‘the community’ that creates dozens of new form related features 
(controls, logic, …) and it would be a shame that they couldn’t benefit 
from our work if they would like to do it. If we show them how easy it is 
to map the concepts of HTML forms to XForms and if we manage to publish 
some XForms 1.2 modules. The community maybe sees the benefit of using one 
or more of our modules and then just defines how their concepts map onto 
the XForms ones and then they can integrate those modules into their 
Toolkit.
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

"Mark Birbeck" <mark.birbeck@webbackplane.com> wrote on 18/11/2008 
13:11:54:

> 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 
theauthors 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 bejust 
'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)
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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.
--