Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

[Philip F. <Phi...@ma...>]

Alain,

> xf:header is actually implemented in Beta 3 already.

Really, wow, I'll have to try that out, thanks!


Regards

Philip

-----Original Message-----
From: Alain Couthures [mailto:ala...@ag...] 
Sent: Friday, July 22, 2011 2:24 PM
To: Conal Christopher Tuohy
Cc: Philip Fennell; xsl...@li...
Subject: Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types

Hi Conal,

xf:header is actually implemented in Beta 3 already. So you better give 
it a try!

Thank you for your feedbacks!

-Alain

Le 22/07/2011 15:07, Conal Christopher Tuohy a écrit :
> Hi Philip
>
> It would be nice if XSLTForms had a complete implementation of XForms 1.1, and if I could use the xf:header feature it would solve my problem, but I think for a 1.0 implementation it does still make sense not to accept a content-type of "text/html" or "*/*" or in general anything other than XML. Unless XSLTForms provides an explicit Accept header when loading an instance, it may accidentally pass on the browser's default Accept header, and for resources which support content negotiation, that not ideal.
>
> On the theoretical point; I think it's an interesting point, but personally do tend to think that an XForm editor for a resource is a perfectly good "representation" of that resource. I don't really see that it's relevant whether the XHTML+XForms document includes an editable XML instance by inclusion or by URI reference. I see it as analogous to a situation where you might get a representation of an image using an Accept header of "image/*" and retrieve e.g. a PNG file, or get a representation with Accept: text/html and retrieve a web page containing a reference to that same PNG representation. I agree that from a theoretical point of view the HTML XForm should not be seen as an HTML representation of an "XML resource". In the web architecture the "resource" itself is something abstract (it's information about a person or information, in this case), and the XML instance is just a representation of that resource. The XForm is also a representation of that same abstract information resource: it's a two-tiered representation in that it transcludes another representation (a RIF-CS XML record), but that pattern is not unusual on the web, actually.
>
> I'm keen to continue discussing the web-architecture aspect of this, though ... I wonder if the new xforms-users list is a more appropriate form, since it's not really specific to XSLTForms.
>
> Regards
>
> Con
>
> ________________________________________
> From: Philip Fennell [Phi...@ma...]
> Sent: Friday, 22 July 2011 7:12 PM
> To: Conal Christopher Tuohy; xsl...@li...
> Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types
>
> Conal,
>
> Firstly, to my knowledge, the xf:submission element's xf:header element is not currently supported by XSLTForms. This would be the way to specify the Accept header for your requests, but, more importantly, there is a refinement to the use of the xf:header element that affects how they are set by the client. The 'combine' attribute is created to deal with the situation where you want to either add or override the existing header sent by the client. In your case, you would have to use combine="replace" to ensure only the requested content-type is sent. The other options are 'append' and 'prepend' so that you can define how your value is added to an existing header.
>
> Secondly, and I know this might sound a bit nit-picky but, from the way I tend to look at things, I would regard an XForm application and the instance data it loads as two separate resources. The XForm is not an HTML representation of the XML instance data resource it loads. Also, for XSLTForms, the response has to be application/xml in order that the browser will act upon the xml-stylesheet processing instruction. Now, the server is not bound to honour the request's Accept header, it can give either the best it can or say 'Not Acceptable' so just because it asks for HTML doesn't mean it will receive it.
>
> A document, transformed into an HTML Form, that contains the data from the document might be regarded as a text/html representation of that data, but I'm not convinced that you can argue the same for an XForm document that references the document.
>
> I think there is potential ambiguity in the design that you are using which could lead people to say that it is not truly RESTful.
>
> Some people suggest using a type attribute on the Accept header value to extend its meaning. For example, an Atom Feed has a content type of application/atom+xml where as a single Atom Entry is application/atom+xml;type=entry
>
> Maybe, you could use a content type of application/xml;type=edit. This might be a more flexible solution as it would still give you the possibility of requesting an HTML representation that wasn't editable.
>
> I'd be interested in your thoughts on this as it is potentially a common problem with developing for XForms.
>
>
> Regards
>
> Philip
>