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

Thanks for the detailed respons and good questions, Aaron.
Here are some replies:

>From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Aaron Reed
>Sent: Tuesday, August 26, 2008 2:49 PM
>To: www-forms@w3.org
>Subject: Re: XForms, the xf:header and the HTTP Accept header.
>
>
>Hey Leigh,
>
>I think that we can make 'prepend' work, but I haven't tried it to be
sure.

If you can't make prepend work, then it won't be possible for a form
to specify a Accept or Accept-Lang value that takes higher precedence
but doesn't replace the existing values.

>I assume that the call to get the request header in Mozilla will have
the defaults filled in already when we need them.

>I have no problem with 'append' and 'replace' as being the other
>possible attribute values if you go with @combine.  I would prefer
>that @replace not be used since it is already used in submission and
>might cause confusion.  But that is just my own personal preference.
>I personally have no problem with calling it @append (t/f as values),
>@combine (prepend/append/replace as values) or even @merge (t/f as
>values).

I'm leaning towards combine="prepend|append|replace|error" and then we
need to decide what the default is.
See the "decide" issue below though.

>Clarifications.  In your blog post, you have "Define header ordering
>as" and then some info.  You say xf:header/@ref, but I assume that
>you mean xf:header/@nodeset? Or at least you meant the individual
>results returned from the evaluation of the nodeset.

Yes, I meant nodeset.  Note that nodeset="x[y=z]" has a well-defined
order that is preserved from the instance document, but nodeset="a|b"
doesn't preserve document order from the instance (at least in XPath
1.0; dunno about XPath 2.0).  There's not an easy way to refer back to
instance order anyway, and what if there are two instances?  So, it's
OK for us to say the define that that the primary axis for header
order is (1) order of xf:header and (2) secondary is
xf:header/@nodeset order.  After that, see next paragraph.

>You also say, "Docuement Order of value elements within each
>f:header" but unless I'm reading the schema wrong, it seems only
>be one name element and one value element can appear as children of
>a xf:header, right?

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.

The value element has a value attribute, which is converted by XPath
string, so that means if it's a nodeset it's a space-separated list of
values.  That seems to me to be wrong.  So we need to make it either
be single-valued or say that we have a (4) axis of multiple values of
the value element?  

If everyone else thinks we should disallow multiple value elements and
treat nodesets in value as strings, we can, but it puts the author in
the business of doing concat and quoting.  It may be that we need
value/@nodeset, though there is no binding implied.

>You also mention that the WG needs to "decide whether this behavior
>controls only the pre-existing header values, or whether it also
>applies to multiple value garnered during form processing."  Very
>important for the WG to spell this out.  Definitely an area where
>different processors could interpret the behavior differently.

>You also mention, "If header values or names cannot be serialized
>(perhaps due to unquotable characters in the value or inexpressible
>names in the key), then serialization will get an exception".  If
>this gets spec'd, please make sure that a testcase or two is created
>for this piece.  I'm no huge HTTP request expert so I'd like to know
>at least a couple of use cases that SHOULD fail so that if they don't
>for us I can figure out why.  Otherwise we may never send the
>exception :-) But we definitely need something new.  Wouldn't be
>consistent to include it under xforms-submit-error since all of the
>current xforms-submit-errors occur after the the request was built
>and sent to a URL.

Definitely we need to decide what to do here, if only in a note.
Here are some possibilities:

1. Security concerns might prohibit setting fields such as
"Authorization" or "Connection" or "Cookie" though one might argue
that it's OK.  I suspect different browser vendors will have a
different take on this and other security issues.

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?

3. Header names in HTTP 1.1 are governed by RFC2616 in this production:

    token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

So header names apparent't can't contain colon, for example.  Probably
the HTTP serializer would consider this an error and you'd get the
xforms-submit-error as you say above.  Maybe if IBM implements
submission/@method="MQSeries" this won't be a problem, so I don't
think the checking belongs in the xf:header element, but in HTTP
serialization, and since we don't define HTTP serialization ourselves,
it ought to be a note and a testcase, as you say.

4. Header names in HTTP 1.1 are governed by RFC2616 in this same
production as well, but have additional stuff: comments, quoted
strings, backslash, etc.  I would hope that a well-written HTTP
serializer would handle these issues itself, and not require the users
of its API to read and implement RFC2616 section 2.2, but in any case,
it seems possible that there are error conditions involving illegal
value strings and we must at least Note in the document that a
serializer (and in particular HTTP 1.1) might reject some values.
It'd be great if someone who knew more about that would pipe up.

Leigh.


>
>Those are my thoughts at least.  Philip will have to let us know if
they satisfy his anticipated use cases.
>--Aaron
>
>Klotz, Leigh wrote:
>> Aaron and Philip,
>> 
>> As I described in my comment on Philip's O'Reilly blog posting [1], 
>> we've decided to take the potential schedule hit on this to re-design

>> xf:header.  Please take a look at the proposal there and see what you

