Discussion:
XForms:instance requests, the HTTP Accept header and RESTful Web Services...
(too old to reply)
Philip Fennell
2007-09-28 08:11:12 UTC
Permalink
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.
Lars Oppermann
2007-10-19 12:33:51 UTC
Permalink
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
Post by Philip Fennell
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
<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 <***@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
N***@inventivegroup.com
2007-10-19 13:32:53 UTC
Permalink
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
Post by Lars Oppermann
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
Post by Lars Oppermann
using the header element, through which the accept header can be setas
needed
Post by Lars Oppermann
by your content negotiation. There is currently no capability of specifying
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
Post by Philip Fennell
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
<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
Post by Lars Oppermann
Post by Philip Fennell
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.
Post by Lars Oppermann
Post by Philip Fennell
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.
Post by Philip Fennell
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
--
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
Philip Fennell
2007-10-19 14:21:41 UTC
Permalink
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: ***@inventivegroup.com
[mailto:***@inventivegroup.com]
Sent: 19 October 2007 14:33
To: Lars Oppermann
Cc: Philip Fennell; www-***@w3.org; www-forms-***@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
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
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
Post by Philip Fennell
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
Post by Philip Fennell
same 'Accept' header whether it comes from a hyper-link in the host
<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
Post by Philip Fennell
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
Post by Philip Fennell
the 'Accept' header is probably too narrow, but something along
these lines would allow a server that uses pre-emptive content
negotiation
to
Post by Philip Fennell
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.
Post by Philip Fennell
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.
Post by Philip Fennell
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
--
Sun Microsystems Lars Oppermann
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.
Philip Fennell
2007-10-19 14:08:05 UTC
Permalink
Lars,
Post by Lars Oppermann
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.
Post by Lars Oppermann
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.
Post by Lars Oppermann
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
Post by Lars Oppermann
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: ***@Sun.COM [mailto:***@Sun.COM]
Sent: 19 October 2007 13:34
To: Philip Fennell; www-***@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
Post by Lars Oppermann
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
<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.
Post by Lars Oppermann
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.
Post by Lars Oppermann
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
--
Sun Microsystems 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.
Lars Oppermann
2007-10-19 15:01:06 UTC
Permalink
Post by Philip Fennell
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?
I didn't mean to add a parameter to the get URL in the source attribute but was
thinking about a new attribute on the instance element which form authers could
use to control RESTful content negotiation, e.g.:
<xf:model>
<xf:instance src="/object/145-12345" type="text/xml"/>
...

With dummy instance for the work-around, I was thinking about not specifying a
URL at all but rather leaving the instance data empty or almost empty at load
time and only replacing the empty document with the submission that has the
appropriate accept header specified. An (untested) example would look like this...

<xf:model>
<xf:instance name="I1"><my:empty/></xf:instance>
<xf:submission action="/object/145-12345"
name="S1" instance="I1" replace="instance">
<header><name>accept</name><value>text/xml</value></header>
</xf:submission>
<xf:action ev:event="xforms-ready">
<xf:send submission="S1"/>
</xf:action>
...

Calling the above mentioned type-attribute syntactic sugar is indeed a bit
harsh, considering its usefulness in a restful application. The problem that I
want to avoid is duplicating the submission module into the instance element...
what if you want to use WSSE headers when loading an initial instance... add
another attribute... and so forth. Hence I'd argue for using the submission
workaround (at least for now), starting with a potentially empty instance,
whenever fine grained control on how an instance is retrieved is needed.
--
Sun Microsystems 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
John Boyer
2007-10-19 16:54:41 UTC
Permalink
Perhaps another thing we could consider for the future is putting a
submission attribute on instance.
This would allow us to avoid creating a second highly configurable
communication object.

The src and resource attributes on instance are designed to provide a
very lightweight syntax for doing easy things.
But our intent was to provide RESTful capabilities through submission. In
XForms 1.1, this means you would have to write

<instance id="X">
<data/>
</instance>

