W3C home > Mailing lists > Public > public-forms@w3.org > February 2009

Re: 1.1 spec correction for unspecified submission method

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Sat, 21 Feb 2009 12:20:42 +0000
Message-ID: <ed77aa9f0902210420q78142b0bt5dfc0ba412be5ecc@mail.gmail.com>
To: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
Cc: John Boyer <boyerj@ca.ibm.com>, Erik Bruchez <ebruchez@orbeon.com>, Forms WG <public-forms@w3.org>
Hello all,

In the context of Leigh's point about using events to signal markup
errors, I totally agree. I've been pushing for an approach where we
*reduce* the number of potential markup failures, by coming up with
logical interpretations of 'missing' markup, and I think we should be
making that approach central.

For example, we used to say that an xf:submit element without a
@submission was an error, now we say that it defaults to the first
xf:submission in the current model. Simple, and far more useful than
the error, because it makes simple forms _really_ simple.

Similarly, if we are going to ensure that XForms 'full' and XForms for
HTML are running in parallel, then we need to ensure that this has a
coherent explanation:

  <form action="">
    ...
  </form>

An easy way to do that is to ensure that xf:submission has the right
default values, such as @method="get".

I realise of course that this is not all work for XForms 1.1, and will
be the job of future specs; but I did want to flag up that we should
aim to reduce the number of errors that a form can generate, by
finding meaningful behaviours.

(My favourite example is tying an xf:range to a non-integer, non-date,
node in the instance; I believe that it remains the case that this
will throw an error, yet it seems a completely pointless error to
throw, especially for new authors.)

Regards,

Mark