>> think.  Of course, we welcome discussion from others as well.
>> 
>> Aaron, I'm concerned that append="true|false" may not be enough.  Do 
>> you think we need a prepend as well?  In that case, perhaps 
>> combine="replace|append|prepend" would be needed.  Do we also need 
>> "error" with that being the default?
>> 
>> [1]
>>
http://news.oreilly.com/2008/08/xforms-and-restful-web-service.html#co
>> mm
>> ent-2021003
>> 
>> Thanks,
>> Leigh.
>> 
>> 
>> -----Original Message-----
>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On 
>> Behalf Of Aaron Reed
>> Sent: Thursday, July 31, 2008 10:11 AM
>> To: www-forms@w3.org
>> Subject: Re: XForms, the xf:header and the HTTP Accept header.
>> 
>> 
>> Hi Philip,
>> 
>> That is exactly what I was thinking, but you are missing one of my 
>> points, I believe.  You seem to be thinking that there would be no 
>> desire ever to use xf:header for an accept header with replace="all".
>> That is a pretty limiting assumption.  And if the form author did
want 
>> to do this and your suggestions were in place, then you'd be
requiring 
>> that form author to mimic his browser's default accept header and
then 
>> add his own changes on top of that.  Which seems to be quite a lot of

>> trouble and likely difficult to do.  But you could have <xf:header 
>> @append="true">...</xf:header> and then the author doesn't have to 
>> jump through hoops to do what he wants to do.  And there also
wouldn't 
>> have to be a special case in the processor code to look explicitly
for 
>> accept header changes and treat them as always replaceable.
>> 
>> --Aaron
>> 
>> Philip Fennell wrote:
>>> Aaron,
>>>
>>>> With your suggestion of allowing only the default accept header (no

>>>> xf:headers in the xforms document) or xforms author supplied accept

>>>> header (using xf:headers in the xforms
>>>> document) then you would be requiring the xforms author to 
>>>> completely
>> 
>>>> anticipate other extensions that the browser has installed or the 
>>>> user might lose out.
>>> It took me a couple of times re-reading my previous e-mail to 
>>> understand what I think you think I meant, and I believe I
understand 
>>> where I went wrong.
>>>
>>> I shouldn't have implied that when the developer sets replace="all" 
>>> that they then set the Accept header to what they believe Firefox 
>>> normally uses. What I should have said was that in the replace="all"
>>> case, the developer would not set the Accept header through
xf:header 
>>> which would allow the associated submission to revert to the
'current'
>> 
>>> Accept header (accommodating all current extensions) for a request 
>>> that will load a new document.
>>>
>>> With that correction to my suggestion in mind, does the use of 
>>> replace="instance" and replace="all" respectively allow the
developer 
>>> to express their intent for XForms and browser related requests and 
>>> therefore make the overriding of the accept header a desirable 
>>> behaviour?
>>>
>>>
>>>
>>> Regards
>>>
>>> Philip Fennell
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On 
>>> Behalf Of Aaron Reed
>>> Sent: 30 July 2008 22:51
>>> To: www-forms@w3.org
>>> Subject: Re: XForms, the xf:header and the HTTP Accept header.
>>>
>>>
>>> Hi Philip,
>>>
>>> If you are running the xforms processor on a browser that has other 
>>> extensions (who may also modify the default accept header) that
would 
>>> handle the data coming back at least as well if not possibly better 
>>> than the xforms processor, then the server should be able to serve 
>>> the
>> 
>>> data back in the more acceptable format.  With your suggestion of 
>>> allowing only the default accept header (no xf:headers in the xforms
>>> document) or xforms author supplied accept header (using xf:headers 
>>> in
>> 
>>> the xforms
>>> document) then you would be requiring the xforms author to
completely 
>>> anticipate other extensions that the browser has installed or the 
>>> user
>> 
>>> might lose out.  While this might be ok for some browsers/processors

>>> on some platforms due to the limited number of available options, if

>>> the user wants his xform to run well on all platforms and browsers, 
>>> that is asking for a lot of anticipation from the form author.
>>>
>>> --Aaron
>>>
>>> Philip Fennell wrote:
>>>> Aaron,
>>>>
>>>>> we must keep in mind that the accept header by default is what the

>>>>> browser will accept back which is certainly a far greater variety 
>>>>> than the xforms plugin can accept.  And in most case, I'd argue, 
>>>>> the
>> 
>>>>> xforms processor has no idea what the user is trying to do so to 
>>>>> automatically limit the user seems the wrong way to
>>>> go.
>>>>
>>>> Where a submission uses replace="instance", then the developer's 
>>>> intent is that the response is for the XForms processor. Where 
>>>> replace="all" is used, the intent is that the response is being 
>>>> handed back to the parent browser and therefore it should be the 
>>>> developer's
>> 
>>>> responsibility to set the Accept header accordingly in these
>> contexts.
>>>> With that in mind, I'd argue that overwriting the accept header 
>>>> should be the preferred behaviour as it is possible for the 
>>>> developer to express their intent through the setting of the 
>>>> submission element's
>>> replace attribute.
>>>> Regards
>>>>
>>>> Philip Fennell
>>>>> XSLT Developer (Content Management Culture)
>>>>>
>>>>> BBC Future Media & Technology
>>>>> Media Village, 201 Wood Lane London W12 7TP
>>>>> BC4 C4, Broadcast Centre
>>>>>
>>>>> T:	0208 0085318
>>>>>
>>>> -----Original Message-----
>>>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On

