RE: XForms:instance requests, the HTTP Accept header and RESTful Web Services...

Lars,

> We talked about your issue during the last WG call...

Wow, and there I thought my question had fallen on stoney ground.

Thanks for the response.

> In order to load a default instance from a URI that uses content
> negotiation, you could start with an empty/dummy instance, set 
> up a replacing submission which has the required accept header 
> specified and trigger that submission once the form is initialized.

I understand your work-around and I can see how it would work. It is
kind of RESTful in that the 'dummy' response could be regarded as one
representation of the resource pointed to by the URL. The subsequent
submission sets a different Accept header (text/xml), for which the
response is a different representation (the XML representation that I
realy want) of that requested resource. However, the problems start when
we get a clash of MIME-type useage. If we assume that the XForms
implementation uses the browser's Accept header for the original request
then I cannot use the browser to request an HTML 'preview' using the
same URL with the same header. Now the problem has been shifted to the
XForm's host document because I have no control over what header is sent
by the browser for a simple XHTML hyper-link either.


> A more direct approach would be to allow authors to specify 
> content negotiation parameters with additional attributes on 
> the xf:instance element. However, this would be duplication 
> of facilities already provided in submission. Thus, if the 
> use-case can be solved with a custom submission I'd prefer 
> that approach over adding syntactic sugar to the xf:instance 
> element.

If parameters are added to the URL to 'help' the process of content
negotiation then things are no longer RESTful because the addition of
the parameter(s) the URL and we no longer have one URL per resource.

I think it is a bit harsh to say that providing the ability to specify
an Accept header for the instance request is 'syntactic sugar'. Why is
it so much more important for the submission than it is for the intial
request?


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: Lars.Oppermann@Sun.COM [mailto:Lars.Oppermann@Sun.COM] 
Sent: 19 October 2007 13:34
To: Philip Fennell; www-forms@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...

Hi Philip,

We talked about your issue during the last WG call...

Generally, what you are looking for is supported in xforms 1.1
submissions by using the header element, through which the accept header
can be set as needed by your content negotiation. There is currently no
capability of specifying accept header contents for instances loaded
with xf:instance/@src attribute. The processor would assume that
whatever is returned from that URI should be parsed as XML.

In order to load a default instance from a URI that uses content
negotiation, you could start with an empty/dummy instance, set up a
replacing submission which has the required accept header specified and
trigger that submission once the form is initialized.

A more direct approach would be to allow authors to specify content
negotiation parameters with additional attributes on the xf:instance
element. However, this would be duplication of facilities already
provided in submission. Thus, if the use-case can be solved with a
custom submission I'd prefer that approach over adding syntactic sugar
to the xf:instance element.

Bests
Lars

Philip Fennell wrote:
> I'm working on a XForms demo that combines XML content editing and 
> RESTful Web Services.
> 
> Whilst looking at the HTTP request headers sent by an xforms:instance 
> request by the Mozilla XForms plug-in I noticed that the server gets 
> the same 'Accept' header whether it comes from a hyper-link in the 
> host XHTML page or from an XForms instance request:
> 
> <a href="objects/0901047880012b9b" title="example xhtml content"
> type="text/html">...</a>
> 
>  or
> 
> <xforms:instance xmlns="" id="content"
> src="../objects/0901047880012b9b"/>
> 
>  sends
> 
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl
> ai
> n;q=0.8,image/png,*/*;q=0.5
> 
> 
> Given that XForms is designed for editing well-formed XML, should it 
> not be the case that an XForms implementation should declare to the 
> server that it only accepts XML. Now I'd admit that just sending 
> 'text/xml' in the 'Accept' header is probably too narrow, but 
> something along these lines would allow a server that uses pre-emptive

> content negotiation to return an XML representation of a concept to 
> the XForm and an XHTML
> (preview) representation to a hyper-link from the host XHTML page.
> Otherwise, I cannot see how XForms can operate within a RESTful Web 
> Service where content negotiation is used to serve appropriate 
> representations from opaque URLs.
> 
> 
> 
> 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
>>
> 
> 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.
> 					
> 
> 


-- 
Sun Microsystems                Lars Oppermann <lars.oppermann@sun.com>
Nagelsweg 55                    Software Engineer
20097 Hamburg, Germany          Phone: +49 40 23646 959
http://www.sun.com/             Fax:   +49 40 23646 550
-----------------------------------------------------------------------
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten, Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer Vorsitzender des
Aufsichtsrates: Martin Haering

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 Friday, 19 October 2007 14:08:18 UTC