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

Received on Friday, 19 October 2007 13:33:08 UTC