>>>> Behalf Of Aaron Reed
>>>> Sent: 29 July 2008 19:13
>>>> To: www-forms@w3.org
>>>> Subject: Re: XForms, the xf:header and the HTTP Accept header.
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Just a FYI to the WG, Mozilla will 'replace' the value of a request

>>>> header with the value specified in the xf:header if that particular

>>>> header is only capable of containing one value (for example, the 
>>>> content type header) but will 'append' the value if the header is 
>>>> capable of containing more than one value.
>>>>
>>>> With regards to Philip's argument that the Accept header should
only 
>>>> contain a single media type and that 'Multiple media types suggest 
>>>> that the XForm can accept multiple representations', we must keep
in 
>>>> mind that the accept header by default is what the browser will 
>>>> accept back which is certainly a far greater variety than the
xforms 
>>>> plugin can accept.  And in most case, I'd argue, the xforms 
>>>> processor has no
>> 
>>>> idea what the user is trying to do so to automatically limit the 
>>>> user
>> 
>>>> seems the wrong way to go.  Now, in cases where the instance is 
>>>> being
>> 
>>>> replaced Philip probably has a point.  But in generic post or get 
>>>> submission scenarios it could be that the user might be trying to 
>>>> get
>> 
>>>> out of xforms completely if there is a more appropriate type 
>>>> available but is willing to take xforms in a pinch.
>>>>
>>>> So unless the user has a way to specify his intent (the way he'd do

>>>> that would be up to this WG), I'd leave it up to the server to
serve 
>>>> down the appropriate format given the information available to it.
>>>>
>>>> --Aaron
>>>>
>>>> Philip Fennell wrote:
>>>>> The Mozilla XForms plug-in now, via nightly builds, has support
for 
>>>>> the xf:header element and its associated attributes and child 
>>>>> elements. With respect to the HTTP Accept header, the Mozilla 
>>>>> implementation appends the value in the XForm to the request
header 
>>>>> whilst, for example, the FormsPlayer implementation overwrites the
>>>> existing header.
>>>>> After discussion with Aaron Reed on the dev-tech-xforms mailing 
>>>>> list
>> 
>>>>> he suggests that:
>>>>>
>>>>>> Sounds like you have a usecase for the XForms working group to
>>>>> consider. 
>>>>>> Maybe they could put an attribute on the xf:header that says to
>>>>> replace rather than append.
>>>>>
>>>>> For my two-penneth worth, after thinking about this for a bit, due

>>>>> to the nature of an XForms request and the fact that any data 
>>>>> bindings will only be valid for a single representation of the 
>>>>> requested resource, the Accept header should be overridden and 
>>>>> therefore only have a single media type. Multiple media types 
>>>>> suggest that the XForm can accept multiple representations which
is 
>>>>> of course highly
>> unlike.
>>>>> How you decide which headers are overridden and which get appended

>>>>> is an interesting question.
>>>>>
>>>>> Does anyone on this list have an opinion about this?
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Philip Fennell
>>>>>
>>>>> http://www.bbc.co.uk/
>>>>> This e-mail (and any attachments) is confidential and may contain
>>>> personal views which are not the views of the BBC unless 
>>>> specifically
>> 
>>>> stated.
>>>>> If you have received it in error, please delete it from your
system.
>>>>> Do not use, copy or disclose the information in any way nor act in
>>>> reliance on it and notify the sender immediately.
>>>>> Please note that the BBC monitors e-mails sent or received.
>>>>> Further communication will signify your consent to this.
>>>>> 					
>>>>>
>>>>>
>>>>
>>>>
>>>> http://www.bbc.co.uk/
>>>> This e-mail (and any attachments) is confidential and may contain
>>> personal views which are not the views of the BBC unless
specifically 
>>> stated.
>>>> If you have received it in error, please delete it from your
system.
>>>> Do not use, copy or disclose the information in any way nor act in
>>> reliance on it and notify the sender immediately.
>>>> Please note that the BBC monitors e-mails sent or received.
>>>> Further communication will signify your consent to this.
>>>> 					
>>>>
>>>>
>>>
>>>
>>>
>>> http://www.bbc.co.uk/
>>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically

>> stated.
>>> If you have received it in error, please delete it from your system.
>>> Do not use, copy or disclose the information in any way nor act in
>> reliance on it and notify the sender immediately.
>>> Please note that the BBC monitors e-mails sent or received.
>>> Further communication will signify your consent to this.
>>> 					
>>>
>>>
>> 
>> 
>> 
>> 
>> 
>
>
>

Received on Wednesday, 27 August 2008 19:41:30 UTC