WSDL 2.0 Candidate Recommendation Issues List

CR005: Built in XML Schema types [link to this issue]

While working on the Woden implementation of the WSDL 2.0 component model 
I came across an implementation detail that isn't spelled out in the spec. 
I'd like some input from the working group.

Section 3.1 of the WSDL 2.0 spec states that the XML schema types are 
built in to WSDL 2.0 and do not have to be imported. Should these types be 
available from the type definitions within the Description component? i.e. 
In a WSDL 2.0 component model implementation, should I be able to access 
these types from the type definitions on the Description component?

Transition history

raised on 17 Jan 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 16 Feb 2006

Accept R2 from Arthur's proposals.

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR009: SOAP binding: empty SOAP Action [link to this issue]

Our specification says, for specifying SOAP Action[2]:

  {soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as
  defined by [IETF RFC 3987], to the Binding Operation component. The
  value of this property identifies the value of the SOAP Action
  Feature for the initial message of the message exchange pattern of
  the Interface Operation bound, as specified in the binding rules of
  bindings to specific versions of SOAP (see 5.10.3 SOAP 1.2 Binding
  Rules for the SOAP 1.2 binding when the value of the {soap version}
  property of the Binding component is "1.2").

I.e., it doesn't allow an empty string as the value for {soap action}.

However, in SOAP 1.1, SOAPAction may be equal to ""[3], and the WS-I
BP 1.0 does allow it[1], which actually seems to be looser than what
WSDL 1.1 allows[4], but that's another story.

So I think that, in order to cover all the cases, we should allow the
empty string for {soap action} in addition to an absolute IRI.

SOAP 1.2 is not clear about whether an empty string is allowed or
not[5]. As it's not forbidden and "" is part of the value space of
xs:anyURI, I think it's fine.

So, for a concrete suggestion, I would like to proposed:

  {soap action} OPTIONAL. A xs:anyURI, which is an absolute IRI as
  defined by [IETF RFC 3987] *or an empty string*, to the Binding
  Operation component.

Cheers,

Hugo

  1. http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Describing_SOAPAction
  2. http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060106/#soap-operation-decl-relate
  3. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528
  4. http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:operation
  5. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ActionFeature

Transition history

raised on 8 Feb 2006 by Hugo Haas (hugo@w3.org)

agreed on 27 Feb 2006

Replace [quoted string value] with [quoted empty string value ("")].

Acknowledgment cycle

announced by group on 16 Mar 2006

Action history

CR017: Action Item 2006-02-16 [link to this issue]

We decided to allow extension attributes that are not part of the
signature for RPC style. I noticed that neither the IRI style nor the
multipart style have a similar allowance. I believe we included this
allowance to RPC style to put metadata assertions as attributes for the
signature. Similar metadata may be useful for the other styles, but I do
not have any use cases.

Transition history

raised on 28 Feb 2006 by Yalcinalp, Umit (umit.yalcinalp@sap.com)

declined on 16 Mar 2006

RPC is different than IRI or multipart in that the extension attributes won't appear in the message. There is therefore no utility in such attributes, and no positive reason to change the spec at this point.

Acknowledgment cycle

announced by group on 16 Mar 2006

CR019: Must XML schema elements by imported in WSDL 2.0? [link to this issue]

The following question arose while developing Woden [1].

Assertion Schema-0016 (from section 3.1) states:

"A WSDL 2.0 document MUST NOT refer to XML Schema components in a given 
namespace unless an xs:import or xs:schema element information item for 
that namespace is present or the namespace is the XML Schema namespace 
which contains built-in types as defined in XML Schema Part 2: Datatypes 
Second Edition [XML Schema: Datatypes]."

The end of the sentence, "...which contains built-in types..." seems to 
imply that only XML Schema types are implicitly available in WSDL 2.0. Are 
schema elements also implicitly available in WSDL 2.0? For example, if I 
want to define an input as follows

<wsdl:input element="xsd:schema" />

do I need to import the schema namespace?

If the answer is yes, I suggest the assertion text be modified to 
explicitly state that the schema namespace must be imported if schema 
elements are to be used. As a suggestion,
"...XML Schema namespace and an XML Schema type has been referenced. XML 
Schema contains..."
If the answer is no, I suggest the assertion text be modified to make it 
clear that both elements and types are available. As a suggestion,
"...which contains elements and built-in types...".

[1] http://incubator.apache.org/woden

Transition history

raised on 14 Mar 2006 by Lawrence Mandel (lmandel@ca.ibm.com)

agreed on 30 Mar 2006

Add: "If a WSDL 2.0 document refers to any component (element, simple type, complex type, etc) of the http://www.w3.org/2001/XMLSchema namespace except the built-in simple types, then it MUST import http://www.w3.org/2001/XMLSchema."

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR024: Part 2 Adjuncts Comments (1 -5) [link to this issue]

1. In 4.2 IRI Style, the content model of the initial is constrained to 
have a sequence of child elements. What are the occurrence contraints? Are 
there any?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

Add clarification that there are no occurance constraints.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR025: Part 2 Adjuncts Comments (1 -5) [link to this issue]

2. In 4.2 IRI Style, the last bullet says: "If the children elements of 
the sequence are defined using an XML Schema type ...". What else could 
they be defined as? Don't all elements have a type?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

Add clarification.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR026: Part 2 Adjuncts Comments (1 -5) [link to this issue]

3. In 5.3 SOAP Binding Rules, the rule about mustUnderstand seems weak. If 
the SOAP Header block is marked as mustUnderstand=true in WSDL, then 
shouldn't the header in the SOAP message also have mustUnderstand=true?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

strengthen "should" to "MUST".

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR027: Part 2 Adjuncts Comments (1 -5) [link to this issue]

4. In 5.6.2, isn't {soap fault codes} really a set and not a list? The 
order of subcodes is irrelevant and it doesn't make sense to repeat a 
subcode. Sounds like a set. Also, is there a difference between having an 
empty set of subcodes and #any. I assume #any means any subcode may be 
used. Does an empty set mean the subcodes are never used?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 11 May 2006

Add clarification along the lines "The value of this property identifies one or more subcodes for this SOAP fault. The list of subcodes is the nested sequence of subcodes, an empty list represents a fault code without subcodes."

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR029: Part 2 Adjuncts Comments (1 -5) [link to this issue]

6. In 5.7.2 is there any constraint between WSDL meps and SOAP meps, i.e. 
if an operation uses a given WSDL mep, then does that restrict the allowed 
SOAP mep used in the biniding?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 8 Jun 2006

Adopt Amy's proposal.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR030: Part 2 Adjuncts Comments (1 -5) [link to this issue]

7. In 5.7.2 there are defaulting rules for {soap mep} but is a value for 
the actual SOAP mep required, i.e. must the defaulting rules produce a 
definite value?

Transition history

raised on 4 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 18 May 2006

Add a reference to 5.10.3, where the "rollup" is specified.

Acknowledgment cycle

announced by group on 30 Aug 2006

Action history

CR037: Comments on Part 2, Chapter 6 [link to this issue]

4. In 6.7 Serialization Format of Instance Data, Table 6-5, why is the 
application/xml the only mime type that can be returned on the output 
message? The other two types might also be useful in outputs. Multipart 
output seems reasonable.  URL encoded output is less likely.

Transition history

raised on 6 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

declined on 6 Jul 2006

Close with no action.

Acknowledgment cycle

announced by group on 30 Aug 2006

CR041: Comment on Part 2, Section 6.5.2 [link to this issue]

In the {http headers} property, is the {name} of the HTTP Header 
component, a key? i.e., is each HTTP Header component in {http headers} 
uniquely identified by it's {name}?

This is implied by 6.5.6 IRI Identification Of An HTTP Header component 
which uses the {name} in the frag id, so it had better be unique.

Transition history

raised on 9 May 2006 by Arthur Ryman (ryman@ca.ibm.com)

agreed on 1 Jun 2006

Add constraint that the {name} is unique within the {http headers} property.

2006-09-14: WG agrees this constraint is already there - dropping the AI.

Acknowledgment cycle

announced by group on 10 Oct 2006

CR045: Inline schemas with no target namespace [link to this issue]

Section 3.1.2.1 of the Core Langage spec says
"WSDL 2.0 modifies the XML Schema definition of the xs:schema element
information item to make this attribute information item required".

There is a scenario where I have an existing XSD that I am intending
to re-use while designing the WSDL. The XSD has no target namespace,
and has a bunch of elements and attributes defined within it. What it
also does is to import a couple of XSDs that have a non-null target
namespace. the wsdl intends to define the message parts to point to
one of the nodes defined in the imported XSDs within the nonamespace
XSD. The nodes that had been directly defined in the no-namespace XSD
are not used by the WSDL, but are consumed by other applications.
In this case, do yo think that it would be "really" invalid to inline
such an XSD into the WSDL ? I was wondering that atleast
theoretically, this should be possible. The question is - "Do we need
to make some statements around this in the spec" ?

Transition history

raised on 19 May 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 21 Sep 2006

Remove removing assertion #Schema-0019-summary (no requirement schemas have a target namespace.)

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR050: When does {safety} appear? [link to this issue]

The wsdlx:safe extension is optional "extension MAY be used", but adds
the "REQUIRED" {safety} property.  The property has a default value of
"false".

From this I assume that an implementation that supports the extension
will always have the safety property present, regardless of whether
wsdlx:safe appears in the WSDL.

I ask because the Woden interchange results don't seem to add the
property unless the attribute appears in the WSDL -- which is entirely
reasonable, and what I also prefer.  Namely, the absence of the property
should clearly be equivalent to the value "false".

I think the simple fix is to make the property OPTIONAL and remove the
defaulting to "false".  Then, if the attribute doesn't appear, the
property will be absent.

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.
html?content-type=text/html;%20charset=utf-8#safety

Transition history

raised on 24 May 2006 by Jonathan Marsh (jmarsh@microsoft.com)

declined on 8 Jun 2006

Close with no action.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR051: when does wsoap:code appear? [link to this issue]

Similarly to safety, it's not clear when wsoap:code and wsoap:subcode
should appear.

Both of these properties are OPTIONAL, yet the mapping defaults the
value to "#any".  Thus whether the property appears isn't deterministic
to the WSDL.  One implementation could leave it out (e.g. Woden) when
it's not in the WSDL, another could always put it in.

The fix seems to be to make the property REQUIRED when the soap binding
is in effect, or to remove the "#any" default and say that no value is
the same as "#any".

Transition history

raised on 24 May 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 8 Jun 2006

Proposed fix accepted.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR053: Allow absolute URI in {location} [link to this issue]

The second comment I have is that it should be possible to "follow an
hyperlink" and give an absolute URI in the whttp:location attribute.

There seems to be no reason why the URIs should follow a predefined
hierarchical structure and in this blog system example, we could imagine
a central server powering different domains. 

The first POST could be at  http://van-der-vlist.com/blog/ and the
server could determine from my credentials a specific (and dynamic)
domain name for the location of the blog entry
(http://eric.van-der-vlist.com/blog/2277_Validatting_microformats).

My understanding of the current WD is that whttp:location="{location}"
wouldn't work if location was containing an absolute URI.

Couldn't that behaviour be changed?

Transition history

raised on 26 May 2006 by Eric van der Vlist (vdv@dyomedea.com)

agreed on 21 Sep 2006

Adopted proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0034, as amended by http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0037.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR055: Clarification needed on HTTP Transfer Coding [link to this issue]

Can someone please clarify some points about the http transer coding
extension properties defined in Part 2 section 6.8.2 Relationship to WSDL
Component Model [1]?

It says the Binding has a {http transfer coding default} property that is
available to InterfaceMessageReference and InterfaceFaultReference
components. Is this worded correctly? Do components from the abstract
interface need http binding information?

It also says BindingOperation has a {http transfer coding default} property
that is available to BindingMessageReference and BindingFault components. Is
'BindingFault' a mistake, should this say BindingFaultReference?

There are no semantic rules about the relationship between the two {http
transfer coding default}  properties (i.e. in Binding and BindingOperation),
so they could potentially be different. I don't think this would make sense,
but it seems to be possible according to the way this section is described.

Finally, there are no semantic rules about the relationship between
BindingOperation's {http transfer coding default} property and the {http
transfer coding} properties if its two child components. As an implementor I
can infer what that relationship might be, but it would be better if the
spec stated in explicitly as it does for default and actual extension
properties elsewhere.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#http-transfer-coding-relate

Transition history

raised on 26 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 7 Sep 2006

Closed by adopting the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0004.html, minus the sentences beginning "If this property is not present ..." on the last two bullets, plus the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2006Sep/0008.html plus a final bullet in each list reading "Otherwise none."

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR072: Questions on {http method} and {safety} extension properties [link to this issue]

Some questions arose while implementing HTTP extensions from Part 2
Adjuncts.

In 6.3.1 HTTP Method Selection at [1]  is there a default value for {http
method} if the {safety} property is "false"?

In 3.1 Operation Safety at [2] the {safety} property is defined as REQUIRED
with a default value of "false" if not specified in the WSDL, so is the
wording at [1] "...if a {safety} property ... is present ..." redundant (i.e.
{safety} will always be present)?

And there's a possible typo in section 3.1 at [2].  The assertion refers to
"...a safe interaction defined in Section 3.5 of [Web
Architecture<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#webarch>
]". I think this should say Section 3.4 (i.e. section 3.4 Safe
Interactions).

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#_http_binding_default_rule_method
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html#property-InterfaceOperation.safety

