RE: 1.1 spec correction for unspecified submission method

I think John's preferred resolution is @method='get' default anyway, and
I'm of course fine with that.
I just don't want to, as you say, introduce any XML Events to be
signalled for markup authoring errors that can be statically analyzed,
and I agree with you that, if we are making changes, I'd prefer to see
any existing ones removed.  I'm not ready to make a blanket statement
that we should have a default for everything, but you do have a good
argument that that ought to be the first option examined in each case.

Leigh.

-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@webbackplane.com] 
Sent: Saturday, February 21, 2009 4:21 AM
To: Klotz, Leigh
Cc: John Boyer; Erik Bruchez; Forms WG
Subject: Re: 1.1 spec correction for unspecified submission method

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 Monday, 23 February 2009 17:13:59 UTC