W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2005

RE: Proposed resolution to LC 77a

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Thu, 7 Apr 2005 13:19:09 +1000
Message-ID: <7997F38251504E43B38435DAF917887F58E461@ausyms23.ca.com>
To: <www-ws-desc@w3.org>
Serialising the namespace rather than the prefix does render comparison independent of the choice of prefix, which appeals to me - it continues to annoy me that canonicalisation doesn't work this way.
Tony Rogers
tony.rogers@ca.com <blocked::mailto:tony.rogers@ca.com> 


From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh
Sent: Thursday, 7 April 2005 10:33
To: David Orchard; www-ws-desc@w3.org
Subject: RE: Proposed resolution to LC 77a

Seems like the complete solution serializes the QName as  (URI, localName) pair rather than a (prefix, localName) pair.  Is there a reason you didn't propose an option for this as well (besides the fact that the resulting URI would be rather long, ugly, and opaque)?



From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On Behalf Of David Orchard
Sent: Friday, April 01, 2005 2: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 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, 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.
is serialized as 
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  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  Qualified names (ie ns1:town) are serialized with only the local element name, ie (town).

Received on Thursday, 7 April 2005 03:19:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:49 UTC