<send ev:event="xforms-model-construct-done" submission="S"/>

<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header>
</submission>

In the future, the following

<instance submission="S"/>

could be a shorthand for the XForms 1.1 syntax.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: ***@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Lars Oppermann <***@Sun.COM>
Sent by: www-forms-***@w3.org
10/19/2007 08:01 AM

To
Philip Fennell <***@bbc.co.uk>
cc
www-***@w3.org
Subject
Re: XForms:instance requests, the HTTP Accept header and RESTful Web
Services...
Post by Philip Fennell
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?
I didn't mean to add a parameter to the get URL in the source attribute
but was
thinking about a new attribute on the instance element which form authers
could
use to control RESTful content negotiation, e.g.:
<xf:model>
<xf:instance src="/object/145-12345" type="text/xml"/>
...

With dummy instance for the work-around, I was thinking about not
specifying a
URL at all but rather leaving the instance data empty or almost empty at
load
time and only replacing the empty document with the submission that has
the
appropriate accept header specified. An (untested) example would look like
this...

<xf:model>
<xf:instance name="I1"><my:empty/></xf:instance>
<xf:submission action="/object/145-12345"
name="S1" instance="I1" replace="instance">
<header><name>accept</name><value>text/xml</value></header>
</xf:submission>
<xf:action ev:event="xforms-ready">
<xf:send submission="S1"/>
</xf:action>
...

Calling the above mentioned type-attribute syntactic sugar is indeed a bit

harsh, considering its usefulness in a restful application. The problem
that I
want to avoid is duplicating the submission module into the instance
element...
what if you want to use WSSE headers when loading an initial instance...
add
another attribute... and so forth. Hence I'd argue for using the
submission
workaround (at least for now), starting with a potentially empty instance,

whenever fine grained control on how an instance is retrieved is needed.
--
Sun Microsystems 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
Lars Oppermann
2007-10-20 09:25:45 UTC
Permalink
John,

This seems like a really good solution, as it avoids the duplicating of
submission functionality into the instance element which I was worried
about. It also shows how submission is somewhat of a high-level wrapper
for an XmlHttpRequest object which isn't explicitly tied to the HTTP
protocol...

/Lars
Post by John Boyer
<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header>
</submission>
In the future, the following
<instance submission="S"/>
Philip Fennell
2007-10-22 08:03:20 UTC
Permalink
Lars, John,

That all makes a lot more sense now. Thank you both.


Regards


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: ***@Sun.COM [mailto:***@Sun.COM]
Sent: 20 October 2007 10:26
To: John Boyer
Cc: Philip Fennell; www-***@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...

John,

This seems like a really good solution, as it avoids the duplicating of
submission functionality into the instance element which I was worried
about. It also shows how submission is somewhat of a high-level wrapper
for an XmlHttpRequest object which isn't explicitly tied to the HTTP
protocol...

/Lars
<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header> </submission>
In the future, the following
<instance submission="S"/>
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.
Klotz, Leigh
2007-10-23 23:14:49 UTC
Permalink
I still think it's wrong that Mozilla Firefox XForms extension is saying
it accepts text/html for instance/@src.

-----Original Message-----
From: www-forms-***@w3.org [mailto:www-forms-***@w3.org] On
Behalf Of Lars Oppermann
Sent: Saturday, October 20, 2007 2:26 AM
To: John Boyer
Cc: Philip Fennell; www-***@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...


John,

This seems like a really good solution, as it avoids the duplicating of
submission functionality into the instance element which I was worried
about. It also shows how submission is somewhat of a high-level wrapper
for an XmlHttpRequest object which isn't explicitly tied to the HTTP
protocol...

/Lars
Post by John Boyer
<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header>
</submission>
In the future, the following
<instance submission="S"/>
John Boyer
2007-10-23 23:51:50 UTC
Permalink
Well, shouldn't it instead just be setting a higher quality rating on
accepting XML content, but not exclude html?

