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 Thursday, 31 July 2008 17:42:11 UTC