Re: XForms, the xf:header and the HTTP Accept header.

Hey Leigh,

Comments inline.

Klotz, Leigh wrote:
> Thank you Aaron.  If this list is too difficult we can move back to
> dev-tech-xforms.
> 
> 1. Did you see Philip Fennel's proposal for 
> 
>     <xf:header>
>         <xf:name>Accept</xf:name>
>         <xf:value>application/sparql-results+xml;q=0.95</xf:value>
>         <xf:value value="default()/>
>         <xf:value>application/atom+xml;q=0.6</xf:value>
>     </xf:header>
> 
> in the previous message on this topic?
> 
> My sense, as I said to Philip, is that this would be too hard to
> implement, but I don't want to second guess you (at least not without
> asking).

This would be awkward to implement.  I assume that the default() xpath 
function would have no meaning outside of a submission so we'd have to 
do special processing to ensure that the default method is contained 
inside a header element.  We'd also have to execute it in the context of 
the xf:name inside the xf:header so that we know what to get the default 
value of and as you suggested, the xf:name could appear below the 
xf:value inside xf:header.  You could, of course, make default() take a 
parameter so that we know what header name to get the default for but 
then it'd be easy for a developer to screw themselves up if they copy 
code and forget to change the parameter getting passed to default(). 
Plus keeping track of the default values for every header name in every 
protocol efficiently would be tough.  Either we'd have to store off all 
of them or we'd have to look ahead and resolve all of the header names 
prior to processing the xf:submission element which would be some ugly code.

I guess the short of it is that it would be POSSIBLE to implement that 
way, but it wouldn't be pleasant.

> 
> 2. Other replies inline below.
> 
>> -----Original Message-----
>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
> Behalf Of Aaron Reed
>> Sent: Tuesday, September 02, 2008 10:11 AM
>> To: www-forms@w3.org
>> Subject: Re: XForms, the xf:header and the HTTP Accept header.
>>
>>
>> I've been trying to reply all week but it keeps asking me to 'ok' the
> archival of my message even after I said 'ok'.  Here's trying again.
>>  > I'm leaning towards combine="prepend|append|replace|error" and then
> we
>>  > need to decide what the default is.
>>
>> What would 'error' do?  I think that the default should be 'append',
> though not a strong opinion.
> 
> Error would act like bind does now: if there is more than one value
> specified for a particular header, it would get an error.  Or maybe an
> exception.  The theory being that you only want to set
> "X-foo-obfuscator" property once, and if someone else tries to set it,
> you want the form to be in error.
> 

So that would be enforced only on the header element with 
combine="error" since that is an attribute on a single xf:header 
element?  So this:
<xf:header combine="prepend">
   <xf:name>Accept</xf:name>
   <xf:value>application/sparql-results+xml;q=0.95</xf:value>
   <xf:value>application/atom+xml;q=0.6</xf:value>
</xf:header>

would throw an error since it has two values?

What if I have a xf:header with combine="error" and containing a 
xf:name="foo" and later in that same xf:submission I have a xf:header 
with combine="append" and name="foo".  Would that throw an error?

> 
>>  > Keith's test cases show only one name, but multiple values.  I
> don't
>>  > see a reason to disallow multiple value elements, since it's
> already
>>  > allowed anyway. So (3) third axis would be value element document
>>  > order in the XForms document.
>>
> 
>> Multiple value element children aren't allowed under a header element
>> according to the schema.  I don't really care if you eventually allow
>> it as long as the schema is corrected.  It shouldn't affect the
>> implementation much.  Since we are allowing multiple header elements
>> anyhow, I don't see it is that much more work for the developer if
>> the spec continues with enforcing name/value pairs.  Either way is
>> fine with me.
> 
> It came from Keith Wells's test case.  It means you don't have to worry
> about commas or whatever quoting mechanism is used in order to specify
> multiple values for a header, as in this example:
> 
>     <xf:header combine="prepend">
>         <xf:name>Accept</xf:name>
>         <xf:value>application/sparql-results+xml;q=0.95</xf:value>
>         <xf:value>application/atom+xml;q=0.6</xf:value>
>     </xf:header>
> 

If this is valid, then the schema needs to be updated.  It would be nice 
if a note were made in the header element section, too, specifically 
mentioning this possibility.  When I think of name/value, I think pairs. 
  I don't think one of one and many of the other.

>>  > 2. Browser vendors may have headers that they wish to control
>>  > themselves, ones not defined in the HTTP protocol.  For example,
> Opera
>>  > Mini reportedly uses X-OperaMini-Features, and I can imagine that
> not
>>  > being settable.  Whether this is an error or a field to be silently
>>  > ignored, I don't know; what's your opinion and that of other
>>  > implementors?
>>
>> Ideally I'd say that it should be reported to the form author, though
> not necessarily as an exception, perhaps an xforms-????-error and if the
> implementation allows for it, an error output in a console.  I can't
> picture an implementation header that a form author would expect to be
> able to change and want to halt submission if setting that header
> failed.
> 
> It would likely be xforms-submit-error or xforms-serialiation-error, but
> if you think it would be better to have the browser ignore requests
> (silently or verbosely) then I'll report that.

I don't have a strong feeling on this one.  But it'd be nice if we could 
drive it with a use case (which would then become a testcase in the 
testsuite).  I'd rather it not halt submission unless we can come up 
with a scenario where that would be a desired outcome.

> 
> Leigh.
> 
>

Received on Wednesday, 3 September 2008 17:40:54 UTC