This would allow the bulk of systems to continue serving out well-formed
XML as text/html content. The XForms processor is OK here because it will
just generate a parse exception if the form hits a system that serves out
tag soup. The form author writes the src attribute and there is no xpath
override, so it seems reasonable to put the onus on the form author to src
reference content that is in fact well-formed XML.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: ***@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Klotz, Leigh" <***@xerox.com>
10/23/2007 04:14 PM

To
"Lars Oppermann" <***@Sun.COM>, John Boyer/CanWest/***@IBMCA
cc
"Philip Fennell" <***@bbc.co.uk>, <www-***@w3.org>
Subject
RE: XForms:instance requests, the HTTP Accept header and RESTful Web
Services...






I still think it's wrong that Mozilla Firefox XForms extension is saying
it accepts text/html for instance/@src.

-----Original Message-----
From: www-forms-***@w3.org [mailto:www-forms-***@w3.org] On
Behalf Of Lars Oppermann
Sent: Saturday, October 20, 2007 2:26 AM
To: John Boyer
Cc: Philip Fennell; www-***@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...


John,

This seems like a really good solution, as it avoids the duplicating of
submission functionality into the instance element which I was worried
about. It also shows how submission is somewhat of a high-level wrapper
for an XmlHttpRequest object which isn't explicitly tied to the HTTP
protocol...

/Lars
Post by John Boyer
<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header>
</submission>
In the future, the following
<instance submission="S"/>
Klotz, Leigh
2007-10-24 21:51:33 UTC
Permalink
If instance/@src is not prepared to handle anything but XML it should
not be using
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
n;q=0.8,image/png,*/*;q=0.5
and should omit explicit mention of non-XML types:
Accept: text/xml,application/xml,application/xhtml+xml;q=0.9;*;q=0.5
and given the mediatypes specified in the XForms rec, I would argue
something like this:
Accept: application/xml;q=0.9,text/xml;q=0.7,*/*;q=0.5

In other words, clearly prefer application/xml to text/xml, but let
everything else fall under */*.
Until we get content headers for instance/@src there's no point in
explicitly requesting any application/*+xml for an instance.
Why not application/svg+xml?

I agree of course that submission is different.

Leigh.

________________________________

From: John Boyer [mailto:***@ca.ibm.com]
Sent: Tuesday, October 23, 2007 4:52 PM
To: Klotz, Leigh
Cc: Lars Oppermann; Philip Fennell; www-***@w3.org
Subject: RE: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...



Well, shouldn't it instead just be setting a higher quality rating on
accepting XML content, but not exclude html?

This would allow the bulk of systems to continue serving out well-formed
XML as text/html content. The XForms processor is OK here because it
will just generate a parse exception if the form hits a system that
serves out tag soup. The form author writes the src attribute and there
is no xpath override, so it seems reasonable to put the onus on the form
author to src reference content that is in fact well-formed XML.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: ***@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
<http://www.ibm.com/developerworks/blogs/page/JohnBoyer>





"Klotz, Leigh" <***@xerox.com>

10/23/2007 04:14 PM

To
"Lars Oppermann" <***@Sun.COM>, John Boyer/CanWest/***@IBMCA
cc
"Philip Fennell" <***@bbc.co.uk>, <www-***@w3.org>
Subject
RE: XForms:instance requests, the HTTP Accept header and RESTful Web
Services...






I still think it's wrong that Mozilla Firefox XForms extension is saying
it accepts text/html for instance/@src.

-----Original Message-----
From: www-forms-***@w3.org [mailto:www-forms-***@w3.org
<mailto:www-forms-***@w3.org> ] On
Behalf Of Lars Oppermann
Sent: Saturday, October 20, 2007 2:26 AM
To: John Boyer
Cc: Philip Fennell; www-***@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...


John,

This seems like a really good solution, as it avoids the duplicating of
submission functionality into the instance element which I was worried
about. It also shows how submission is somewhat of a high-level wrapper
for an XmlHttpRequest object which isn't explicitly tied to the HTTP
protocol...

/Lars
Post by John Boyer
<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header>
</submission>
In the future, the following
<instance submission="S"/>
Philip Fennell
2007-10-25 08:17:18 UTC
Permalink
I agree with Leigh that XForms implementations should be using an Accept
header that more acurately reflects what they can 'accept' but still
allowing a fall back for less savy servers that is caught by client-side
validation if an inappropriate representation is served-up.
Post by Klotz, Leigh
application/xml;q=0.9,text/xml;q=0.7,*/*;q=0.5
I'd much rather see the current XForms implementations do the 'right
thing' with the Accept header now, and then see XForms extended in the
near future to allow greater flexibility through John's submission
attribute on the instance element.