Transition history

raised on 23 May 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 13 Jun 2006

This issue is a duplicate of CR050 and CR035, and the typo mentioned has already been fixed.

Acknowledgment cycle

announced by group on 16 Oct 2006

CR076: {rpc signature} REQUIRED when rpc style is not specified? [link to this issue]

Section 4.1.1 of the Adjuncts specifies {rpc signature} as a required
property.  Per our recent clarifications, this will appear in the
component model whenever the implementation supports the rpc extension.
Thus, even if the {style} property does not include the rpc-style uri,
the {rpc signature} property will appear.  No default value is supplied
either.

Instead, I believe it would be cleaner to make the {rpc property}
optional, and state that when the rpc style is engaged, the property
MUST appear.

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#InterfaceOperation_RPC_Signature_Definition

Transition history

raised on 12 Jul 2006 by Jonathan Marsh (jmarsh@microsoft.com)

agreed on 20 Jul 2006

Add co-occurance constraint (that must be there if the style is RPC), and make the property OPTIONAL.

Acknowledgment cycle

announced by group on 16 Oct 2006

Action history

CR092: Re: WSDL 2.0 Fault Binding [Plus two Questions] [link to this issue]

[Section 5.4.5 of SOAP 1.2 Part 1] SOAP 1.2 states the following - "All
child *element information items* of the Detail *element information
item*are called detail entries ".
This means that the "Detail" element information item  can have multiple
detail entries. Does that mean that the user shd be able to define multiple
element info items while describing a Fault in a WSDL Document, or cd the
child elements of a fault element in the WSDL be directly copied under
the <Detail> element in a SOAP Fault EII ?