On Sat, Feb 21, 2009 at 12:47 AM, Klotz, Leigh <Leigh.Klotz@xerox.com> wrote:
> I have no objection to
> 2) Fix the problem by making method="get" the default, which also aligns
> with the web and doesn't introduce another error-type
> HTML 4.01 says method is required; XHTML 1.0 says it defaults to "get" so
> that would be the better solution.
>
> However, I definitely object to our current practice (and saying that we
> just did it isn't good enough) of adding new error types to signal markup
> errors.
> The schema and the prose specify the lexical representation, and if it a
> processor determines it doesn't match the schema, it should not process the
> document.  Otherwise we're re-inventing document validation with DOM events.
>
> ________________________________
> From: John Boyer [mailto:boyerj@ca.ibm.com]
> Sent: Friday, February 20, 2009 4:38 PM
> To: Klotz, Leigh
> Cc: Erik Bruchez; Forms WG
> Subject: RE: 1.1 spec correction for unspecified submission method
>
>
> No we don't, though that's a little like asking "why make something better
> if it still won't be perfect?"
>
> It's also not really the same issue.  If you find a schema violation like
> the one you're showing, the usual web behavior of ignoring the
> non-understandable content is what happens most of the time, and the spec
> doesn't say much on the point.
> This situation is different because the spec does say something definitive
> because we're talking about a known attribute/element pair and how it is
> processed by a defined processing model.  Except we didn't say exactly what
> to do in the error scenario.
>
> If you look at step 5 of submit processing, we say to get the method.
> If you look at step 6 of submit processing, we say to get the resource.  In
> diffs since CR, the WG decided to fix the problem of not specifying a
> resource by specifically providing an xforms-submit-error with error-type of
> resource-error.
>
> See the diff mark in this section:
> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#submit-evt-submit
>
> Now we have exactly the same situation in step 5 as we fixed in step 6.
>
> This is the context in which I meant that we have three solutions:
>
> 1) Ignore the problem because there are other schema violations we don't
> cover and we'll never be perfect
> 2) Fix the problem by making method="get" the default, which also aligns
> with the web and doesn't introduce another error-type
> 3) Fix the problem by making an xforms-submit-error with an error-type.
>
> #1 and #3 have about the same amount of merit in this case.  #2 seems better
> to me.
>
> The addition of the error for absence of resource was very useful because an
> author can now use a resource-less submission to test validity of data.  If
> the error-type is validation-error, then data is invalid.  If the error-type
> is resource-error, then the data is valid.
>
> But for method, there is no utility in the error, so #1 and #3 get about the
> same mileage.  But #2 simplifies authoring, aligns to current web default,
> and makes one less place in the spec where we tell implementers that authors
> are required to do something but then don't say how to deal with the error
> case.
>
> 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: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
> To: John Boyer/CanWest/IBM@IBMCA
> Cc: "Erik Bruchez" <ebruchez@orbeon.com>, "Forms WG" <public-forms@w3.org>
> Date: 02/20/2009 03:54 PM
> Subject: RE: 1.1 spec correction for unspecified submission method
> ________________________________
>
>
> What do we tell processors to do in this situation:
>
> <xf:model>
>   <xf:fnord />
> </xf:model >
>
> ?
>
>
> ________________________________
> From: John Boyer [mailto:boyerj@ca.ibm.com]
> Sent: Friday, February 20, 2009 3:40 PM
> To: Klotz, Leigh
> Cc: Erik Bruchez; Forms WG
> Subject: RE: 1.1 spec correction for unspecified submission method
>
>
> That *is* what we say now, in prose.  The problem is that we then don't say
> what happens when the requirement is not met.  It's a requirement on authors
> not on implementers, so we either have to tell implementers what to do when
> authors don't meet the requirement or the implementations will not all
> behave the same authors don't meet the requirement.
>
> Cheers,
> 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: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
> To: John Boyer/CanWest/IBM@IBMCA
> Cc: "Erik Bruchez" <ebruchez@orbeon.com>, "Forms WG" <public-forms@w3.org>
> Date: 02/20/2009 03:35 PM
> Subject: RE: 1.1 spec correction for unspecified submission method
>
> ________________________________
>
>
> Ah, I checked the 1.0 schema; of course.  In Relax NG you can specify that
> one or the other must be required.
> I hear a later revision of XML Schemas allows co-occurrence constraints as
> well. Why not just say it in prose then?
> 4) A conforming document must have either a method attribute or a method
> element.
>
> ________________________________
> From: John Boyer [mailto:boyerj@ca.ibm.com]
> Sent: Friday, February 20, 2009 3:32 PM
> To: Klotz, Leigh
> Cc: Erik Bruchez; Forms WG
> Subject: RE: 1.1 spec correction for unspecified submission method
>
>
> Hi Leigh,
>
> The problem is that we already say, from the schema perspective, that the
> method attribute is optional.  This is because we also have a method element
> child of submission, which can computationally determine the method with the
> value attribute.
> Further, because the method attribute exists, the method element child is
> not required either, again from the schema perspective.
>
> So we have this situation where neither the attribute nor the element is
> required, but we claim that one is required, but we don't say what happens
> if you don't put one.  The options are
>
> 1) Make method="get" the default if neither the attribute nor the element is
> given.
> 2) Specify xforms-submit-error (which we did for the resource
> attribute/element pair; see the diff on step 7 of submit event processing)
> 3) Continue to not say anything and let implementations pick their own way
> of handling the problem (some will do #1, others #2, and others ...)
>
> Cheers,
> 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: "Klotz, Leigh" <Leigh.Klotz@xerox.com>
> To: John Boyer/CanWest/IBM@IBMCA, "Erik Bruchez" <ebruchez@orbeon.com>
> Cc: "Forms WG" <public-forms@w3.org>
> Date: 02/20/2009 03:19 PM
> Subject: RE: 1.1 spec correction for unspecified submission method
>
>
> ________________________________
>
>
> Or leave unspecified behavior and let the user agent handle it however else
> it handles Schema violations.
>
> <xsd:attribute name="method" use="required">
>
>
> ________________________________
> From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] On
> Behalf Of John Boyer
> Sent: Friday, February 20, 2009 2:40 PM
> To: Erik Bruchez
> Cc: Forms WG
> Subject: Re: 1.1 spec correction for unspecified submission method
>
>
> Hi Erik,
>
> Another more compelling possibility is to simply say that "get" is the
> default method.  This is simpler editorially, does not introduce a further
> error-type, and aligns with the default currently used on the web.  Does
> that sound good?
>
> Cheers,
> 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: Erik Bruchez <ebruchez@orbeon.com>
> To: Forms WG <public-forms@w3.org>
> Date: 02/18/2009 04:17 PM
> Subject: Re: 1.1 spec correction for unspecified submission method
>
>
>
> ________________________________
>
>
> That sounds reasonable except that it is a little annoying to have to
> add a new "method-error" error type, since this type does not exist yet.
>
> -Erik
>
> On Feb 18, 2009, at 1:54 PM, John Boyer wrote:
>
>>
>> At some time since CR, it was noticed that we did not say what a
>> submission would do if the resource URI was not specified, and we
>> have corrected the 1.1 spec to say that you get an xforms-submit-
>> error with error-type of resource-error
>>
>> I was doing a code review on Ubiquity XForms implementation of the
>> method element, and noticed that the 1.1 spec has the same problem
>> for the method.  The spec says that one of the method attribute or
>> method element must be specified, but it does not say what happens
>> if the author violates the requirement.  It looks like a simple
>> omission error, i.e. clearly you should ge tan xforms-submit-error
>> with an error-type of method-error.
>>
>> 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
>>
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
>
>
>
>
>
>



-- 
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 Saturday, 21 February 2009 12:21:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:50 UTC