Regards

Philip Fennell
Post by Klotz, Leigh
XSLT Developer (Content Management Culture)
BBC Future Media & Technology
Media Village, 201 Wood Lane London W12 7TP
BC4 C4, Broadcast Centre
T: 0208 0085318
________________________________

From: Klotz, Leigh [mailto:***@xerox.com]
Sent: 24 October 2007 22:52
To: John Boyer
Cc: Lars Oppermann; Philip Fennell; www-***@w3.org
Subject: RE: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...


If instance/@src is not prepared to handle anything but XML it should
not be using
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
n;q=0.8,image/png,*/*;q=0.5
and should omit explicit mention of non-XML types:
Accept: text/xml,application/xml,application/xhtml+xml;q=0.9;*;q=0.5
and given the mediatypes specified in the XForms rec, I would argue
something like this:
Accept: application/xml;q=0.9,text/xml;q=0.7,*/*;q=0.5

In other words, clearly prefer application/xml to text/xml, but let
everything else fall under */*.
Until we get content headers for instance/@src there's no point in
explicitly requesting any application/*+xml for an instance.
Why not application/svg+xml?

I agree of course that submission is different.

Leigh.


________________________________

From: John Boyer [mailto:***@ca.ibm.com]
Sent: Tuesday, October 23, 2007 4:52 PM
To: Klotz, Leigh
Cc: Lars Oppermann; Philip Fennell; www-***@w3.org
Subject: RE: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...



Well, shouldn't it instead just be setting a higher quality rating on
accepting XML content, but not exclude html?

This would allow the bulk of systems to continue serving out well-formed
XML as text/html content. The XForms processor is OK here because it
will just generate a parse exception if the form hits a system that
serves out tag soup. The form author writes the src attribute and there
is no xpath override, so it seems reasonable to put the onus on the form
author to src reference content that is in fact well-formed XML.

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: ***@ca.ibm.com

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
<http://www.ibm.com/developerworks/blogs/page/JohnBoyer>





"Klotz, Leigh" <***@xerox.com>

10/23/2007 04:14 PM


To
"Lars Oppermann" <***@Sun.COM>, John
Boyer/CanWest/***@IBMCA
cc
"Philip Fennell" <***@bbc.co.uk>, <www-***@w3.org>
Subject
RE: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...






I still think it's wrong that Mozilla Firefox XForms extension is saying
it accepts text/html for instance/@src.

-----Original Message-----
From: www-forms-***@w3.org [mailto:www-forms-***@w3.org
<mailto:www-forms-***@w3.org> ] On
Behalf Of Lars Oppermann
Sent: Saturday, October 20, 2007 2:26 AM
To: John Boyer
Cc: Philip Fennell; www-***@w3.org
Subject: Re: XForms:instance requests, the HTTP Accept header and
RESTful Web Services...


John,

This seems like a really good solution, as it avoids the duplicating of
submission functionality into the instance element which I was worried
about. It also shows how submission is somewhat of a high-level wrapper
for an XmlHttpRequest object which isn't explicitly tied to the HTTP
protocol...

/Lars
Post by Klotz, Leigh
<submission id="S" replace="instance" instance="X" resource="URL"
serialization="none" ...>
<header> ... set up accept header here ...</header>
</submission>
In the future, the following
<instance submission="S"/>
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.

Loading...