Transition history

raised on 10 Nov 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 7 Dec 2006

Add http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0017.html and say that the soap1.2 fault details element will contain a WSDL-described element, but may also contain other stuff that is not described.

See also http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0054.html.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR093: Re: WSDL 2.0 Fault Binding [Plus two Questions] [link to this issue]

[Section 5.4.5.1 of SOAP 1.2 Part 1] states that "Each detail entry MAY
have a [namespace name] property which has a value, that is the name of the
element MAY be namespace qualified." This means that the detail entries may
alternatively come from "null/No Namespace". How wd a user be able to model
this in a WSDL description ?

Transition history

raised on 10 Nov 2006 by Ramkumar Menon (ramkumar.menon@gmail.com)

agreed on 7 Dec 2006

Editorial fixes implemented for CR092 suffice to clarify.

Acknowledgment cycle

announced by group on 15 Feb 2007

CR109: SOAP Fault code issue [link to this issue]

Related to MessageTest-1G document, I have the following comment with 
the specification.

Currently, the soap fault code property can take any qname value.

It is fine for soap 1.1 but soap 1.2 constraints the qname value to be 
in a set of 5 predefined QNames.

It would be good if we could put an assertion to the spec stating that 
if soap1.2 is engaged the fault code qname must be in the predefined 
QName set.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 14 Dec 2006

