Thread: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content typ
Brought to you by:
alain-couthures
From: Conal T. <con...@ve...> - 2011-07-22 06:07:53
|
I have been using XSLTForms recently, for editing XML metadata records. In our project, we have a RESTful web service (based on a Fedora repository) which uses HTTP Content Negotiation to publish different representations of a resource (i.e. using the same HTTP URL, but in response to different HTTP Accept headers). Each resource may be represented as an XML metadata record or as an XForm, depending on the content-type requested. If a browser sends a request for an HTML page, we want to return an XForm embedded in HTML, but if the browser doesn't want HTML, then we send the "raw" XML record. If the browser accepts HTML, then it receives an XForm, and the XForm itself then issues a request (to the same URL!) to retrieve the XML instance. The problem is that XSLTForms doesn't specify an HTTP Accept header, and the browser (Firefox 5 for example) sends its default Accept header, which includes "text/html", etc. Hence the instance document retrieved is not the "raw" XML representation, but rather an XForm (i.e. the XForm has loaded itself as a model instance!) I think it's a bug for XSLTForms to say that it accepts "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which is the default Accept header in Firefox). It seems sensible to me to set an Accept header listing "text/xml" and "application/xml", so that XSLTForms can be used with services such as ours, which use content negotiation. I found I could fix the problem by explicitly setting the Accept header in xsltforms.js, in two places (there is a case for Internet Explorer and a case for other browsers). See below: > if (window.XMLHttpRequest) { > Core.openRequest = function(method, uri, async) { > // > netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); > var req = new XMLHttpRequest(); > try { > req.open(method, Core.constructURI(uri), async); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This > browser does not support XHRs(Ajax)! \n Cause: " + (e.message || > e.description || e) + " \n Enable Javascript or ActiveX controls (on > IE) or lower security restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > } > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > if (Core.isMozilla) { > req.overrideMimeType("text/xml"); > } > return req; > }; > } else if (window.ActiveXObject) { > Core.openRequest = function(method, uri, async) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This browser does not > support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) + > " \n Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > return req; > }; > } else { > throw new Error("This browser does not support XHRs(Ajax)! \n > Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 |
From: Philip F. <Phi...@ma...> - 2011-07-22 09:12:19
|
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 -----Original Message----- From: Conal Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 7:08 AM To: xsl...@li... Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types I have been using XSLTForms recently, for editing XML metadata records. In our project, we have a RESTful web service (based on a Fedora repository) which uses HTTP Content Negotiation to publish different representations of a resource (i.e. using the same HTTP URL, but in response to different HTTP Accept headers). Each resource may be represented as an XML metadata record or as an XForm, depending on the content-type requested. If a browser sends a request for an HTML page, we want to return an XForm embedded in HTML, but if the browser doesn't want HTML, then we send the "raw" XML record. If the browser accepts HTML, then it receives an XForm, and the XForm itself then issues a request (to the same URL!) to retrieve the XML instance. The problem is that XSLTForms doesn't specify an HTTP Accept header, and the browser (Firefox 5 for example) sends its default Accept header, which includes "text/html", etc. Hence the instance document retrieved is not the "raw" XML representation, but rather an XForm (i.e. the XForm has loaded itself as a model instance!) I think it's a bug for XSLTForms to say that it accepts "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which is the default Accept header in Firefox). It seems sensible to me to set an Accept header listing "text/xml" and "application/xml", so that XSLTForms can be used with services such as ours, which use content negotiation. I found I could fix the problem by explicitly setting the Accept header in xsltforms.js, in two places (there is a case for Internet Explorer and a case for other browsers). See below: > if (window.XMLHttpRequest) { > Core.openRequest = function(method, uri, async) { > // > netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); > var req = new XMLHttpRequest(); > try { > req.open(method, Core.constructURI(uri), async); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This > browser does not support XHRs(Ajax)! \n Cause: " + (e.message || > e.description || e) + " \n Enable Javascript or ActiveX controls (on > IE) or lower security restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > } > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > if (Core.isMozilla) { > req.overrideMimeType("text/xml"); > } > return req; > }; > } else if (window.ActiveXObject) { > Core.openRequest = function(method, uri, async) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This browser does not > support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) + > " \n Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > return req; > }; > } else { > throw new Error("This browser does not support XHRs(Ajax)! \n > Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
From: Conal C. T. <con...@ve...> - 2011-07-22 13:08:13
|
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 -----Original Message----- From: Conal Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 7:08 AM To: xsl...@li... Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types I have been using XSLTForms recently, for editing XML metadata records. In our project, we have a RESTful web service (based on a Fedora repository) which uses HTTP Content Negotiation to publish different representations of a resource (i.e. using the same HTTP URL, but in response to different HTTP Accept headers). Each resource may be represented as an XML metadata record or as an XForm, depending on the content-type requested. If a browser sends a request for an HTML page, we want to return an XForm embedded in HTML, but if the browser doesn't want HTML, then we send the "raw" XML record. If the browser accepts HTML, then it receives an XForm, and the XForm itself then issues a request (to the same URL!) to retrieve the XML instance. The problem is that XSLTForms doesn't specify an HTTP Accept header, and the browser (Firefox 5 for example) sends its default Accept header, which includes "text/html", etc. Hence the instance document retrieved is not the "raw" XML representation, but rather an XForm (i.e. the XForm has loaded itself as a model instance!) I think it's a bug for XSLTForms to say that it accepts "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which is the default Accept header in Firefox). It seems sensible to me to set an Accept header listing "text/xml" and "application/xml", so that XSLTForms can be used with services such as ours, which use content negotiation. I found I could fix the problem by explicitly setting the Accept header in xsltforms.js, in two places (there is a case for Internet Explorer and a case for other browsers). See below: > if (window.XMLHttpRequest) { > Core.openRequest = function(method, uri, async) { > // > netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); > var req = new XMLHttpRequest(); > try { > req.open(method, Core.constructURI(uri), async); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This > browser does not support XHRs(Ajax)! \n Cause: " + (e.message || > e.description || e) + " \n Enable Javascript or ActiveX controls (on > IE) or lower security restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > } > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > if (Core.isMozilla) { > req.overrideMimeType("text/xml"); > } > return req; > }; > } else if (window.ActiveXObject) { > Core.openRequest = function(method, uri, async) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This browser does not > support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) + > " \n Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > return req; > }; > } else { > throw new Error("This browser does not support XHRs(Ajax)! \n > Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
From: Efraim F. <efr...@gm...> - 2011-07-22 13:31:53
|
Hi, On 07/22/2011 09:07 AM, Conal Christopher Tuohy wrote: > 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 Am I missing something? XSLTForms does support xf:header in trunk. There does seem to be a bug in the implementation, though. Where the same header already exists, the XForms spec says that the value should be appended to the end. XSLTForms instead prepends it. The combine attribute, which can have the values "prepend", "append", and "replace", does nothing. -- --- Efraim Feinstein Lead Developer Open Siddur Project http://opensiddur.net http://wiki.jewishliturgy.org |
From: Philip F. <Phi...@ma...> - 2011-07-22 13:54:40
|
Efraim, > The combine attribute, which can have the values "prepend", > "append", and "replace", does nothing. Ahh, may be that is what I remember as not working. Thanks for clarifying that. Regards Philip -----Original Message----- From: Efraim Feinstein [mailto:efr...@gm...] Sent: Friday, July 22, 2011 2:32 PM To: xsl...@li... Subject: Re: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types Hi, On 07/22/2011 09:07 AM, Conal Christopher Tuohy wrote: > 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 Am I missing something? XSLTForms does support xf:header in trunk. There does seem to be a bug in the implementation, though. Where the same header already exists, the XForms spec says that the value should be appended to the end. XSLTForms instead prepends it. The combine attribute, which can have the values "prepend", "append", and "replace", does nothing. -- --- Efraim Feinstein Lead Developer Open Siddur Project http://opensiddur.net http://wiki.jewishliturgy.org ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
From: Alain C. <ala...@ag...> - 2011-07-22 13:33:22
|
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 > |
From: Philip F. <Phi...@ma...> - 2011-07-22 13:21:32
|
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 > |
From: Conal C. T. <con...@ve...> - 2011-07-22 14:12:42
|
Thanks Alain - that's great! But xf:header is only applicable to xf:submission isn't it? i.e. I can't control the headers of a xf:instance? Though I suppose I could start with an empty xf:instance, and use an xf:submission (with an Accept xf:header) to initialise the instance when the form loads. Con ________________________________________ From: Alain Couthures [ala...@ag...] Sent: Friday, 22 July 2011 11:23 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 > |
From: Philip F. <Phi...@ma...> - 2011-07-22 14:01:23
|
Conal, > Though I suppose I could start with an empty xf:instance, and use > an xf:submission (with an Accept xf:header) to initialise the > instance when the form loads. Yes, that's how I tend to do it from the xforms-ready event. <xf:model> <xf:action ev:event="xforms-ready"> <xf:send submission="submission-id"/> </xf:action> ... </xf:model> Regards Philip -----Original Message----- From: Conal Christopher Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 2:56 PM To: Alain Couthures Cc: Philip Fennell; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types Thanks Alain - that's great! But xf:header is only applicable to xf:submission isn't it? i.e. I can't control the headers of a xf:instance? Though I suppose I could start with an empty xf:instance, and use an xf:submission (with an Accept xf:header) to initialise the instance when the form loads. Con ________________________________________ From: Alain Couthures [ala...@ag...] Sent: Friday, 22 July 2011 11:23 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 > |
From: Philip F. <Phi...@ma...> - 2011-07-22 15:43:52
|
Conal, > I wonder if the new xforms-users list is a more appropriate form Can you be more specific about the xforms-users list. I've done a quick search but found nothing matching that name. > 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. Taken in isolation, I can also see that, as part of the transformation that generates a resource's representation, it is a moot point as to whether the resource is included in-line in an XForm or, by reference, out-of-line. I will post a question to the www...@w3... e-mail list to start a discussion about this notion of whether an XForm is a representation of or an application for a resource. Regards Philip -----Original Message----- From: Conal Christopher Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 2:08 PM To: Philip Fennell; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types 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 -----Original Message----- From: Conal Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 7:08 AM To: xsl...@li... Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types I have been using XSLTForms recently, for editing XML metadata records. In our project, we have a RESTful web service (based on a Fedora repository) which uses HTTP Content Negotiation to publish different representations of a resource (i.e. using the same HTTP URL, but in response to different HTTP Accept headers). Each resource may be represented as an XML metadata record or as an XForm, depending on the content-type requested. If a browser sends a request for an HTML page, we want to return an XForm embedded in HTML, but if the browser doesn't want HTML, then we send the "raw" XML record. If the browser accepts HTML, then it receives an XForm, and the XForm itself then issues a request (to the same URL!) to retrieve the XML instance. The problem is that XSLTForms doesn't specify an HTTP Accept header, and the browser (Firefox 5 for example) sends its default Accept header, which includes "text/html", etc. Hence the instance document retrieved is not the "raw" XML representation, but rather an XForm (i.e. the XForm has loaded itself as a model instance!) I think it's a bug for XSLTForms to say that it accepts "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which is the default Accept header in Firefox). It seems sensible to me to set an Accept header listing "text/xml" and "application/xml", so that XSLTForms can be used with services such as ours, which use content negotiation. I found I could fix the problem by explicitly setting the Accept header in xsltforms.js, in two places (there is a case for Internet Explorer and a case for other browsers). See below: > if (window.XMLHttpRequest) { > Core.openRequest = function(method, uri, async) { > // > netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); > var req = new XMLHttpRequest(); > try { > req.open(method, Core.constructURI(uri), async); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This > browser does not support XHRs(Ajax)! \n Cause: " + (e.message || > e.description || e) + " \n Enable Javascript or ActiveX controls (on > IE) or lower security restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > } > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > if (Core.isMozilla) { > req.overrideMimeType("text/xml"); > } > return req; > }; > } else if (window.ActiveXObject) { > Core.openRequest = function(method, uri, async) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This browser does not > support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) + > " \n Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > return req; > }; > } else { > throw new Error("This browser does not support XHRs(Ajax)! \n > Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
From: Conal C. T. <con...@ve...> - 2011-07-23 14:56:13
|
The other list I mentioned is this one: http://discussions.blackmesatech.com/listinfo.cgi/xforms-blackmesatech.com "This discussion list hosts general discussions of XForms, both theoretical and practical. Particular emphasis is placed on questions of how best to use XForms to achieve particular ends and how to solve problems with XForms. Discussions that are focused on the current work of the W3C Forms working group should take place on www...@li..., and discussions that are specific to the behaviors of particular XForms processors should take place on product-specific mailing lists. But general product-independent discussions of how to do specific things with XForms and general debugging questions are in order." ________________________________________ From: Philip Fennell [Phi...@ma...] Sent: Saturday, 23 July 2011 1:43 AM To: Conal Christopher Tuohy; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types Conal, > I wonder if the new xforms-users list is a more appropriate form Can you be more specific about the xforms-users list. I've done a quick search but found nothing matching that name. > 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. Taken in isolation, I can also see that, as part of the transformation that generates a resource's representation, it is a moot point as to whether the resource is included in-line in an XForm or, by reference, out-of-line. I will post a question to the www...@w3... e-mail list to start a discussion about this notion of whether an XForm is a representation of or an application for a resource. Regards Philip -----Original Message----- From: Conal Christopher Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 2:08 PM To: Philip Fennell; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types 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 -----Original Message----- From: Conal Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 7:08 AM To: xsl...@li... Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types I have been using XSLTForms recently, for editing XML metadata records. In our project, we have a RESTful web service (based on a Fedora repository) which uses HTTP Content Negotiation to publish different representations of a resource (i.e. using the same HTTP URL, but in response to different HTTP Accept headers). Each resource may be represented as an XML metadata record or as an XForm, depending on the content-type requested. If a browser sends a request for an HTML page, we want to return an XForm embedded in HTML, but if the browser doesn't want HTML, then we send the "raw" XML record. If the browser accepts HTML, then it receives an XForm, and the XForm itself then issues a request (to the same URL!) to retrieve the XML instance. The problem is that XSLTForms doesn't specify an HTTP Accept header, and the browser (Firefox 5 for example) sends its default Accept header, which includes "text/html", etc. Hence the instance document retrieved is not the "raw" XML representation, but rather an XForm (i.e. the XForm has loaded itself as a model instance!) I think it's a bug for XSLTForms to say that it accepts "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which is the default Accept header in Firefox). It seems sensible to me to set an Accept header listing "text/xml" and "application/xml", so that XSLTForms can be used with services such as ours, which use content negotiation. I found I could fix the problem by explicitly setting the Accept header in xsltforms.js, in two places (there is a case for Internet Explorer and a case for other browsers). See below: > if (window.XMLHttpRequest) { > Core.openRequest = function(method, uri, async) { > // > netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); > var req = new XMLHttpRequest(); > try { > req.open(method, Core.constructURI(uri), async); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This > browser does not support XHRs(Ajax)! \n Cause: " + (e.message || > e.description || e) + " \n Enable Javascript or ActiveX controls (on > IE) or lower security restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > } > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > if (Core.isMozilla) { > req.overrideMimeType("text/xml"); > } > return req; > }; > } else if (window.ActiveXObject) { > Core.openRequest = function(method, uri, async) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This browser does not > support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) + > " \n Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > return req; > }; > } else { > throw new Error("This browser does not support XHRs(Ajax)! \n > Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
From: Philip F. <Phi...@ma...> - 2011-07-23 14:59:12
|
Conal, Thank you for that, I will join the list. Regards Philip ________________________________________ From: Conal Christopher Tuohy [con...@ve...] Sent: 23 July 2011 15:53 To: Philip Fennell; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types The other list I mentioned is this one: http://discussions.blackmesatech.com/listinfo.cgi/xforms-blackmesatech.com "This discussion list hosts general discussions of XForms, both theoretical and practical. Particular emphasis is placed on questions of how best to use XForms to achieve particular ends and how to solve problems with XForms. Discussions that are focused on the current work of the W3C Forms working group should take place on www...@li..., and discussions that are specific to the behaviors of particular XForms processors should take place on product-specific mailing lists. But general product-independent discussions of how to do specific things with XForms and general debugging questions are in order." ________________________________________ From: Philip Fennell [Phi...@ma...] Sent: Saturday, 23 July 2011 1:43 AM To: Conal Christopher Tuohy; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types Conal, > I wonder if the new xforms-users list is a more appropriate form Can you be more specific about the xforms-users list. I've done a quick search but found nothing matching that name. > 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. Taken in isolation, I can also see that, as part of the transformation that generates a resource's representation, it is a moot point as to whether the resource is included in-line in an XForm or, by reference, out-of-line. I will post a question to the www...@w3... e-mail list to start a discussion about this notion of whether an XForm is a representation of or an application for a resource. Regards Philip -----Original Message----- From: Conal Christopher Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 2:08 PM To: Philip Fennell; xsl...@li... Subject: RE: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types 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 -----Original Message----- From: Conal Tuohy [mailto:con...@ve...] Sent: Friday, July 22, 2011 7:08 AM To: xsl...@li... Subject: [Xsltforms-support] Content negotiation problem: HTTP "Accept" header specifies non-XML content types I have been using XSLTForms recently, for editing XML metadata records. In our project, we have a RESTful web service (based on a Fedora repository) which uses HTTP Content Negotiation to publish different representations of a resource (i.e. using the same HTTP URL, but in response to different HTTP Accept headers). Each resource may be represented as an XML metadata record or as an XForm, depending on the content-type requested. If a browser sends a request for an HTML page, we want to return an XForm embedded in HTML, but if the browser doesn't want HTML, then we send the "raw" XML record. If the browser accepts HTML, then it receives an XForm, and the XForm itself then issues a request (to the same URL!) to retrieve the XML instance. The problem is that XSLTForms doesn't specify an HTTP Accept header, and the browser (Firefox 5 for example) sends its default Accept header, which includes "text/html", etc. Hence the instance document retrieved is not the "raw" XML representation, but rather an XForm (i.e. the XForm has loaded itself as a model instance!) I think it's a bug for XSLTForms to say that it accepts "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" (which is the default Accept header in Firefox). It seems sensible to me to set an Accept header listing "text/xml" and "application/xml", so that XSLTForms can be used with services such as ours, which use content negotiation. I found I could fix the problem by explicitly setting the Accept header in xsltforms.js, in two places (there is a case for Internet Explorer and a case for other browsers). See below: > if (window.XMLHttpRequest) { > Core.openRequest = function(method, uri, async) { > // > netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); > var req = new XMLHttpRequest(); > try { > req.open(method, Core.constructURI(uri), async); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new > ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This > browser does not support XHRs(Ajax)! \n Cause: " + (e.message || > e.description || e) + " \n Enable Javascript or ActiveX controls (on > IE) or lower security restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > } > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > if (Core.isMozilla) { > req.overrideMimeType("text/xml"); > } > return req; > }; > } else if (window.ActiveXObject) { > Core.openRequest = function(method, uri, async) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP.3.0"); > } catch (e) { > try { > req = new ActiveXObject("Msxml2.XMLHTTP"); > } catch (e) { > throw new Error("This browser does not > support XHRs(Ajax)! \n Cause: " + (e.message || e.description || e) + > " \n Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } > } > req.open(method, Core.constructURI(uri), async); > // Added by con...@ve... so xsltforms > doesn't accept "text/html" (so that HTTP content negotiation can be used) > req.setRequestHeader("Accept", > "text/xml;q=0.5,application/xml;q=0.6,application/xhtml+xml;q=0.4"); > return req; > }; > } else { > throw new Error("This browser does not support XHRs(Ajax)! \n > Enable Javascript or ActiveX controls (on IE) or lower security > restrictions."); > } -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |