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

Nick,

I know that the PicoForms developers have considered this and found that
'a lot of Web servers not doing the right thing' and in order to get
some forms to work they have chosen to set the accept header of an
instance request to */*.

With the exception of Lars' workaround, I cannot see how I can go in
both an XForms and REST direction if I am not provided with the control
over request headers that REST requires.
 


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: Nick_Van_den_Bleeken@inventivegroup.com
[mailto:Nick_Van_den_Bleeken@inventivegroup.com] 
Sent: 19 October 2007 14:33
To: Lars Oppermann
Cc: Philip Fennell; www-forms@w3.org; www-forms-request@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...

Hi Philip, Lars,

I think that an implementation (XForms 1.0 or 1.1) is free to specify an
accept header when retrieving the initial instance and when on
submission when instance, all or text is specified for the replace
attribute. But because it is not specified in the spec it is
implementation dependant if the implementation adds the accept header
when that header attribute is not specified on the submission element.

More precise an implementation __could__ add the following accept header
when:

- src or resource on instance : text/xml,application/xml
- instance on submission : text/xml,application/xml
- text on submission : text/plain
- all on submission: add the supported mimetypes of your application

Regards,

Nick Van den Bleeken  -  Research & Development Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com

www-forms-request@w3.org wrote on 10/19/2007 02:33:51 PM:

> 
> 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 setas
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/plai
> > 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
> 



--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer


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:21:57 UTC