Add an assertion that when using SOAP 1.2 the fault code QName is constrained to the five values from the spec.

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR110: Semantics of {http cookies} Property. [link to this issue]

This came up at the interop event in Dinard:

1. The spec is unclear.[1] What is the meaning of the {http cookies} property?

Does is state whether the service will send cookies or whether the
client needs to understand cookies.

I recommend that it mean that the service uses cookies in some meaning
way and that the client will be unable to use the service effectively
unless it supports cookies.

2. The spec is inconsistent. It says Binding components MAY indicate
..., and also that the property is REQUIRED.

The XML attribute is optional, but the property is REQUIRED.
Therefore, a Binding  component MUST indicate...

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#http-cookies-decl

Transition history

raised on 15 Nov 2006 by Arthur Ryman (arthur.ryman@gmail.com)

agreed on 14 Dec 2006

1) Clarify that "true" means the service relies on cookies and client must understand them; 2) change "MAY indicate" to "indicates".

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR111: Mapping WSDL meps to the HTTP binding [link to this issue]

Reading the HTTP binding specification I have the following comment.

Currently the mapping from WSDL meps to HTTP binding  messages is 
described in section 6.4.1.

Basically it says that the wsdl input message is the http request 
message and the wsdl output message, if any is the http response message.
I wonder whether this description is sufficient for the inonly and 
especially robust-inonly wsdl meps.

