Issue 189 proposals:

I've rewritten my proposals for Issue 189 into more easily parsable text that end in concrete text.  I'm proposing 4 straightforward changes to part 3, and I've dropped any proposal for solving the unknown namespace prefix problem.

Issue 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.  

Proposal #1
Add to section 3.6.1.1 the following paragraph:
A "/" after the element cited in the location attribute indicates that elements not cited in the location attribute MUST not be serialized in the request URI.

Issue 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

Proposal #2a
Change section 3.5.1, 5th bullet to
- The complex types that defines the body of an input element or its children elements MAY contain attributes

Changes to 3.6.1.2:
- Change elements->elements or attributes
- Add to first bullet: Attributes are serialized first, and elements are serialized after attributes.

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]}'

Proposal #2b:
Add to section 3.6.1.1 at the end:
Element names may be followed by a subset of XPath that enables selecting a single child attribute.  This terminates the parsing of the element.  

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

Proposal #3a:
Remove first sentence of section 3.5.1 bullet 3 ("The sequence MUST contain only local element children").  
Add to section 3.6.1.2.  Qualified names (ie ns1:town) are serialized as they appear in the instance data, ie (ns1:town).

Cheers,
Dave

Received on Monday, 19 July 2004 19:53:10 UTC