RE: Proposed resolution to LC 77a

I have an option #4. Lets keep this simple. Option #4 introduces a minor
change to URI style,
 
> The sequence MUST contain only local element children
 
The sequence MUST contain only element declarations whose {target namespace}
property is absent.
 
BTW, XForms 1.0 spec, section "Serialization as
application/x-www-form-urlencoded" [1] agrees with me.
 
[1]
http://www.w3.org/TR/2003/REC-xforms-20031014/slice11.html#serialize-urlenco
de
<http://www.w3.org/TR/2003/REC-xforms-20031014/slice11.html#serialize-urlenc
ode> 
 
Regards,
Asir S Vedamuthu
asirv at webmethods dot com
 <http://www.webmethods.com/> http://www.webmethods.com/ 

 
-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of David Orchard
Sent: Friday, April 01, 2005 5:55 PM
To: www-ws-desc@w3.org
Subject: Proposed resolution to LC 77a


LC 77a roughly says there is no mechanism for namespaces to be specified or
used in URIs according to application/x-www-form-urlencoded.  Nor is there
any mention of what happens when qualified XML elements are encoded.
 
There are roughly 3 solutions for namespaces: 1) Disallow qualified
elements, 2) allow qualified but ignore namespace names; 3) allow qualified
and serialize namespace names.
 
Option #1
I think that the specification as it stands says #1, because 3.9.1
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#_operation_uri_style
<http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/#_operation_uri_style
>  says " The sequence MUST contain only local element children".
 
However, this seems very unnatural to me.  All the examples that I did for
the primer assume namespaces as the types were re-used.  The effect of this
is that every type in the primer would have to be duplicated in a
non-namespaced type.  Further the instance data would have to exist in the
namespaced type.  If you wanted an application to deploy on soap over HTTP
and directly over HTTP, you have to duplicate all the input types and data.

 
Therefore, if my interpretation of the status quo is correct, I think this
is really broken and the primer shows that.  
 
Option #3:
 
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
<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.
Both sides have the WSDL, and 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
 
This can be achieved by:
Remove first sentence of section 3.9.1 bullet 3 ("The sequence MUST contain
only local element children").  
Add to section 3.8.1.2.1  Qualified names (ie ns1:town or town) are
serialized as they appear in the instance data, ie (ns1:town or town).
 
The downside to this is that the URIs are not fully self-describing, nor are
the extensible.  If somebody wants to add some extra content, say
ns4:timeOfDay, then there is no way for the receiver to "know" what the new
namespace is.  However, this is for URI Queries, so it's unlikely that a
Query would be able to process the ns4:timeOfDay without knowing about ns4
ahead of time.  
 
Option #2: ignore namespace prefix
Remove first sentence of section 3.9.1 bullet 3 ("The sequence MUST contain
only local element children").  
Add to section 3.8.1.2.1  Qualified names (ie ns1:town) are serialized with
only the local element name, ie (town).
 
Cheers,
Dave
 

 

Received on Thursday, 7 April 2005 15:03:50 UTC