At least, we might need to specify the HTTP code to use in the response, 
especially for the robust-inonly.

Should it be 200, 202 or left unspecified as it is currently?
Are there other things that need to be specified?

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 21 Dec 2006

Specify 202 for the response to in-only, and 204 for the response to robust-in-only.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR113: SOAP Response query string issue [link to this issue]

Continuing on the SOAP/HTTP Binding review,
I have a comment related to the SOAP binding section 5.10.4.2.1.

When using the SOAP-Response MEP, one needs to serialize the input data, 
if any, in the URI as a query string, following what is done in the HTTP 
binding (section 6.7.2).

The issue is that section 6.7.2 serialization is based on the query 
parameter separator and query parameter default separator properties. 
These properties, while present in the HTTP binding, are not brought in 
the SOAP binding.

Here are two suggestions to solve this small issue:
    - add to the soap/http binding the query parameter separator default 
property, which has the '&' value by default
    - do NOT add any of the @whttp:queryParameterSeparator and 
@whttp:queryParameterSeparatorDefault attributes, as this flexibility is 
not required by the soap binding IMHO.

This way, the serialization algorithm will always use the '&' character 
as the query parameter separator character.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 14 Dec 2006

Add the query separator and query separator default properties to the SOAP binding.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR114: Mapping WSDL MEPs to SOAP MEPs [link to this issue]

Reviewing the soap binding, I have the following comments.

As of today, the SOAP binding defines how to map the inout mep to the 
request-response and soap-response meps.

The mapping from in-only and robust in-only meps to SOAP meps are not 
defined, which makes difficult or at least not very interoperable the 
use of these two WSDL meps with the SOAP binding.

It seems that the newest version of the SOAP1.2 specification 
(http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html) will provide 
the SOAP/HTTP binding with the support of the request-optional response 
mep. This mep fits well with the robust-in-only mep at least.

It may therefore be interesting to add in the WSDL SOAP binding section 
a robust-inonly mep to soap mep mapping description.

Concerning the in-only mep, the situation seems less clear. Of course we 
could also bind the in-only mep to the request-optional response mep. On 
the other hand, a SOAP1.2 one way mep is under way but has no support in 
the SOAP1.2/HTTP binding.

Transition history

raised on 15 Nov 2006 by youenn fablet (youenn.fablet@crf.canon.fr)

agreed on 21 Dec 2006

Specify in section 5.10.4 the mapping of in-only and robust-in-only MEPs to the SOAP request-response MEP, taking advantage of the new 202.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR116: 6.7.1.1 Construction of the request IRI using the http location [link to this issue]

Given this instance data:
 <root>
   <foo>1</foo>
   <foo>2</foo>
 </root>

With http:location="t"
we should obtain "t?foo=1&foo=2"

With http:location="t/{foo}"
we should obtain "t/1?foo=2"

With http:location="t/{foo}/{foo}"
we should obtain "t/1/2"

With http:location="t/{foo}/{foo}/{foo}"
should we obtain an error (we don't have 3 foo elements in the instance
data) or, should we obtain "t/1/2/1" or "t/1/2/2" ?

As a side comment, using element names in the http:location adds an
additional message schema constraint, in addition to the ones already
defined the IRI style: those element names shouldn't be optional. If one
of those http:location element names is defined as optional in the
schema, not including it in the instance data could result in a runtime
error.

Transition history

raised on 16 Nov 2006 by Philippe Le Hegaret (plh@w3.org)

agreed on 21 Dec 2006

