Issue 189: Binding message content to URI

Issue 189 overview.

In general, the proposal for the application/x-www-form-urlencoded faithfully models serializing an xml tree of form data into a URI.  This is by no means a complete solution for how to use URIs and XML documents with HTTP as a transfer protocol.  The particularly noticable areas are the deficiencies in serializing normal xml structures into a URI, and the use of the HTTP PUT method.  I have distilled my concerns into 3 discrete problems with proposed solutions.

Issue 189 Part 1

As I've shown the "Music" example at http://www.pacificspirit.com/Authoring/wsdl/ArtistWSDL2uriformencoding.html, there are some cases where the current wsdl binding makes it impossible to fully utilize HTTP with the current uri-encoding style.  In particular, the PUT operation cannot work with the www-form-uriencoded style which is a client-generated URI mechanism.  

One scenario is a "PUT" operation.  An HTTP PUT says that the input resource replaces the resource at the URI.  These URIs are typically dynamic, either constructed at the client or the server.  In the case of a client constructed URI using the www-form-uriencoding style, we would need to have the input data that will be used in the URI.  An example of this is an ID element, which would be used to make an entry like /Music/Artist?id=5.  Also think of how to set the temperature of Frejus.  There are 2 problems that emerge:

1. The Artist resource may not have an ID element that is to be used in this regard.  The ID element may be generated as part of an ArtistList return for example.  This results in the problem that the ID may be part of the input but is not serialized in the body.  The solution to this is to allow input data that is not serialized in the body.  I don't believe the group is that interested in this, as I think the compromise of allowing body data in the URI was essential to moving forward.  

2. If the Artist resource does have an ID element, then the current binding does not allow only part of the input data to be serialized into the URI.  The rough assumption is that a "GET" will be the operation so all the data goes in the URI.  That is clearly not the case.  The solution is to have a mechanism for subsetting the input data to go into the URI.  One suggestion is that the www-uriencoding algorithm have some way of terminating the parsing of the input data.  The simplest that I can do is to add an optional "/" character inside the curly brace at the end to indicate only the specified element content (and no siblings) are to be serialized.  http:operation location='temperature/{town/}' then becomes "temperature/Fr%C3%A9jus".

This same problem can occur with HTTP POST.  HTTP POST allows the client to give a URI that it thinks will be the URI for the resource it is POSTing.  The server can disagree of course, but the client does have the luxury of making a gentle suggestion.

There are other problems with the binding of message content that are more stylistic than out and out flaws like the previous.

Issue 189 Part 2a

There is no mechanism for adding attributes into message content.  XML's regular use of ID and href is precluded.  The simplest solution that I can achieve is that an attribute on an element is treated as the first sibling for the purposes of serialization.  Thus

<data>
  <town id="5">Fréjus</town>
  <date>2004-01-16</date>
  <unit>C</unit>
</data>

is serialized as temperature/Fr%C3%A9jus?id=5&date=2004-01-16&unit=C

Issue 189 Part 2b

The above proposal allow attributes as query parameters.  But it does not allow the value to be encoded in a URI as part of the path, such as:

temperature/town/5

The solution is to allow a subset of Xpath, particularly attribute expression inside the curly brace where an attribute may be specified.  Specification of an xpath expression expression would end the substitution rules processing.

Something akin to:
location='temperature/town/{town[@id]}'

Perhaps the simplest solution is to use the "barename" syntax and only allow ids to be serialized into uris, something like:
location='temperature/town/{town#id}'

If it came to a decision of a subset of xpath wouldn't pass muster but barenames would, i'd choose barenames to at least allow specification of id attributes.

Issue 189 Part 3a

There is no mechanism for namespaces to be specified or used in URIs.  Many XML applications make use of namespaces.  As I mentioned in the binding of Qnames to URIs blog entry, http://www.pacificspirit.com/blog/2004/04/29/binding_qnames_to_uris, there are many ways of serializing qnames.  

I think the very simplest for WSDL is #16, where the ns decl is skipped.  When XML is serialized, the schema must have specified any namespaces associated with elements.  These namespaces are invarient from the interface perspective.  The simplest solution I can suggest is that the namespace prefix be included in the URI when a namespace prefix is in the instance data.  As an example, ns1, ns2, ns3 are defined in the wsdl.

<ns1:data>
  <ns1:town>Fréjus</ns1:town>
  <ns2:date>2004-01-16</ns2:date>
  <ns3:unit>C</ns3:unit>
</ns1:data>

is serialized as 
temperature/Fr%C3%A9jus?ns2:date=2004-01-16&ns3:unit=C

Issue 189 Part 3b

The previous proposal does not cover the scenario where the client has extended the element content, assuming that the data structure had a wildcard, ie

<ns1:data>
  <ns1:town>Fréjus</ns1:town>
  <ns2:date>2004-01-16</ns2:date>
  <ns3:unit>C</ns3:unit>
  <ns4:foo>foo</ns4:foo>
</ns1:data>

 this is a difficult sitution to resolve.  We could simply keep the status quo, which roughly says that extensibility is not allowed in the element content (the sequence MUST only contain elements).  

I'm somewhat torn whether this is a good solution or not.  The notion that a client would be able to extend a query with data that the server will ignore seems potentially useful from an XML perspective but less so from an HTTP perspective.  

Should we choose to allow namespace names to be serialized, I suggest that the passing the QName by lexical value would be a good option, as in option #10:

temperature/Fr%C3%A9jus?ns2:date=2004-01-16&ns3:unit=C&(ns4namespacename)foo=foo

Cheers,
Dave

Received on Tuesday, 6 July 2004 19:34:23 UTC