1) Rewrite HTTPSerialization-5073 to talk about types rather than instances.

2) Say each token SHOULD match something in the instance.

3) If there is no match, replace the token with the empty string.

4) A token may appear more than once, in which case it is replaced by corresponding repeated elements in the instance. [ednote: I think this is already in the text.]

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR117: Re: 6.7.1.1 Construction of the request IRI using the http location [link to this issue]

Following on philippe's message, there are also ambiguous cases that 
might happen.

Given this schema:
<element name=root>
    <sequence>
        <element name=person type=string minOccurs=0/>
        <element name=address type=string minOccurs=0/>
        <element name=surname type=string minOccurs=0/>
    </sequence>
</element>

Given this instance data:
<root>
    <person>foo</person>
    <address>/</address>
    <surname>foo</surname>
</root>
with http:location="foo/{person}/{address}/{surname}

we will obtain foo/foo///foo, which leads to ambiguous parsing on the 
server side (as address='' and surname='/foo' will also lead to the same 
uri-encoded data).

Should we prevent this case and escape the '/' character in url path 
encoded data?

There is also the case of the '?' special character that may lead to 
issues in determining when begins the query string.
Should we prevent this case and escape the '?' character in url path 
encoded data?

Transition history

raised on 22 Nov 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 8 Feb 2007

Resolved by accepting proposal for Option 1, plus correct placement of "/" and "?" (should be allowd in query params, not in paths), change syntax to "!" from "~", and add a constraint that the query parameter separator must be encoded.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR120: SOAP Response and IRI style [link to this issue]

When the soap response MEP is used to bound an in-out operation, the 
input being defined by a schema,
the input is serialized in the URI following the url-encoded 
serialization (section 6.7.2).

This serialization requires the use of the IRI style which puts a 
constraint on the kind of operations that can be bound to the soap 
response mep.

It seems sensible to me that inout operations can be bound to the 
soap-response mep if:
    - the input message is a #none kind of message (I did not found any 
text about this case by the way, I may have missed something)
    - the input message is a #element kind of message with the element 
schema following the IRI style constraints

Does this make sense?

Should we add some text in the specification to clarify this?

Transition history

raised on 22 Nov 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 11 Jan 2007

Agreed, allow #none in addition to IRI style.

Acknowledgment cycle

announced by group on 20 Feb 2007

Action history

CR122: Clarification about ignoreUncited behaviour [link to this issue]

Reading section 6.7.2, I am not entirely sure of the right behaviour of 
the whttp:ignoreUncited property.
Here is my current understanding. Can someone verify and correct it if 
needed?

Input parameters not cited in whttp:location are serialized to build a 
query string.
This query string is then added to the message body or the request IRI

If the operation is POST or PUT, the query string value is serialized in 
the message body, no matter the value of whttp:ignoreUncited.
It is unclear then whether section 6.7.2.2.2 should be considered in 
that case.
If we do consider it, then if ignoreUncited=false, we are requested to 
serialize the data in the request IRI according section 6.7.2.2.3.
This section dealing only with GET/DELETE requests, we can conclude that 
the data is not serialized in the request IRI (?)
The example in section 6.7.2.2.4 follows that rule.
If my understanding is right, then we should maybe clearly state that 
section 6.7.2.2.2 is only applicable to requests that have no body.

If the operation is GET or DELETE, we have two cases:
- If ignoreUncited=false, the query string is serialized in the 
request IRI
- If ignoreUncited=true, the query string is not serialized in the 
request IRI.
In the latter case, part of the input data is not serialized at all in 
the request. Is it the expected behaviour?

Transition history

raised on 7 Dec 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

declined on 11 Jan 2007

Yes, this is the expected behavior. It is possible to bind some XML data in such a way that parts of that data are omitted from the message. It is also possible that this may cause problems in some cases. But adding a constraint about using these features together is somewhat unnatural and may constrain away useful behavior in other cases. WG did not change the spec in response to this issue.

Acknowledgment cycle

announced by group on 11 Jan 2007

CR127: Message Dispatching Primer Section [link to this issue]

Reading section 5.1 in the primer, it is written that assigning unique 
QNames of GED as inputs within the interface of the service is 
sufficient to disambiguate the types of the messages that are received.

While this is certainly true for a typical SOAP service that uses the 
Request/Response mep, this is not the case when the SOAP/Response mep is 
used.
In that case, the GED QName is not sent in the message, only the 
subchildren local names are sent in the url.
It would be easy to have two different GED QNames with the same 
subchildren local names.
I do not know whether we should improve the primer, but this might be 
worth noting it anyway.

The same kind of issue also arises with the HTTP binding.
In this case, the dispatching may be done according the url, the method, 
the content-type and possibly other bits of information.
This flexibility is good if we are going from a service to a WSDL document.
In a typical WSDL first situation, it may however be hard for authors 
and tools to check that message dispatching will never be ambiguous.
A few guidelines may help with that respect.
						

Transition history

raised on 13 Dec 2006 by Youenn Fablet (youenn.fablet@crf.canon.fr)

agreed on 18 Jan 2007

Close with proposal in CR134.

Acknowledgment cycle

announced by group on 1 Feb 2007

CR128: Interface Inheritance Clarification [link to this issue]

I believe a clarification is waranted within part 1: core language re: 
interface inheritance.

The following sentence appears to imply that an interface inherits faults 
and operations from interfaces defined within the extends attribute AND from 
interfaces extended indirectly, i.e. interfaces defined within the extends 
attribute of extended interfaces, etc ...

"To avoid circular definitions, an interface MUST NOT appear as an element 
of the set of interfaces it extends, either directly or indirectly."

The next sentence, however, seems to imply that an interface inherits 
content only from the interfaces listed within its extends attribute:

"The set of operations available in an interface includes all the operations 
defined by the interfaces it extends, along with any operations it directly 
defines. "

If the first supposition is correct, then what is the use case for being 
able to list more than one extended interface within the extends attribute?

Please advise.  Thanks.

Transition history

raised on 14 Dec 2006 by Cindy McNally (cindymcnally_6@hotmail.com)

agreed on 18 Jan 2007

Reword as: "The set of operations available in an interface includes all the operations defined by the interfaces it extends directly or indirectly, together with any operations it directly defines."

Acknowledgment cycle

announced by group on 16 Feb 2007

Action history

CR130: Question on double curly braces with HTTP Location [link to this issue]

Part 2 section 6.7.1.1 which describes the curly brace template syntax used
for {http location} contains the sentence:

"A double curly brace (i.e. "{{" or "}}") MAY be used to include a single,
literal curly brace in the request IRI."

I am a bit confused about why this sentence is here. I assume it is not
describing how to include a literal curly brace within the string enclosed
by matching curly braces in the WSDL because this string must be the local
name of an element, which by definition cannot contain a curly brace.

E.g.   whttp:location="?first={First{{Name}" is meaningless because
'First{Name' is not a valid local name.

So instead it seems to describe how to include a curly brace within the
value substituted for the local name enclosed within matching curly braces
during the construction of the request IRI.

E.g. for whttp:location="?first={FirstName}", FirstName might be substituted
with the value 'Marvin{{' in the request IRI which represents the literal
value 'Marvin{'

Is this correct? If so, does this need to be specified here in Part 2 - it
seems it belongs in the specification that describes how to construct the
message (e.g. HTTP spec for an HTTP request)? If my understanding is
incorrect could someone please explain with some examples.

Transition history

raised on 18 Dec 2006 by John Kaputin (gmail) (jakaputin@gmail.com)

agreed on 18 Jan 2007

httpLocation ::= CharData? (( openBrace | closeBrace | elementName ) CharData?)*
CharData ::= [^{}]*
openBrace ::= '{{'
closeBrace ::= '}}'
elementName ::= '{' NCName '}'

Plus reference to EBNF syntax in XML spec.

Acknowledgment cycle

announced by group on 15 Feb 2007

Action history

CR131: Clarifying assertion for HTTP Location [link to this issue]

Part 2 section 6.7.1.1 Construction of the request IRI using the {http
location} property.

This section contains the assertion:

"Strings enclosed within single curly braces MUST be element names from the
instance data of the input message."

I assume 'input message' here refers generically to any input data for the
HTTP request (i.e. to a WSDL input, output or fault message element).   To
make this clearer and to keep it consistent with the description at
hyperlink "instance data", perhaps you could restate this something like:

"Strings enclosed within single curly braces MUST be element names from the
instance data of the input, output or fault message."

Transition history

raised on 18 Dec 2006 by John Kaputin (gmail) (jakaputin@gmail.com)