Issues regarding the documents produced by the WS Description Working Group should be reported to public-ws-desc-comments@w3.org (public archives).
Comments on this list should be sent to the www-ws-desc@w3.org mailing list (Archives).
id | Status | Spec | Topic | Class | Req | Title |
---|---|---|---|---|---|---|
290 | Active | Discussion of Alternative Schema Languages | Editorial | Typo in http://www.w3.org/TR/2005/NOTE-wsdl20-altschemalangs-20050817/ | ||
289 | Active | RDF Mapping | Design | URIs where we should provide RDF representation |
id | Spec | Req | Topic | Class | Status | Raised By | Owner |
---|---|---|---|---|---|---|---|
issue toplevel element name uniqueness | Part 1 | Design | Closed | Eric Prud'hommeaux | |||
Title: Should all top-level elements' names be unique across the target namespace? | |||||||
Description: Currently names of things like portTypes and bindings are uniquely only across that specific type. That is, one can have a binding called foo and a portType called foo. Should we make these names be unique across the entire document? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved at November 2002 FTF. WSDL 1.2 will retain multiple symbol spaces, one for each top level construct. |
|||||||
issue transition documentation | Both | Editorial | Closed | Jonathan Marsh | |||
Title: Do we need to provide user documentation describing the transition between WSDL 1.1 and WSDL 1.2? | |||||||
Description: If we decide to do so, what form should such documentation take? The removal of operation overloading and advice on how to restructure a WSDL 1.1 file that relies on this feature are an example. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved to add a non-normative appendix detailing the changes from 1.1 to 1.2 |
|||||||
issue add include | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should we add an "include" mechanism? | |||||||
Description: It appears that most users who use <import> really treat it as an include mechanism. Should we bite the bullet and have both import and include mechanisms similar to XSLT? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No include will be added. Issue re-opened. Discussed at November 2002 FTF. Resolved to add a wsdl:include mechanism that works like xs:include sans chameleon behaviour. |
|||||||
issue clarify import | Editorial | Closed | Sanjiva Weerawarana | ||||
Title: Clarify semantics of import. | |||||||
Description: We have run into many, many people who appear to be confused about how import is supposed to work. The notion that it only establishes a relationship between a namespace and a location is quite hard to grasp it appears. Specifically, the fact that nothing is said about what one may find about the namespace at that location appears to be very confusing. We need to clarify the intended semantics at the minimum. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Update the document to completely clarify the intended semantics of <import>. The intended WSDL 1.1 semantics were the same as XSD's import, except with a mandatory location attribute. Sanjiva will ask Jean-Jacques to propose new wording. |
|||||||
issue importing documents in same namespace | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should imports of documents in the same namespace be possible? | |||||||
Description: WSDL 1.1 allows imports to documents in the same namespace. The constraint text: The namespace attribute information item is of type anyURI in the namespace named "http://www.w3.org/2001/XMLSchema". Its actual value indicates that the containing WSDL document can contain qualified references to WSDL definitions in that namespace (via one or more prefixes declared with namespace declarations in the normal way). This value MUST NOT match the actual value of the enclosing WSDL document targetNamespace attribute information item. It MUST be identical to the actual value of the referred WSDL document's targetNamespace attribute information item. in the spec disallows this [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved at November 2002 FTF that wsdl:import will work exactly like xs:import. |
|||||||
issue service type | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should we have an abstract view of a service? | |||||||
Description: WSDL defines a service as a collection of ports, but there is no abstract analog. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Introduced serviceTypes at June 2002 F2F. removed again at September 2002 FTF. |
|||||||
issue multiple services | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should a single WSDL file only define one service? | |||||||
Description: WSDL 1.1 supports having multiple services in a single WSDL file. This has caused confusion amongst users. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Allow multiple services, where each MAY be of a different service type. (At the June F2F.) |
|||||||
issue implements attribute | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should there be an implements attribute on 'service' | |||||||
Description: Currently the {port types} property of the service component is populated via the bindings. Should the service have an implements attribute that lists the port types it implements? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: resolved at November 2002 FTF NOT to add an implements attribute to the service element |
|||||||
issue fault name uniqueness | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should faults be named with QNames? | |||||||
Description: In WSDL 1.1 fault names are NCNames which are not unique within portType even. This leads to a cumbersome mechanism to uniquely identify a fault. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Close issue-fault-name-uniqueness - works just like operations (no change to spec). | |||||||
issue allow nonxml typesystems | part 1 | Design | Closed | September 2002 Face-to-face | |||
Title: Allow non-XML type systems? | |||||||
Description: Do we want to allow WSDL 1.2 to use type systems which are NOT XML based [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: non-XML type systems are allowed via extensibility attributes of message/part elements. |
|||||||
Resolution: Fixed. | |||||||
issue operation patterns | Part 1 | Closed | Prasad Yendluri | ||||
Title: Should more operation patterns be supported? | |||||||
Description: We discussed this briefly at the April F2F (perhaps) but, I think it would be extremely helpful to permit alternate and multiple responses to a request; that is, permit multiple output messages in an operation like we have multiple faults in an operation. It would then be helpful to make them alternate or sequence. That is, do all of them come back or just one of them. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: This issue is closed by leaving it to the realm of orchestration languages and applications. June 11, 2002 (at face-to-face). |
|||||||
issue extensible message exchange patterns | part 1 | Closed | Glen Daniels | ||||
Title: Should we have a mechanism to define extensible message exchange patterns? | |||||||
Description: See http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0271.html [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: This issue is closed on the basis that the open-ended extensibility model we have adopted enables the description of arbitrary message exchange patterns. June 11, 2002 (at face-to-face meeting). Further discussion on this issue occured during the November 2002 FTF. Further discussion on this issue at Jan 2003 FTF. Decided to allow MEPs to be specified by URI. The WG will define a set of MEPs ( probably 6-7 ) |
|||||||
issue require type match for in out parameters | Part 1 | Closed | Jacek Kopecky | ||||
Title: For a part to be an in/out parameter, the type must match. | |||||||
Description: For a parameter to be considered in/out it must also be the case that the parts be of exactly the same type. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Unknown. Issue is closed but no resolution is recorded. May be related to removal of parameterOrder |
|||||||
issue remove parameter order | part 1 | n/a | Design | Closed | Sanjiva Weerawarana | ||
Title: Should we remove parameter order? | |||||||
Description: While parameter order is specified at a portType level, in the SOAP case, whether the binding is an RPC binding or not is not specified until later. Thus, the information is misplaced at best. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved at September 2002 Face-to-face, Alex, VA to remove paramterOrder attribute |
|||||||
issue remove notification operations | Part 1 | n/a | Design | Closed | Sanjiva Weerawarana | ||
Title: Should we remove notification operations? | |||||||
Description: Notification operations are also not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per the 20-22 Jan 2003 face to face meeting, there will be a one-way, output-only MEP. |
|||||||
issue remove solicit response operations | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should we remove solicit-response operations? | |||||||
Description: Solicit-response operations are not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per the 20-22 Jan 2003 face to face meeting, there will be a output-input MEP. |
|||||||
issue operation overloading | Part 1 | Design | Closed | Joyce Yang | |||
Title: Should operation overloading be disallowed? | |||||||
Description: WSDL 1.1 allows overloaded operations- operations with the same name but different messages. If they are to be disallowed then we must require the operation name to be unique within a portType. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Do not allow operation overloading. See minutes for telecon on June 27, 2002 and follow-on email discussion. |
|||||||
issue portType extensibility | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should portTypes be extensible? | |||||||
Description: Some users have asked that portTypes be extensible. We need to carefully consider whether that is a good thing or not. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed. port type extensibility added 20021010. |
|||||||
issue operation name uniqueness | Part 1 | Design | Closed | Steve Tuecke | |||
Title: Need to be able to distinguish between operations with the same NCName in different portTypes | |||||||
Description: It is important that operations within port type be uniquely identifiable. Suggested approachs so far: a) make operations top-level and make their names QNames ( qualified by targetNamespace ) b) Use the port type name as the scope identifier and refer to this somehow from the binding [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Proposal to make operations top-level constructs ( and hence named by QName ) presented at November 2002 FTF |
|||||||
Resolution: resolved at the November 2002 FTF to reject proposal to make operations top-level. All operations of a combined port type MUST have unique local names. |
|||||||
issue clarify type and element | Part 1 | Design | Closed | Keith Ballinger | |||
Title: Clarify use of type= and element= in part with XML Schema experts. | |||||||
Description: The question is whether we can just have element and still retain full abstraction or if not whether we can just have type and live. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] | |||||||
Resolution: Per 18 Dec 03 telecon, noted this issue is obsolete since we now have a single way to indicate the schema construct that describes the 'message'. |
|||||||
issue message parts | Part 1 | Design | Closed | Sanjiva Weerawarana | |||
Title: Should the message part mechanism be extended to support optional parts etc.? | |||||||
Description: In WSDL 1.1, a message can only be defined to be a sequence of parts. It is not possible to indicate that certain parts may be optional, may occur multiple times, etc.? Should we do that? Overlapping with XML Schema's mechanisms is an obvious concern. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: We will consider this for WSDL 2.0 in conjunction with the resolution for issue "issue-eliminate-message." If <message> is retained in WSDL 2.0, then this issue becomes interesting; otherwise it's a non-issue. Per 30 July 2003 meeting in Raleigh, NC, decided to eliminate message construct and use XML Schema (or some other type system) directly. |
|||||||
issue eliminate message | Part 1 | n/a | Design | Closed | Keith Ballinger, Jeffrey Schlimmer, Others | ||
Title: Can we eliminate <message> in favor of a schema mechanism? | |||||||
Description: Using the <message> mechanism to define the structure of a message makes the <message> syntax an alternate infoset defining syntax to XSD in some sense. It would be nice to be able to write message definitions just using XSD and eliminate the <message> mechanism altogether. Continued discussion at November 2002 Face-to-face at Macromedia. Multiple proposals, one to replace message with references to elements/types/named model groups in schema ( Roberto, Jeff, Gudge ) another to move the parts in message inside the input and output elements of port type operations ( Sanjiva, Paco, Joyce ) [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Original resolution: We will consider this for WSDL 2.0. For WSDL 1.2, we will not remove the <message> construct. At 30 July 2003 meeting in Raleigh, NC, decided to remove message and message/part constructs, and replace with interface/operation/input/@body that points to a GED. (Restricts SOAP to a single GED in s:Body.) Replace with interface/operation/input/@headers that point to a list of GEDs. Same for interface/operation/output. interface/operation/fault TBD. Add attribute to operation to indicate whether a set of rules was used when writing the schema as a hint/guide to reconstructing method signatures in proxy code. |
|||||||
issue references with qname | Part 1 | Closed | Sanjiva Weerawarana | ||||
Title: Should intra-namespace references using only localParts be supported? | |||||||
Description: WSDL 1.1 requires all references to be QNames. For example, a reference to a portType from a binding element must always use a QName even if that portType is in the same namespace and even if it is defined in the same document. It would be convenient to support local part references for intra-namespace references. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Update the document to clearly indicate that all references must be with QNames, whether inter-document or intra-document. Sanjiva delegates to Roberto on April 29, 2002. |
|||||||
issue remove optional name of definition | Part 1 | Closed | Sanjiva Weerawarana | ||||
Title: Should we remove the optional name attribute of <definitions>? | |||||||
Description: WSDL 1.1 has an optional attribute on definitions which is defined as being used to provide a lightweight form of documentation. I would like to remove that as it's not clear that that has been useful or used. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Decided to remove during the July 18th telecon. |
|||||||
issue require targetnamespace | Part 1 | Closed | Sanjiva Weerawarana | ||||
Title: Require targetNamespace attribute? | |||||||
Description: WSDL 1.1 indicates that the targetNamespace attribute is optional. I would like to make it required as otherwise the NCNames used in other places don't make much sense. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted during telcon on June 27, 2002. |
|||||||
6e | Part 3 | n/a | HTTP | Design | Closed | Gisle Aas | |
Title: Define behavior for http:urlReplacement "search pattern" with no corresponding named part in message | |||||||
Description: [email] For http:urlReplacement it is not clear what should happen for "search patterns" where there is no correspondingly named part in the message. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Strings enclosed within single curly braces MUST be input message part names; any other strings enclosed within single curly braces are a fatal error. [email] |
|||||||
Resolution: Accepted per 29 May 2003 telecon. |
|||||||
6d | Part 3 | n/a | HTTP | Design | Closed | Gisle Aas | Unassigned |
Title: Define encoding for characters outside ASCII in a request URL | |||||||
Description: [email] For http:urlReplacement it not not clear what URL escaping should be done on the replacement text. - Is an embedded "?" to be expanded into "?" or "%3f". - Is an embedded "%3f" to be expanded into "%3f" or "%253f" [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 13 Feb 2003 teleconference, editors to add text compatible with I18N. |
|||||||
6c | Part 1 | n/a | Design | Closed | Gisle Aas | Unassigned | |
Title: Can a part reference a global element declaration instead of a type | |||||||
Description: [email] Is it legal for the part referenced to reference a schema element instead of a type? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 30 July 2003 meeting in Raleigh, NC, decided to eliminate message construct and have interface/operation/input etc refer directly to global element declarations in XML Schema (and not complexTypes). |
|||||||
6b | Part 3 | n/a | SOAP/HTTP | Design | Closed | Gisle Aas | Unassigned |
Title: Define encoding for characters outside ASCII in a request URL | |||||||
Description: [email] If [the value of abstract type] is xsd:string, then it is unclear how chars outside the ASCII range are to be handled. UTLencoded UTF8 perhaps? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Wait until Charmod goes to REC, if possible, since it contains a pretty strong requirement that W3C specifications "use Internationalized Resource Identifiers (IRI) (or an appropriate subset thereof)." |
|||||||
Resolution: Per 13 Feb 2003 teleconference, editors to add text compatible with I18N. |
|||||||
6a | Part 3 | n/a | SOAP/HTTP | Design | Closed | Gisle Aas | Unassigned |
Title: Define encoding of complex types in a request URL | |||||||
Description: [email] The spec does not say much about how values of abstract types are to be stringified when the type is something else xsd:string. Should it just be stringified as XML (and then URLencoded)? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat, and (somewhat) human readable. |
|||||||
1 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Simon Fell | Unassigned |
Title: How to specify an empty SOAP action | |||||||
Description: [SOAPAction has been deprecated, as of SOAP 1.2] <quote section="3.4 soap:operation"> The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted. <quote> Does this mean the SOAPAction value should include the quotes needed ?, i.e. if you're expecting a SOAP request POST .... SOAPAction: "/foo/bar" do you include the quotes in the soap:operation ?, e.g. <soap:operation soapAction="/foo/bar" /> or not?, if not and the soapAction is mandatory for HTTP bindings, how do you specify that you want an empty SOAPAction header ? e.g. POST .... SOAPAction:[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. No @soapAction will mean no soapaction header. |
|||||||
2 | Part 3 | n/a | HTTP | Design | Closed | Glen Daniels | Unassigned |
Title: Allow SOAPAction for bindings other than SOAP | |||||||
Description: [SOAPAction has been deprecated, as of SOAP 1.2] <quote section="3.4 soap:operation"> The soapAction attribute specifies the value of the SOAPAction header for this operation. This URI value should be used directly as the value for the SOAPAction header; no attempt should be made to make a relative URI value absolute when making the request. For the HTTP protocol binding of SOAP, this is value required (it has no default value). For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted. <quote> It's my opinion that WSDL should not specify the absolute exclusion of the SOAPAction for non-HTTP bindings. What if an SMTP binding wants to use exactly the same URI, but encapsulate it in an "X-SOAPAction" header? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 4 Nov 2003 face-to-face, decided to simplify SOAP binding extension to just <wsoap:action uri="xs:anyURI" />. |
|||||||
3 | Part 1 | n/a | Design | Closed | ? | Unassigned | |
Title: How can arrays be declared? | |||||||
Description: [email] Possibly one of the most talked about parts of WSDL:
[needs review] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Dec 2003 telecon, closed because we don't deal with the SOAP data model or its encoding [email]. | |||||||
4 | Part 1 | n/a | Design | Closed | Matt Long | Unassigned | |
Title: Namespaces | |||||||
Description: [email] I ran across this example at http://www.w3.org/2001/03/14-annotated-WSDL-examples The example is correct but does emphasize a concern. 1) when a part is typed "element" and referenced to schema 2) and the binding's soap:body "namespace" attribute is used Spec reads Section 3.5 ...although the namespace attribute only applies to content not explicitly defined by the abstract types. ... A case becomes present where the namespace attribute can be declared and the element's namespace *is* explicitly declared by the targetNamespace of the schema (assuming XSD) which is the namespace to be used and *NOT* the text of the soap:body namespace attribute. However, if the schema was non-XSD *and* no targetNamespace (or such) could be isolated, the value of the namespace would default to the "namespace" attribute. This seems confusing and it would seem in the interests of best practices to either 1) declare the namespace attribute of the soap:body element equal to the intended namespace or 2) omit the namespace attribute *if* the element is explictly declared in schema. (I would think (1) would clear any garbled confusion in either case). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
5 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Rine Holt | Unassigned |
Title: Encoding Style | |||||||
Description: [email] SOAP defines EncodingStyle as being scoped at the element + child level [the same as namespaces], meaning that a single SOAP message may contain different parts with different encoding styles, but in WSDL this is scoped at the message level, i.e. the whole message uses a particular encoding style, so there are potential SOAP messages that can't be modelled in WSDL. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: email Allow encodingStyle to be specified on each message block (and also fault detail) but not their descendants, i.e. each block has a single encodingStyle |
|||||||
7 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Jeff Lansing | Unassigned |
Title: Example incorrectly uses xsd:binary | |||||||
Description: [email] The sample in section 4.1 of the spec uses xsd:binary which doesn't exist, its not clear what the correct type to use in its place would be. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed example; rewrite in primer. |
|||||||
8 | Part 1 | n/a | Editorial | Closed | Kevin Liu | Unassigned | |
Title: Inconsistency in definition of attribute extensibility | |||||||
Description: [email] In section 2.1, extensibility is expilictly stated for all the elements, but not for attributes. In the WSDL Schema, PartType is extended from "openAtts". This means anyAttributes can be defined in addition to the three optional attributes specified for Part (name, type, element). Though it mentions in section 2.3 that "other message-typing attributes may be defined as long as they use a namespace different from that of WSDL", it would be better for those who use the grammar as a convenient reference if this is also reflected in section 2.1. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] | |||||||
Resolution: Per 18 Dec 03 telecon, same description for attribute and children extensibility; neither in pseudo syntax to minimize clutter. |
|||||||
9 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Gisle Aas | Unassigned |
Title: Example misses "Soap" | |||||||
Description: [email] In example 1 of WSDL 1.1 (2001-03-15) the binding reference from the port does not resolve because of a typo. The binding name should be: tns:StockQuoteSoapBinding The example is missing "Soap" in there. Simon Fell also notes that examples 2,4 and 5 have the same problem. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed example; rewrite in primer. | |||||||
10 | Part 1 | n/a | Editorial | Closed | Gisle Aas | Unassigned | |
Title: Example 3 element order bug | |||||||
Description: [email] [see also issue 43] In example 3 the <types> element comes after <service>. This is not allowed according to the WSDL schema (A 4.1) or the grammar in section 2.1. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed example; rewrite in primer. |
|||||||
11 | Part 1 | n/a | Editorial | Closed | Giles Aas | Unassigned | |
Title: Bug in grammar for <import> | |||||||
Description: [email] According to the schema in section A-4.1 the <import> element might take an subordinate documentation element. The grammar in section 2.1 ought to be changed to say: <wsdl:import namespace="uri" location="uri"> * <wsdl:documentation .... />? </wsdl:import> In WSDL 1.1 (2001-03-15) it simply says. <import namespace="uri" location="uri"/>* The namespace qualifier for <import> is also missing in the current text. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Obsolete pseudo grammar. | |||||||
12 | Part 1 | n/a | Editorial | Closed | Gisle Aas | Unassigned | |
Title: Bug in schema for "part" attribute | |||||||
Description: [email] [see also issue 20] According to the schema in section A-4.1 the 'name' attribute of <part> is optional. This is not indicated in the grammar in section 2.1 and section 2.3. Section 2.3 also states that "The part _name_ attribute provides a unique name among all the parts of the enclosing message". I believe the schema is wrong and that the definition of "partType" should be changed to: <complexType name="partType"> <complexContent> <extension base="wsdl:openAtts"> <attribute name="name" type="NMTOKEN" use="required"/> <attribute name="type" type="QName" use="optional"/> <attribute name="element" type="QName" use="optional"/> </extension> </complexContent> </complexType>[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 30 July 2003 meeting in Raleigh, NC, decided to remove message and message/part construct. |
|||||||
13 | Part 1 | n/a | Editorial | Closed | Jacek Kopecky | Unassigned | |
Title: Parameter Order missing from schema | |||||||
Description: [email] This is an editorial issue for WSDL 1.1 - the schema doesn't declare the parameterOrder attribute. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed @parameterOrder. |
|||||||
14 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Glen Daniels | Unassigned |
Title: Request to support SOAP features | |||||||
Description: [email] At present, it is possible with WSDL 1.1 to specify particular headers which should be included with particular messages. This was, I believe, a reasonable first stab at integrating headers with a description language, but it falls far short of being able to support the kind of rich semantic additions that are going to be coming down the line as SOAP extensions over the next few months/years. Without going into too much detail, I'd like to see us require the ability to specify that a particular SOAP "module" is offered by, or required by, particular services or operations. SOAP 1.2 (part 1, sec 3) discusses the concept of SOAP "features", which are semantic extensions named with a URI and implemented by either SOAP extensions (headers) or bindings. Bindings already have a requirement for URI naming, and I'm attempting to push for extensions to do the same. Once we have URIs for such things, it becomes possible to say something like "this operation supports the 'http://www.w3.org/2002/06/reliable-message' extension", which would imply some set of headers/exchanges mandated by that specification. It's unclear to me as to whether we would require a schema description of every possible header which such an extension might produce, but that's another facet of this which we should discuss. This is also a potentially complex issue in that it gets into situations where messages that are not actually specified directly in the WSDL may become part of the exchange due to the extension specs, but I think we need to figure this stuff out if we hope to live in a world with true "orthogonal extensibility" and some hope of negotiation/interop. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Dec 2003 telecon, noted that features and properties are currently included in the draft [email]. |
|||||||
15 | Part 1 | n/a | Design | Closed | Graham Glass | Unassigned | |
Title: Missing <document> tag for operation arguments | |||||||
Description: [email] I'd like to see changed with the WSDL specification is the ability to add <documentation> tags to a <part>. right now, you can't officially comment arguments to an operation, which seems like an error. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] | |||||||
Resolution: Per 18 Dec 03 telecon, noted that we now allow documentation everywhere. |
|||||||
16 | Part 1 | n/a | Editorial | Closed | Simon Fell | Unassigned | |
Title: Does a binding have to specify all the operations in a portType? | |||||||
Description: [email] Does a binding have to specify all the operations in a portType ? I thought not, but i can't spot anything in the spec that says one way or the other. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Fixed. |
|||||||
17 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Simon Fell | Unassigned |
Title: nowhere to specify actor URI in WSDL ? | |||||||
Description: [email] [s/actor/role/, as of SOAP 1.2] Is there anyway to specify the actor URI for a header in WSDL, i can't spot anything ? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: As described in proposal above, with minor amendments from Gudge and Jonathan. |
|||||||
18 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Gisle Aas | Unassigned |
Title: Default for transport of <soap:binding> | |||||||
Description: [email] [see also issue 46] The _transport_ attribute of <soap:binding> is optional, but it is not clear to me what the default is. Is "http://schemas.xmlsoap.org/soap/http" the default? If so, shouldn't the schema in section A-4.1 declare this value as the default? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: soap:transport is mandatory |
|||||||
19 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | David Cleary | Unassigned |
Title: Inconsistency on optionality of 'soap:headerfault' | |||||||
Description: [email] Section 3.7 of the WSDL spec states that soap:headerfault elements are optional, but they aren't in the schema both in the spec and at http://schemas.xmlsoap.org/wsdl/soap/. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten. |
|||||||
20 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | David Cleary | Unassigned |
Title: Inconsistency in definition of 'soap:header' (contains 'part' or 'parts'?) | |||||||
Description: [email] [see also issue 12] Section 3.7 of the WSDL spec states that the soap:header and soap:headerfault elements take a required 'part' attribute of type NMTOKEN, but the schema in the spec and at http://schemas.xmlsoap.org/wsdl/soap/ state that the attribute is 'parts' and of type NMTOKENS. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Header now points directly to Schema. |
|||||||
21 | Part 1 | n/a | Design | Closed | Jean-Jacques Moreau | Unassigned | |
Title: Examples use <import> elements inconsistenly | |||||||
Description: [email] In most places, the <import> element seem to correspond to a #include directive, for example in section 2.1.2 stockquoteservice.wsdl example. This does not seem to be the case for the stockquote.wsdl example in the same section. If the <import> element in that section was equivalent to a #include directive, the schema stockquote.xsd would be included as is, and there would be a missing surrounding <types> element. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Remove example; rewrite in primer. |
|||||||
22 | Part 1 | n/a | Editorial | Closed | Jean-Jacques Moreau | Unassigned | |
Title: Specification not XML Infoset based | |||||||
Description: [email] Currently, the specification is not XML Infoset based. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Fixed. |
|||||||
23 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Jean-Jacques Moreau | Unassigned |
Title: Request to support SOAP 1.2 | |||||||
Description: [email] Does WSDL 1.1 support the new SOAP 1.2 (graph) data model, encoding and RPC convention? Does it support the new SOAP 1.2 transport binding framework, and revised extensibility model (features)? More generally, does it support all of SOAP 1.2? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Dec 2003 telecon, decided to split this into separate issues. See new issues 99, 100, and 101. |
|||||||
24 | Part 1 | n/a | Design | Closed | Waqar Sadiq | Unassigned | |
Title: Real difference between literal vs. encoded? | |||||||
Description: [email] [see also issue 25] The second issue that has been confusing to me is the literal vs. encoded. I think that WSDL specification should take it upon itself to clarify the issue clearly. I am sure that some people out there truly understand the difference but I am sure ther is a great deal of confusion about this also. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Original resolution: Removed @use. @encodingStyle is a hint about how types/schema was generated. Reopened by Macromedia\Tom at telecon prior to 30 July 2003. Per 18 Dec 03 telecon, noted that SOAP encoding can be used via some other, to-be-invented schema language in the current design. (See new issue 97.) |
|||||||
25 | Part 1 | n/a | Design | Closed | Jacek Kopecky | Unassigned | |
Title: Unclear relationship between XML Schema and SOAP data model | |||||||
Description: [email] [see also issue 24] WSDL 1.1 uses XML Schema to describe data in, for example, SOAP 1.1 encoding. XML Schema is not really good at describing graph data model strictly, therefore WSDL 1.1 has the "encoded" use of schemas but it does not specify concretely how schemas are dealt with. If we want to keep "encoded" use, IMHO we'll have to specify how XML Schema schemas are understood in connection with SOAP data model. AFAIK, this has been a big interop issue. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed @use. @encodingStyle is a hint about how types/schema was generated. |
|||||||
26 | Part 2 | n/a | Design | Closed | Herve Ruellan | Unassigned | |
Title: Replace transmission primitives by MEPs in operation | |||||||
Description: [email] [See also issue 35-36] _Background_ Currently WSDL 1.1 defines 4 transmissions primitives (one-way, request-response, solicit-response, notification). SOAP 1.2 defines the concept of Message Exchange Pattern (MEP) [1]. A MEP is a template for the exchange of messages between SOAP Nodes. _Issue_ In its current state, WSDL 1.1 is not able to define which MEP a Web Service will use over a SOAP binding (several different MEP can define a one-way transmission primitive). _Proposed solution_ As MEP are almost independant of SOAP 1.2, I would suggest replacing transmission primitives by MEP. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Dec 2003 telecon, decided to close given Part 2 of the spec [email]. |
|||||||
27 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Herve Ruellan | Unassigned |
Title: Remove 'style' attribute, which no longer works for SOAP 1.2 | |||||||
Description: [email] _Background_ In SOAP 1.2, RPC is an extension of SOAP, that is a particular use of SOAP. _Issue_ Regarding SOAP 1.2, the style attribute can only be seen as a hint that SOAP 1.2 is used with *an* RPC extension. It does not specify which RPC extension is used nor any other important informations like which encoding is used for the parameters... _Proposed solution_ Remove the style attribute and create a way for defining which SOAP extensions are used (see below). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: At 22 Sep 2003 meeting in Palo Alto, CA decided to resolve per 31 July 2003 meeting. Per 31 July 2003 meeting in Raleigh, NC, removed @style from SOAP binding; defined an attribute on operation that may be used to indicate that a set of rules was used when constructing the XML Schema for the Body. |
|||||||
28 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Herve Ruellan | Unassigned |
Title: 'transport' cannot fully describe underlying SOAP 1.2 protocol binding | |||||||
Description: [email] _Background_ A SOAP 1.2 message can be transfered over many protocols. SOAP 1.2 defines bindings for specifying use of underlying protocols. For example [2] describes *an* HTTP binding for SOAP 1.2. _Issue_ The transport attribute allows to define which binding is used for a Web Services accessed over SOAP 1.2. However this attribute may be ill named (there may exists several bindings for a particular transport) and it does not allow specifying which options of a binding are used. _Proposed solution_ Use the soap:binding element to define which binding is used and [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete - already have provided the protocol attribute. |
|||||||
29 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Herve Ruellan | Unassigned |
Title: How to specify the structure and ordering of 'soap:body' parts | |||||||
Description: [email] Background_ Currently WSDL 1.1 says that the parts attribute indicates which message parts appear somewhere within the SOAP body. Other parts may appear in other locations (such as attachements). _Issue_ WSDL 1.1 does not specify the precise structure of the body (are the parts allowed to appear in any order, may they be contained in element information items descendant of the body...). In addition, it does specify nothing for the parts not transmitted in the body. _Proposed solution_ Have WSDL 1.1 define in a precise way the structure of the SOAP body. Give some directives for specifying in a Web Services description what happen to the parts not transmitted in the body (is it possible to not transmit them...). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete - parts are gone. |
|||||||
30 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Herve Ruellan | Unassigned |
Title: soap:body encodingStyle | |||||||
Description: [email] [Child aspect already covered by issue 5] _Background_ In WSDL 1.1, the encodingStyle attribute is a list of uri. In SOAP 1.2, the encodingStyle attribute is an uri. Moreover, an element can use an encodingStyle while some of its children use another encodingStyle. (Note: the usage of the encodingStyle attribute is being discussed currently and may differ in the final version of SOAP 1.2). _Issue_ WSDL 1.1 and SOAP 1.2 does not have the same use of the encodingStyle attribute. _Proposed solution_ Change the WSDL 1.1 use of the encodingStyle attribute. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: email Restrict the value of the encodingStyle attribute to be either empty (for literal) or a single URI (for encodings like SOAP encoding). |
|||||||
31 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Herve Ruellan | Unassigned |
Title: 'soap:address' insufficient to describe SOAP 1.2 endpoint | |||||||
Description: [email] _Background_ WSDL 1.1 uses the soap:address element to specify the destination of the message. _Issue_ The way of targetting a WSDL message through SOAP 1.2 is dependant on the binding used and may also depend on the MEP used. The soap:address element may not be sufficient to describe this targetting. _Proposed solution_ The target of a WSDL message should be defined in the soap:binding element. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. |
|||||||
32 | SOAP 1.1 Binding | n/a | Design | Closed | Jean-Jacques Moreau | Unassigned | |
Title: Will SOAP 1.1 still be supported? | |||||||
Description: [email] Should this new version of WSDL have backward compatibility support for SOAP 1.1, or just support SOAP 1.2? More generally, should it have support for individual version of SOAP and other protocols? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Yes, we will provide a SOAP 1.1 binding (Note). |
|||||||
33 | Part 1 | n/a | Design | Closed | Waqar Sadiq | Unassigned | |
Title: Distinction between RPC style and document style | |||||||
Description: [email and email] I do believe strongly that this distinction between RPC style and document style is quite misleading. The reason I think the issue becomes relevant to WSDL is that most users will not be exposed to SOAP or will not quite understand SOAP. Interface description language is what is viewed as the contract and the underlying protocol becomes part of the solution. From my own experience, I kept on happily ignoring the distinction between the two. The document style was meaningless to me. I became more aware of the issue when I used somebody else's WSDL that indicated document style and ran into some incompabilities. So even if we cannot consolidate those two styles, should we atleast make an attempt to a) raise awareness of this issue and possibly put it in front of the relevant group and b) possibly provide some guidance and explanation in the primer or some other non-normative documents. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 31 July 2003 meeting in Raleigh, NC, decided to eliminate separate styles in SOAP binding and use attribute on operation to indicate whether a set of rules was used when writing the schema as a hint/guide to reconstructing method signatures in proxy code. |
|||||||
34 | Part 1 | n/a | Design | Closed | Sanjiva Weerawarana | Unassigned | |
Title: Should portTypes be extensible? | |||||||
Description: [email] Some users have asked that portTypes be extensibile. We need to carefully consider whether that is a good thing or not. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
35 | Part 1 | n/a | Design | Closed | Sanjiva Weerawarana | Unassigned | |
Title: Should we remove solicit-response operations? | |||||||
Description: [email] [See also issue 26] Solicit-response operations are not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc.. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
36 | Part 1 | n/a | Design | Closed | Sanjiva Weerawarana | Unassigned | |
Title: Should we remove notification operations? | |||||||
Description: [email] [See also issue 26] Notification operations are also not fully defined in WSDL 1.1. There are multiple interpretations of these in the community: event, callback etc.. Also, there is little evidence that anyone is actually using them. We could consider replacing this with a first-class description of an event mechanism. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
37 | Part 1 | n/a | Design | Closed | Sanjiva Weerawarana | Unassigned | |
Title: Should we remove parameter order? | |||||||
Description: [email] [See also issue 13] While parameter order is specified at a portType level, in the SOAP case, whether the binding is an RPC binding or not is not specified until later. Thus, the information is misplaced at best. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
38 | Part 1 | n/a | Editorial | Closed | Sanjiva Weerawarana | Unassigned | |
Title: Clarify the what kinds of extensibility elements go where. | |||||||
Description: [email] There is confusion in the user community about what should go in a binding vs. a port vs. a service in terms of extensibility. An approach could be to that data marshalling type extensions go in a binding and transport stuff goes in to a port and anything else goes into a service. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: email | |||||||
39 | Part 1 | n/a | Design | Closed | Arthur Ryman | Unassigned | |
Title: Binding Extensions Depend on the Structure of the portType | |||||||
Description: [email] The portType is supposed to represent the abstract interface of a service without reference to how the service is accessed. However, the current design couples the binding extensions with the structure of the portType making it necessary to define a separate portType for each binding extension. SOAP RPC Style, SOAP Document Style, and HTTP GET or PORT each require specific structure in the portType, yet all can be used to access the same logical service. It is useful to provide HTTP GET and POST endpoints for a service in addition to a SOAP/HTTP endpoint. Each endpoint should provide access to the same underlying service. It is therefore reasonable to expect that each endpoint should be bound to the same portType. The portType should be an abstract definition of the interface of the service. The bindings should describe how to access the service using a given protocol. However, the binding extensions for HTTP GET and POST are not defined in a way that allows them to use the same portType as SOAP/HTTP. To work around this problem, an additional, but semantically equivalent portType, must be defined. [see email above for examples] Potential Solutions * Expand the definitions of the binding extensions so they can be applied to any portType. For example, in the HTTP GET or POST bindings, define how the response is generated from a message that has several parts. * Eliminate message definitions and instead define portTypes directly in terms of XML Schema types. Use XPath to bind parts of the schema to the protocol. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: At the 22 Sep 2003 meeting in Palo Alto, CA, decided to resolve per 30-31 July 2003 meeting. At the 30-31 July 2003 meeting in Raleigh, NC, decided to eliminate message and eliminate the different binding styles for SOAP. |
|||||||
40 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Arthur Ryman | Unassigned |
Title: The binding extension for SOAP is defined in terms of features that interact in a complex way | |||||||
Description: [email] The binding extension for SOAP depends on the following features: * The message part XSD style, either type or element. * The SOAP style, either RPC or Document. * The encoding style, either literal or encoded. * The direction of the message, either input or output. Since each of these four properties has two values, there are a total of sixteen possible combinations. The text of the WSDL 1.1 specification should be clearer about how these properties interact and which combinations are valid since not all seem to be. Each combination should be enumerated and described clearly, and illustrated with an example. It is important to establish the validity and interpretation of each combination in order to improve interoperability between vendors. For example, the current version of WebSphere Studio creates services that use literal encoding in RPC style, but the current version of Microsoft Visual Studio .NET does not support the generation of Web references to that type of service. It is not clear whether this restriction is based on a belief that the combination is not valid, or is simply a prioritization of function delivery. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: At 22 Sep 2003 meeting in Palo Alto, CA, decided to resolve as per 30-31 July 2003 meeting. At the 30-31 July 2003 meeting in Raleigh, NC, we decided to eliminate the message construct and use only elements directly; we also decided to eliminate the style mechanism in the SOAP binding; we have previously decided to eliminate the use of SOAP encoding. |
|||||||
41 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Arthur Ryman | Unassigned |
Title: Define encoding of attributes in a request URL | |||||||
Description: [email] [see also issue 6] In WSDL 1.1 it is possible to defined an input message part that is a complex XML schema type. [see email above for example] The WSDL 1.1 specification does not explicitly describe how to URL encode complex types, but a reasonable interpretation is to use the serialized content as a the query string value. For example, suppose an input message has a part named employee of type PersonType. This part would be passed in a query string as: employee=<name>John Doe</name><birthdate>1960-01-01</birthdate> Now suppose that PersonType had an attribute named sex. [see email above for example] How would this be passed in a query string? Clearly the WSDL 1.1 is silent on this topic. The WSDL 1.1 specification should either explicitly disallow attributes, or should define some serialization that can be used with URL encoding, e.g. prefix the content with a comma-separated list of attribute values enclosed in square brackets: employee=[sex(male)]<name>John Doe</name><birthdate>1960-01-01</birthdate> [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 13 Feb 2003 teleconference, leave HTTP request URLs segmented, flat, and (somewhat) human readable. |
|||||||
42 | Part 1 | n/a | Design | Closed | Kevin Liu | Unassigned | |
Title: Shall "element" attribute of "part" only refer to elements defined in schema? | |||||||
Description: [email] In section 2.3 Messages, it states: " WSDL defines several such message-typing attributes for use with XSD: *element. Refers to an XSD element using a Qname. *type. Refers to an XSD simpleType or complexType using a Qname." While in the section 3.1 example 4 and example 5, element is used as follow: <message name="GetTradePriceInput"> <part name="tickerSymbol" element="xsd:string"/> <part name="time" element="xsd:timeInstant"/> </message> References: Section 2.3 Message Section 3.1 SOAP Examples [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: email | |||||||
43 | Part 1 | n/a | Editorial | Closed | Kevin Liu | Unassigned | |
Title: Does order matter for the child elements of "definitions"? | |||||||
Description: [email] [see also issue #10] Section 3.1 SOAP Examples, example 3 lists <types> as the last element under <definitions>. This is inconsistent with the schema where <type> is defined as the second of the sequenced elements of the "definitionsType"; similar issue with section 4.1 HTTP GET and POST Binding example 6 where <binding> is put after <service> References: Section 3.1 SOAP Examples, example 3 Section 4.1 HTTP GET and POST Binding example 6 A 4.1 WSDL Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: email | |||||||
44 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Kevin Liu | Unassigned |
Title: "name" attribute of "soap:fault" is not defined in schema | |||||||
Description: [email] Section 3.6 sopa:fault grammar indicates that fault has a required name attribute while in the schema no such attribute defined for faultType References: Section 3.6 soap:fault A 4.2 SOAP Binding Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten. |
|||||||
45 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Kevin Liu | Unassigned |
Title: "use" attribute of "fault" should be optional | |||||||
Description: [email] Section 3.6 soap:fault grammar indicates that the use attribute of fault is required while in the schema use is defined as optional References: Section 3.6 soap:fault A 4.2 SOAP Binding Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved at the 22 Sep 2003 consistent with prior decision to eliminate the use of SOAP encoding. |
|||||||
46 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Kevin Liu | Unassigned |
Title: "transport" attribute of "soap:binding" should be optional | |||||||
Description: [email] [see also issue 18] Section 3.3 sopa:binding grammar and the SOAP binding schema both indicate that the transport attribute of binding is optional while in the text, it is "required" References: Section 3.3 soap:binding A 4.2 SOAP Binding Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten. |
|||||||
47 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Kevin Liu | Unassigned |
Title: "soap:operation" should be optional | |||||||
Description: [email] Section 3.4 soap:operation grammar indicates that the operation is optional. In the text of the same section, it also states that "For other SOAP protocol bindings, it MUST NOT be specified, and the soap:operation element MAY be omitted." However, in the SOAP Binding schema, no value is specified for minOccur/maxOccur. It implies that this element is required. References: Section 3.4 soap:operation A 4.2 SOAP Binding Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Schema is obsolete and will be completely rewritten. |
|||||||
48 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Kevin Liu | Unassigned |
Title: "use" attribute of "soap:body" should be optional | |||||||
Description: [email] Section 3.5 soap:body grammar and the SOAP binding schema both indicate that the use attribute of soap:body is optional while in the text, it is "required" References: Section 3.3 soap:binding A 4.2 SOAP Binding Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved at the 22 Sep 2003 consistent with prior decision to eliminate the use of SOAP encoding. |
|||||||
49 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Kevin Liu | Unassigned |
Title: Inconsistency in "soap:header" specification | |||||||
Description: [email] Section 3.7 sopa:header and soap:headfault grammar indicates that there can be 0 or more <soap:header> element while in the schema no minOccur/maxOccur specified for <soap:header> which means there can be exactly one occurrence References: Section 3.7 sopa:header and soap:headfault A 4.2 SOAP Binding Schema [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Fixed. |
|||||||
50 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Kevin Liu | Unassigned |
Title: SOAP examples declare arrays using an obsolete schema syntax | |||||||
Description: [email] Inheritance rules have been changed since 2000/10 version XML schema. It requires that everything must be re-stated to be inherited. In section 3.1 SOAP Examples (example 5) and section 5.11 MIME Binding example (example 7), array declaration still follows old rules. See Appendix A for more details. References: Section 3.1 SOAP Examples (example 5) Section 5.11 MIME Binding example (example 7) [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed example; rewrite in primer. |
|||||||
51 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Kevin Liu | Unassigned |
Title: Asymmetry between soap:body and soap:header | |||||||
Description: [email] This issue can be viewed as an example our observation that the binding extension specification is not clearly documented and not sufficient. Section 3.5 states that "The soap:body element specifies how the message parts appears inside the SOAP Body element. ... provides information on how to assemble the different message parts inside the Body element if the SOAP message ". Section 3.7 states that "the soap:header and soap:headerfault elements allows header to be defined that are transmitted inside the Header element of the SOAP Envelope. It is patterned after the soap:body element ". These statements imply that it should be similar to assemble different message parts inside SOAP message body and message header. However, the attributes of these two elements are quite different and the usage of the word "part(s)" and "message" is very confusing to many readers. The grammar section lists these elements as below: <soap:body parts="nmtokens"? use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?> <soap:header message="qname" part="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?>* <soap:headerfault message="qname" part="nmtoken" use="literal|encoded"encodingStyle="uri-list"? namespace="uri"?/>* <soap:header> The text about parts attribute of soap:body reads as "The optional parts attribute of type nmtokens indicates which parts appear somewhere within the SOAP Body portion of the message (other parts of a message may appear in other portions of the message such as when SOAP is used in conjunction with the multipart/related MIME binding). If the parts attribute is omitted, then all parts defined by the message are assumed to be included in the SOAP Body portion". Here it's very hard to understand if "part" refer to the WSDL message part or the SOAP message part, also it's hard to understand if it's talking about WSDL message or SOAP message. There is no explanation about: * Why does soap:header need to have the "message" and "part" attributes while soap:body can be bound to a particular input/output message? * Is it intended to allow part from other messages to be incorporated into the SOAP header? Then what is the meaning of grouping parts into a message? * Why does not soap:header allow more than one part per message while in soap:body "parts" attribute can be a list of WSDL message parts? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Fixed. | |||||||
52 | Part 3 | n/a | HTTP | Design | Closed | Paul Prescod | Unassigned |
Title: Allow operation addresses to be absolute | |||||||
Description: [email] operation addresses should not be required to be relative [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Closed without action: Can be achieved by putting one operation per interface and bind the interface to a uri. |
|||||||
53 | Part 3 | n/a | HTTP | Design | Closed | Paul Prescod | Unassigned |
Title: Allow operations within a binding to use different HTTP methods | |||||||
Description: [email] each operation in a binding should choose its own method, not one for all [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Define http:operation/@verb. |
|||||||
Resolution: Incorporated per [Rennes Meeting]. |
|||||||
54 | Part 3 | n/a | HTTP | Design | Closed | Paul Prescod | Unassigned |
Title: Allow binding to any HTTP method | |||||||
Description: [email] any HTTP method should be allowed [in the HTTP binding] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/20/2004 FTF. Extensibility in the HTTP method will be provided per the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html, with the amendment that the default media type will be x-www-url-encoded. |
|||||||
55 | Part 3 | n/a | HTTP | Design | Closed | Paul Prescod | Unassigned |
Title: Define binding to HTTP headers | |||||||
Description: [email] need a way to set HTTP headers [in the HTTP binding] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/20/2004 FTF. |
|||||||
56 | Part 3 | n/a | HTTP | Design | Closed | Paul Prescod | Unassigned |
Title: Define means to specify an authentication requirement | |||||||
Description: [email] need a way to specify an authentication requirement [in the HTTP binding] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/20/2004 FTF. See resolution of issue 165. |
|||||||
57 | Part 1 | n/a | Design | Closed | Prasad Yendluri | Unassigned | |
Title: Should Operations permit alternate and multiple responses? | |||||||
Description: [email] We discussed this briefly at the F2F (perhaps) but, I think it would be extremely helpful to permit alternate and multiple responses to a request. That is permit multiple output messages in an operation like we have multiple faults in an operation. It would then be helpful to make them alternate or sequence. That is, do all of them come back or just one of them. This is perhaps a suggestion for new functionality. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: email | |||||||
58 | Part 3 | n/a | MIME | Design | Closed | Prasad Yendluri | Unassigned |
Title: Permit "message" attribute in mime:content binding? | |||||||
Description: [email] The <mime:content> is defined with a "part" and a "type" attribute spec. E.g. <output> .. <mime:part> <mime:content part="docs" type="text/html"/> </mime:part> </output> I think it would be very useful to permit the part to come from a different message just as it is done with the <soap:header > binding. Like <mime:content message = "tns:rnheaders" part="serviceHdr" type="text/xml"/> [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: MIME Binding outside the scope of our charter, closing issue with no action. |
|||||||
59 | Part 3 | n/a | MIME | Editorial | Closed | Prasad Yendluri | Unassigned |
Title: MIME Binding permits 0 parts in multipart/related | |||||||
Description: [email] A 4.4 MIME Binding Schema permits "zero" parts in multipart/related. <element name="multipartRelated" type="mime:multipartRelatedType"/> <complexType name="multipartRelatedType" content="elementOnly"> <element ref="mime:part" minOccurs="0" maxOccurs="unbounded"/> </complexType> This is not legal. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: MIME Binding outside the scope of our charter, closing issue with no action. |
|||||||
60 | Part 3 | n/a | SOAP/HTTP | Editorial | Closed | Prasad Yendluri | Unassigned |
Title: Inconsistency regarding optional parts | |||||||
Description:
[email]
The examples in Section 5.11 clearly see the need for parts being optional. However since decided that parts in messages will not be permitted to be optional, we need to fix the examples. Example 7 carries in its description: The response contains multiple parts encoded in the MIME format multipart/related: a SOAP Envelope containing the current stock price as a float, zero or more marketing literature documents in HTML format, and an optional company logo in either GIF or JPEG format. However, neither the abstract level definitions nor the concrete bindings shown make the parts (attachments) optional. Specifically the "optional" company-logo nor the marking literature (zero or more => optional w/ cardinality) are really not optional. We need to fix the examples accordingly. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Primer will contain new examples. | |||||||
61 | Part 3 | n/a | SOAP/HTTP | Design | Closed | David Orchard | Unassigned |
Title: Additional SOAP binding for HTTP GET-in/SOAP-out | |||||||
Description: [email] I, and I think the TAG, agree with having a WSDL definition for a HTTP GET-in/SOAP out binding that is orthogonal to the SOAP POST binding. Could this be added to the WSDL issues list, as it sounds like you are in agreement as well. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed at 5/21/2004 FTF. |
|||||||
62 | Part 3 | n/a | SOAP/HTTP | Design | Closed | James Snell | Unassigned |
Title: Specify a specific SOAP fault code to be returned | |||||||
Description:
[email]
At a recent SOAPBuilders interop forum, we discussed the current WSDL SOAP bindings lack of being able to specify the specific fault codes that may be thrown by the various operations. For example, given the following WSDL 1.1 snippet, we can tell that a fault can be thrown, but we have no idea what specific faultcodes we should expect. <operation name="doWapSheDangDang"> <soap:operation ... /> <input>...</input> <output>...</output> <fault name="fault-name"> <soap:fault name="fault-name" use="encoded" encodingStyle="..." namespace="..." /> </fault> </operation> The soap:fault element "specifies the contents of the contents of the SOAP Fault Details element", it says absolutely nothing about the fault code. There needs to be a mechanism that allows one to specify the fault codes that may be thrown. The service would be allowed to throw fault codes other than those listed, however. Just one possible way of addressing this... (I'm sure ya'll could come up with a better one) <operation name="beBoppaLooLa"> <soap:operation ... /> <input>...</input> <output>...</output> <fault name="fault-name"> <soap:fault code="server.unauthorized" name="fault-name" use="encoded" encodingStyle="..." namespace="..." /> <soap:fault code="custom.invalidWhatchamagig" ... /> </fault> </operation>[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete, ability to specify code/subcodes has already been added. |
|||||||
63 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Prasad Yendluri | Unassigned |
Title: SOAP binding violates separation of abstract definitions concrete bindings | |||||||
Description: [email] Section 2.3 (Messages) of WSDL spec permits defining parts of a message using either "type" or "element" attribute: <definitions .... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions> Section '2.3.2 Abstract vs. Concrete Messages' also states: Message definitions are always considered to be an abstract definition of the message content. A message binding describes how the abstract content is mapped into a concrete format. However, section '3.5 soap:body' in the SOAP bindings section requires that the parts be defined using the "type" if the "use" is "encoded": The required use attribute indicates whether the message parts are encoded using some encoding rules, or whether the parts define the concrete schema of the message. If use is encoded, then each message part references an abstract type using the type attribute. These abstract types are used to produce a concrete message by applying an encoding specified by the encodingStyle attribute. If use is literal, then each part references a concrete schema definition using either the element or type attribute. No explanation is given why the parts need to be defined using "type" if "use" is "encoded". The SOAP binding scheme is therefore requiring that things be defined in a particular way at the abstract level, violating the separation of abstract definitions and applying multiple concrete bindings to the same abstract level definitions. We should either remove the restriction or clearly state why this restriction needs to be there. No justification is provided in the spec for this, other than simply having one statement that calls for it. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved per 30-31 July 2003 meeting at the 22 Sep 2003 meeting in Palo Alto, CA. At the 30-31 July 2003 meeting in Raleigh, NC, we decided to eliminate the message construct and use only elements directly; we also decided to eliminate the style mechanism in the SOAP binding; we have previously decided to eliminate the use of SOAP encoding. |
|||||||
64 | Part 3 | n/a | HTTP | Design | Closed | Mark Baker | Unassigned |
Title: Operations and HTTP verbs | |||||||
Description:
[email]
I believe that the distinction that WSDL 1.1 makes about operations and HTTP verbs, is misleading. In particular, it adds to the confusion regarding the use of the new Web Method Specification Feature in SOAP 1.2, as many people seem to believe that you still need to specify a WSDL operation when you've specified which HTTP method you're using. HTTP "verbs", such as GET, PUT, POST, etc.. are "operations" in the same way that "GetStockQuote" is. I would like to see the HTTP binding for WSDL 1.2 reflect this. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Adopt Hugo's proposal; open syntax issues 169, 170. |
|||||||
65 | Part 3 | n/a | FTP | Design | Closed | Naresh Agarwal | Unassigned |
Title: WSDL binding for FTP? | |||||||
Description: [email] WSDL 1.1 includes a binding for SOAP 1.1 endpoints. It specifies the binding, if SOAP is used along with HTTP. If i wish to use SOAP over FTP, then i need to make certain changes in SOAP bindings of WSDL. I have listed these changes below: 1) "tranport" attribute of <definitions>\<bindings>\<soap:bindings> element need to be changes. It is an URI. Can i use any unique string for this, or i need to get a standard URI from a body like IANA? 2)"soapAction" <definitions>\<bindings>\<operation>\<soap:operation> will no more be used. 3) "location" attribute <definitions>\<service>\<port>\<soap:address> would be a FTP URL Am i missing something? Do i need to make any other changes in the WSDL bindings? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Dec 2003 telecon, decided we won't be doing a SOAP/FTP binding [email]. |
|||||||
66 | Part 3 | n/a | HTTP | Design | Closed | Sam Ruby | Unassigned |
Title: How to represent the equivalent of hypertext links? | |||||||
Description: [email] [email] The question I would like to see explored is how to describe such a service in WSDL. The essense of the issue is how to represent the equivalent of hypertext links. Starting from a document, the flow is as follows: 1) One of the elements contains an attribute of type {http://www.w3.org/1999/xlink}:href. The type of that attribute is of type {http://www.w3.org/2001/XMLSchema}:anyURI. 2) The value of the attribute is to be treated as the {http://schemas.xmlsoap.org/wsdl/http/}:address location of web service. This service is expected to be accessed via a {http://www.w3.org/2002/06/soap/features/web-method/}:Method of GET using the {http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/}:ExchangePatternName of http://www.w3.org/2002/06/soap/mep/soap-response/. 3) The resulting document contains an element of exactly the same shape and form as in step (1), and the cycle continues. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Previously agreed to structure our schema so that serviceType derivations can be reused as service references. Support for specific service reference formats such as xlink is not provided. |
|||||||
67 | Part 3 | n/a | HTTP | Design | Closed | Paul Prescod | Unassigned |
Title: Invoking HTTP GET with no arguments | |||||||
Description: [email] In addition to R085 there is a small syntactic issue. WSDL must make it possible to invoke an HTTP method like GET with no arguments, for the case where the endpoint URI *is* the URI you want to GET. In other words, http:operation/@location should be optional. I notice that soap:operation has an issue to be made optional so there is some good symmetry there. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Make http:operation/@location optional. |
|||||||
Resolution: Incorporated per [Rennes Meeting]. |
|||||||
68 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Matthew Jones | Unassigned |
Title: Confusing description between soap:body and soap:fault | |||||||
Description: [email] Section 2.5 talks about soap:binding, the first sentence is: The soap:body element specifies how the message parts appear inside the SOAP Fault element. I don't think this statement is true and it is at least certainly misleading because the soap:body appear inside input, output and soap:fault is patterned after soap:body. All of section 2.5 seems to suffer from the confusion with soap:fault. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete, parts are gone. |
|||||||
69 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Prasad Yendluri | Unassigned |
Title: Confusing description between soap:body and soap:fault | |||||||
Description: [email] The issue has to do with how can a WSDL mark some of the headers at the soap binding level to be optional. WSDL 1.1 specification is silent on this and it is not clear if it is an error if some of the headers defined in a WSDL document are missing from the SOAP message that is generated. WSDL 1.1 spec does not provide a way to mark soap:headers "optional". Current spec for the soap:bind extensions stands as follows: <soap:header message="qname" part="nmtoken" use="literal|encoded" encodingStyle="uri-list"? namespace="uri"?>* The WS-I BP team feels it would be desirable to provide a way (an AII?) to mark the soap:header elements optional or required. Alternatively all headers can be made mandatory unless marked optional via the newly defined attribute. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Dec 2003 telecon, noted that we have removed the direct soap:headers attribute way of specifying SOAP headers. Features can handle optionality of headers as appropriate. [email] |
|||||||
70 | Part 3 | n/a | SOAP/HTTP | Design | Closed | Jeff Greif | Unassigned |
Title: Confusing description between soap:body and soap:fault | |||||||
Description: [email] In 3.1, HTTP GET/POST Examples, in the first blue box, the request format for port2 and port3 should probably have part1 instead of p1, and correspondingly for p2 and p3. Otherwise the names p1, p2 and p3 appear to have been plucked out of the ether. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Remove example; rewrite in primer. |
|||||||
71 | Part 3 | R128 | HTTP | Design | Closed | David Orchard | |
Title: Optional message content in http:urlReplacement | |||||||
Description: The description language MUST support optional message parts in the address. I don't see a way of using http:urlReplacement and having some parts being optional. But maybe I just missed this and some examples would clear it up. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: The current HTTP binding now defines how only some parts may map into the request URI and meets revised R128 wording. [email] |
|||||||
Resolution: Accepted per 29 May 2003 teleconference. |
|||||||
72 | Part 3 | SOAP/HTTP | Design | Closed | Jonathan Marsh | ||
Title: Describe XMLP attachments | |||||||
Description: We have a statement from XMLP WG that we should describe attachments. We should wait to see what they come up with before we start that item. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/19/2004 FTF. We'll describe MTOM availability using our feature mechanism and oordinate with the XMLP working group to get that feature described in the MTOM/XOP specifications. No normative change to our specs. |
|||||||
73 | Part 3 | SOAP/HTTP | Editorial | Closed | Carl Binding | ||
Title: Clarify Fault versus Body in SOAP binding | |||||||
Description: [email] It seems to me that in that particular section, it is not the "Fault" element layout that is under discussion, but the SOAP-Body element layout. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete - text has been completely rewritten. |
|||||||
74 | Part 3 | SOAP/HTTP | Editorial | Closed | Carl Binding | ||
Title: Clarify name for parts in SOAP binding | |||||||
Description: [email] It is also somewhat unclear what the element name for parts, referenced via their type attribute, shall be. Maybe some clarification would be useful for true interoperability? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: At 30 July 2003 meeting in Raleigh, NC, we decided to remove the message/part construct and use XML Schema element declarations directly in interface/operation/input etc. |
|||||||
75 | Part 2 | Editorial | Closed | Someone @ XMLEurope2003 | |||
Title: Incoherence between WSA and WSD MEPs | |||||||
Description: In part 2, we use a terminology which is different from that used by the WS-Arch WG. For example, patterns names are different. This is confusing the audience. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Issue is obsolete - Patterns and MEPs have converged |
|||||||
76 | Part 1 | Design | Closed | WG | |||
Title: Pointing to derived interfaces | |||||||
Description: Is it ok for an endpoint to point to an interface derived from what is expected? 2 cases in which this happen is when endpoint in a service element and endpoint reference also gives you expected interface. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Duplicate of issue 81 | |||||||
77 | Part 1, 2 | Design | Closed | Sanjiva Weerawana | |||
Title: [local name] for interface/.*put | |||||||
Description: The semantics of other AIIs with [local name] = 'name' does not match the semantics of interface/input/@name and interface/output/@name. The latter is used to correlate messages with the interface/@pattern and does not allow the author of the wsdl:interface to coin a name (as other AIIs with the same [local name] do). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 11 Sep 2003 telecon, decided to use 'messageReference'. |
|||||||
78 | Part 1, 2 | Design | Closed | Sanjiva Weerawana | |||
Title: Implied value for interface/.*put | |||||||
Description: If a pattern specifies only one input (or output) message, the @name AII is not needed to resolve which interface/input (or interface/output) matches the messages named in the pattern. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 4 Sep 2003 teleconference, Make the @ formerly known as "name" optional. We will also > state in the specification that this attribute is required to disambiguate > two or more messages that flow in the same direction in a pattern. |
|||||||
79 | Part 1, 2 | Design | Closed | Umit Ulcinap | |||
Title: How much validation? | |||||||
Description: Does a WSDL processor have to validate portions of a WSDL document that it doesn't care about? What if it doesn't care about the hint for mapping to a method signature? What if it doesn't care about a specific binding? How much validation does a WSDL processor have to do? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Add conformance section with: 1) document conformance: conform to schema, etc. 2) infoset conformance 3) processor conformance (accepts any conformant WSDL, types, exts, Jacek's proposal) |
|||||||
80 | Part 1 | Design | Closed | David Booth | |||
Title: Inappropriate binding component name | |||||||
Description: If a binding construct does not specify an interface, and therefore provides transport (and wire rep) details indepenent of an interface, it is not a 'binding' because it is not an association between two things. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Keep "binding", close issue 80 with no action. | |||||||
81 | Part 1 | Design | Closed | Philipe Le Hegaret | |||
Title: Account for interface inheritance | |||||||
Description: Recently adopted proposal states that the QName of binding/@interface, when present, MUST match QName of service/@interface. This match process must account for interface inheritance. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Duplicate of 76? | |||||||
Resolution: Issue 81 closed without action, no compelling scenario and workaround exists. | |||||||
82 | Part 1 | Design | Closed | Glen Daniels | |||
Title: Relax binding syntax | |||||||
Description: When all is said and done, the semantics for a combination of binding info pieces must be consistent and reasonable. We should consider not using so many syntactic constraints to make that happen. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: given the changes to the syntax, we close issue 82 with no action. | |||||||
83 | Part 1, 3 | Design | Closed | Glen Daniels | |||
Title: Interaction between binding extensions | |||||||
Description: What is the interaction between binding extensions? Is it out of scope of Part 1, which appears to be the status quo? We should be explicit, especially if we define any sort of composition mechanism across bindings. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Issue 83 is closed with no action. | |||||||
84 | Part 3 | SOAP/HTTP | Design | Closed | Sanjiva Weerawana | ||
Title: SOAP header faults needed? | |||||||
Description: Do we need to define SOAP header faults? Are they currently in use? If so, are we defining them correctly? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete: SOAP header faults are already gone. |
|||||||
85 | Part 3 | HTTP | Design | Closed | Philipe Le Hegaret | ||
Title: HTTP binding depends on message/part | |||||||
Description: The HTTP (non-SOAP) binding currently uses message/part to map constructs for URL replacement. Can it use XPath instead? Would it be restricted only to the case where the Schema was written using the encoding rules? Do input/@headers map to HTTP headers? Can you have standard HTTP headers as elements? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: URL replacement syntax incorported. New issue 158 openned to track HTTP headers portion of this issue. |
|||||||
86 | Part 3 | SOAP/HTTP | Design | Closed | Raised at 4 Sep 2003 teleconference. | ||
Title: New @soapActionURI? | |||||||
Description: Should we define a new binding element for @soapActionURI? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete - we already have added soapAction attribute. |
|||||||
87 | Part 1, 2 | Design | Closed | Raised at 10 Sep 2003 e-mail. | |||
Title: Redundant direction information | |||||||
Description: Redundant direction information between children of operation/{input, output} and direction information in MEP URI. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Close issue #87 with no action. | |||||||
88 | Part 1, 3 | Design | Closed | Savas Parastatidis [email] | |||
Title: Rename wsdl:operation to wsdl:messageExchange? | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: | |||||||
Resolution: Per 30 Oct 2003 teleconference, decided not to change the name of this element. |
|||||||
89 | Part 1, 2, 3 | Design | Closed | Roberto Chinnici [email] | |||
Title: Binding message references in component model | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: | |||||||
Resolution: Close issue 89 by changing the namespace of wsoap:fault to wsdl:fault, and add a corresponding component in the abstract model. | |||||||
90 | Part 1, 2, 3 | Editorial | Closed | David Booth [email] | |||
Title: Use WSA terms? | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: | |||||||
Resolution: Accepted, editors to use WSA terms when possible. |
|||||||
91 | Part 1, 2, 3 | Editorial | Closed | David Booth [email] | |||
Title: MEP terminology | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: | |||||||
Resolution: Issue 91 is closed, editors will use the term "Message Exchange Pattern" rather than "Message Pattern". | |||||||
92 | Part 2 | Design | Closed | FABLET Youenn [email] | |||
Title: Layering message patterns | |||||||
Description: It would be cool to split the mep description in two layers: - one layer that defines the nodes and messages - one layer that tells who is the service [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Obsoleted by MEP work now completed. |
|||||||
93 | Primer | Editorial | Closed | Sanjiva Weerawarana [email] | |||
Title: Uniqueness across wsdl:definitions | |||||||
Description: Concern re: loading a wsdl:definitions and being confident that the correct interface component (for example) has been loaded. Recognition that this is an environmental problem, associated with the cataloging, namespace-resolution approach and is out of scope of this WG. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Per 2 Oct 2003 telecon, decided to include recommended practice re: use of namespace across documents in primer. |
|||||||
Resolution: 2005-3-31: Recent additions have satisifed this issue. |
|||||||
94 | Part 1 | Design | Closed | Amy Lewis [email] | |||
Title: Include cycles | |||||||
Description: What happens if the same location is included twice or if there are include cycles? The XMLSchema spec explicitly permits them. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Per 18 Dec 2003 telecon, decided to make multiple includes same as one. [email]. |
|||||||
95 | Part 1 | Design | Closed | 5 Nov 2003 f2f | |||
Title: service/@name required? | |||||||
Description: Should wsdl:service/@name be optional? We don't want to force users to have to invent a name when service appears on the wire, but currently we require @name within the context of a wsdl:description. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: @name optional for the standalone service type use. it will be required inside the context of a wsdl document. we may be able to describe in the schema as well as in the spec but we should check for side effect. Close issue 95. | |||||||
96 | Part 3 | SOAP/HTTP | Design | Closed | Jean-Jacques Moreau [email] | ||
Title: Support for SOAP intermediaries | |||||||
Description: Consider for example a service jointly provided by a (well-known, fixed) intermediary I1 and a server S. A (SOAP) message travels through I1 and S. It contains blocks B1 and B2. B1 is processed by I1. I1 appends B3 to the outbound message. B2 and B3 are both processed by S. What does the corresponding WSDL look like? [See also a followup message from Ugo Corda, pointing to additional potential issues email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/19/2004 FTF. |
|||||||
97 | Part 3 | SOAP/HTTP | Design | Closed | Jacek Kopecky | ||
Title: Schema language for SOAP encoding | |||||||
Description: Currently provide support for alternative schema languages and believe this is the way to support SOAP encoding. What would this purpose-built schema language look like? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. We will not do this new schema language for soap data model. |
|||||||
98 | Part 1, 3 | Design | Closed | Jacek Kopecky | |||
Title: > 1 style per interface | |||||||
Description: Is it sufficient to be able to mark an interface with a single style versus multiple? Or do we want to allow the development of overlapping, perhaps orthogonal indicators of the style(s) used to construct the interface and its messages? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Make @style an unordered list of URIs | |||||||
99 | Part 3 | SOAP/HTTP | Design | Closed | Jacek Kopecky | ||
Title: Support SOAP 1.2 data model and encoding | |||||||
Description: Issue 23 is generally about full support for SOAP 1.2, and specifically it mentions many aspects of the SOAP 1.2 Recommendation. I suggest that we split this issue into separate issues on support for the Data Model and Encoding (one), RPC (two), transport binding framework (three). Features are already covered by issue 14. After such split, we can close issue 23 [email]. (See related issue 97.) [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Resolved as duplicate of 97. |
|||||||
100 | Part 3 | SOAP/HTTP | Design | Closed | Jacek Kopecky | ||
Title: Support SOAP 1.2 RPC | |||||||
Description: Issue 23 is generally about full support for SOAP 1.2, and specifically it mentions many aspects of the SOAP 1.2 Recommendation. I suggest that we split this issue into separate issues on support for the Data Model and Encoding (one), RPC (two), transport binding framework (three). Features are already covered by issue 14. After such split, we can close issue 23 [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Can't support without a SOAP data model schema language (see issue 97). |
|||||||
101 | Part 3 | SOAP/HTTP | Design | Closed | Jacek Kopecky | ||
Title: Support SOAP 1.2 transport binding framework | |||||||
Description: Issue 23 is generally about full support for SOAP 1.2, and specifically it mentions many aspects of the SOAP 1.2 Recommendation. I suggest that we split this issue into separate issues on support for the Data Model and Encoding (one), RPC (two), transport binding framework (three). Features are already covered by issue 14. After such split, we can close issue 23 [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Already handled by @protocol and F&P. |
|||||||
102 | Part 1 | Design | Closed | Allen Brookes | |||
Title: Schemas in imported WSDL | |||||||
Description: The question came up at the face-to-face whether a wsdl:import imported any embedded schemas. As I remember Glen, Tom and Sanjiva all thought that it should while Roberto thought that it did not. Was there any resolution to this issue? [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Issue 102 closed with Glen's wording and with "root" changed to "importing". | |||||||
103 | Part 1 | Design | Closed | Jacek Kopecky | |||
Title: Proposal for combining the two attribute operation styles to one | |||||||
Description: Hi all, I agreed to try and come up with a proposal for combining the two attribute operation styles into one, so here it is. I'm proposing here a change to the accepted proposal [1] referenced from the last WD because our spec doesn't actually contain the text. [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Close issue 103 as irrelevant since styles are removed. | |||||||
104 | Part 1 | Design | Closed | Jacek Kopecky | |||
Title: Appendix E cleanup | |||||||
Description: [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Hi all, as per my action item I've reviewed appendix E [1] (mainly from the POV of other type systems) and here's what I found. In the current spec, we always use the attributes named 'body' or 'headers' (in no namespace) for referencing element declarations, whether XML Schema, DTD or Relax NG. It means that our model of a message is one that has a single optional body XML element information item and zero or more header XML element information items. This isn't specified anywhere and it isn't clear if there may be more kinds of things in a message. So my first suggestion is to specify an explicit language what the model of message is, perhaps as a paragraph in the section on The Message Reference Component. We also need to decide explicitly on the extensibility of the message model, i.e. whether there are other things in the model of a message. If we only accept XML element declarations (body and headers), it will require that we devise a (possibly simple and limited) mapping to non-XML stuff for use with HTTP and MIME (for exampe for URL parameters and HTML form encoding). If we're happy with this, we will also require that all type systems that might be used in WSDL declare XML elements and we need to say so in the spec. I don't see that as much of a problem, it is certainly possible for this to work with SOAP Encoding and SOAP Data Model. It may be awkward if we have a nice non-XML data model and a binding that uses it and we need to go through an XML conversion step in order to describe this in WSDL. If we accept XML element declarations and other stuff as well (i.e. there are other kinds of stuff in a message than just header and body XML element information items), we'll need an example for that in Appendix E. |
|||||||
Resolution: Issue factored into issues 143, 144, 145. |
|||||||
105 | Part 1 | Design | Closed | Paul Downey | |||
Title: Abstract Faults | |||||||
Description: [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Proposal to hoist faults into the interface alongside operations. |
|||||||
Resolution: Accept Paul's proposal to hoist faults in the interface. Rename faultDefault to fault. Allow <value>,<subcode> as children of <wsoap:fault[Default]>. Remove per-operation (in|out)fault. |
|||||||
106 | RDF Mapping | Design | Closed | Jacek Kopecky | |||
Title: Using RDF in WSDL | |||||||
Description: [email]. How can RDF statements (including OWL statements) be represented in WSDL? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action, see Jacek's withdrawal - confirmed 2006-01-05. |
|||||||
107 | Primer | Editorial | Closed | Paul Downey | |||
Title: Schema for vector, matrix, array | |||||||
Description: [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: WSDL 1.1 document included a set of rules for naming and representing ArrayOfBlah in an /encoded/ binding which greatly aided interoperability of for rpc/encoded exchanges. I therefore propose we provide suggested schema extracts for representing a vector, a matrix and an associative array. These would not be normative, but would provide a well supported pattern to follow when generating code from WSDL and WSDL from code. |
|||||||
Resolution: Close with no action, per decision. |
|||||||
108 | Part 1 | Design | Closed | Roberto Chinnici | |||
Title: Properties and schema other than XSD | |||||||
Description: [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: It appears that the definition of the property component in WSDL 2.0 ([1]) does not allow the use of schema languages other than XML Schema. |
|||||||
Resolution: Accept proposal |
|||||||
109 | Part 1 | Design | Closed | Paul Downey | |||
Title: WSDL versioning | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: In the Interface Description section of the charter there is the following: Developers are likely to want to extend the functionality of an existing Web service. The Working Group will look into extending interface descriptions in a decentralized fashion, i.e. without priori agreement with the original interface designers. We read this as WSDL 2.0 providing a mechanism for versioning a Web Service, at least an outline how to add contents of a message without breaking existing interactions. There appears to be nothing in the requirements relating to how to version a Web Service beyond being able to identify versions of services and descriptions. Has this issue been lost, or is our reading of the charter incorrect ? |
|||||||
Resolution: Joint TF with Schema and WSDL to investigate whether best practices can be developed, which will be included in the Primer. |
|||||||
110 | Part 3 | HTTP | Design | Closed | Philippe Le Hegaret | ||
Title: Full URLReplacement? | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: Should we allow complete URL replacement (changes to portions of the URL other than query parameters) or only query parameter mechanism? Question raised as to whether all possible schemas can be encoded in a URL, or only a restricted subset. Should only RPC style be encoded? Call it something other than RPC? Will we support the body in text/xml encoding only, or also alternate x-www-url-encoded (forms encoding) syntax? There are also three more Part 3 issues raised against Philippe's HTTP binding, which seem to be siblings of Issue 110. I summarize these in the enclosed mail. 1) Is it good practice to extract part of your content to parameterize your URI? If not, what is the best way? 2) Do we want to name the "restricted-to-simpleTypes RPC" style with a URI ala the RPC styls? 3) What if you start using fragids? |
|||||||
Resolution: Addressed by Philippe's comprehensive proposal, adopted on March 25 2004. |
|||||||
111 | Part 1 | Design | Closed | Yaron Goland | |||
Title: Simplified syntax? | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: [email]. This letter proposes three new features for WSDL 2.0 intended to make it much easier for users to directly interact with WSDL definitions. The first feature allows for the use of inclusion by value as an addition to WSDL 2.0's current standard mechanism of inclusion by reference. The second feature provides simplified elements that can be used to describe common WSDL scenarios. The third feature provides a simplified serialization for the WSDL 2.0 infoset that makes WSDLs easier to read and write. |
|||||||
Resolution: No Action. |
|||||||
112 | Part 1 | Design | Closed | Yaron Goland | |||
Title: New headers/body style? | |||||||
Description: [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Arguably the most common protocol design style for application protocols is what this letter will refer to as the headerBody style. Protocols such as HTTP, SOAP, FTP, IMAP, ACAP, SMTP, etc. all use application messages that contain a single body and multiple headers. Given the universal popularity of this design style this letter proposes that WSDL 2.0 add direct support for this style to WSDL 2.0. |
|||||||
Resolution: Proposal adopted as a feature (not required, built-in, or mandated by conformance.) Will go in Part 2. |
|||||||
113 | Part 1 | Design | Closed | Jacek Kopecki | |||
Title: Operation style | |||||||
Description: [email]. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: I'm here proposing an alternate approach to indicating operation styles (not using the 'style' attribute). |
|||||||
Resolution: Issue withdrawn after successfully resolving Issue 98. |
|||||||
114 | Part 3 | SOAP/HTTP | Design | Closed | Jonathan Marsh | ||
Title: Name of wsoap:fault/@name | |||||||
Description: Open issue on the name of wsoap:fault/@name and outfault/@name (should indicate that it is a reference, not defining a name) [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Obsolete, already fixed. |
|||||||
115 | Part 1 | Design | Closed | Jonathan Marsh | |||
Title: Improving on-the-wire conformance | |||||||
Description: Is there something we can do to improve conformance on the wire between WSDL-based agents? This would prevent us from getting immediately profiled. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Added conformance section delineating processor and document conformance. |
|||||||
116 | Part 2 | Design | Closed | Jonathan Marsh | |||
Title: Renaming the label of MEPs | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: Change MEP labels from A and B to IN and OUT |
|||||||
Resolution: Proposed resolution accepted. |
|||||||
117 | Part 1 | Design | Closed | TAG | |||
Title: Marking operations as 'safe' | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: Marking operations as 'safe' |
|||||||
Resolution: Add optional Boolean "safe" attribute to interface operation, corresponding property in the component model. |
|||||||
118 | Part 1 | Design | Closed | Bijan at Jan 04 FTF | |||
Title: Renaming @message | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: Rename @message to @element. |
|||||||
Resolution: Accepted. |
|||||||
119 | Part 1 | Design | Closed | Bijan at Jan 04 FTF | |||
Title: Renaming @messageReference | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: Rename @messageReference to @label. |
|||||||
Resolution: Accepted, along with editorial license to adjust names in the component model accordingly. |
|||||||
120 | Part 1 | Design | Closed | Umit | |||
Title: Operation name feature | |||||||
Description: Operation name feature proposal. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Closed with no action. |
|||||||
121 | Part 1 | Design | Closed | Yaron | |||
Title: Broken resolution of NCNAME or QNAME | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Editors to add clarification text with regards to issue 121. |
|||||||
122 | Part 1 | Design | Closed | Yaron | |||
Title: messageReference semantics on binding | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Intention expressed by Yaron is correct. Editors will add clarification. |
|||||||
123 | Part 1 | Design | Closed | Yaron | |||
Title: Requiring all operations to be bound | |||||||
Description: [email] Might be reopening Issue 16. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Further clarify the spec to make clear that all operations must be bound. |
|||||||
124 | Part 1 | Design | Closed | Yaron | |||
Title: Semantics of mandatory properties and features | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Editors to clarify the spec to say that wsdl:required attribute means that a feature must be understood and it must be engaged. |
|||||||
125 | Part 1 | Design | Closed | Yaron | |||
Title: Make messageReference mandatory | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: No action. This topic has been discussed in depth by the WG before, and had to be resolved by going with the majority. There is no new information that would lead us to reconsider this issue, or to expect a different outcome this time. |
|||||||
126 | Part 1 | Design | Closed | Yaron | |||
Title: Confusion between binding and element names | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No consensus to change. Closed with no action. |
|||||||
127 | Part 1 | Design | Closed | Yaron | |||
Title: Behavior if import/include fails | |||||||
Description: What is the required behavior if it is impossible to successfully import/include an identified document? If this an unrecoverable error that requires that the WSDL be rejected for processing? If so, then shouldn't the spec explicitly state this? [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: It's ok to have bad imports but if during QName resolution you can't find something then it fails like any other qname resolution issue. Include will fail early (immediately). |
|||||||
128 | Part 1 | Design | Closed | Yaron | |||
Title: Two imports for the same namespace illegal? | |||||||
Description: In the case of import the specification doesn't actually define what happens if someone writes two imports for an identical namespace. Although some limited definition redundancy is supported by the spec the support would not appear to be robust enough to support importing the same WSDL definition twice. Therefore putting in two imports as a way to provide redundant locations would appear illegal. But this begs the question - Is it illegal to specify two imports for the same namespace? If so, shouldn't this be explicitly stated in the spec? [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Add to spec to explicitly allow >2 imports from same ns. |
|||||||
129 | Part 1 | Design | Closed | Yaron | |||
Title: Allow multiple values for import/include locations | |||||||
Description: Both WSDL import and include only allow for a single location to be specified. Given the unreliable nature of the Internet would it not be appropriate to allow for more than one location to be specified? Given the permissive semantics of include it would be tempting to specify multiple includes, all pointing to the same file but at different locations as a way to make the WSDL definition more robust in the face of network failures. However this would needlessly waste system resources making unnecessary file requests. If the WSDL processor knows that a set of URIs are equivalent then it need only make requests until it finds a URI that works. [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action. |
|||||||
130 | Part 3 | HTTP | Design | Closed | DaveO | ||
Title: Need async request/response HTTP binding | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Closed with no action. |
|||||||
131 | Part 1 | Design | Closed | DaveO | |||
Title: Treatment of optional extensions | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Clarify that if an optional extension (i.e., an extension not marked as required) is not understood it MUST be ignored. Any not understood extension attributes MUST be ignored. |
|||||||
132 | Part 1 | Design | Closed | DaveO | |||
Title: Message attribute optional | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Message attribute must be optional so it can be omitted when a corresponding attribute for a different type system is in use instead. Factored out description of empty bodies into a new issue (150). |
|||||||
133 | Part 1 | Design | Closed | DaveO | |||
Title: Why aren't two input/output elements allowed to share the same @element value? | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal:
|
|||||||
Resolution: This is by design. We note that issue 133 is a by-product of the removing <message> discussion. If you want to have alternate actual elements for a message reference (label) of a MEP then you have to define a wrapper element with a schema and use that. Alternatively DavidB suggested one could define two operations and achieve the same result (different input same output). |
|||||||
134 | Part 1 | Design | Closed | Umit, et al | |||
Title: Proposal for adding Compositors | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action. |
|||||||
135 | Part 1 | Editorial | Closed | DaveO | |||
Title: WSDL Specification readability | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] |
|||||||
Resolution: Proposal rejected, will pursue a stylistic solution insteead. Issue reclassified as Editorial. Editorial work rejected. |
|||||||
136 | Part 2 | Design | Closed | Yaron | |||
Title: Add in-optional-out MEP | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Accept the addition of the in-optional-out MEP to Part 2. |
|||||||
137 | Part 1 | Design | Closed | Glen | |||
Title: Properties should not be limited to simple types | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Changing the xs:anySimpleType in section 2.7.2.3 to xs:anyType, and appropriately reword the text in table 2-7. |
|||||||
Resolution: Proposed resolution accepted. |
|||||||
138 | Part 1 | Design | Closed | DaveO | |||
Title: Second level xs:import | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] |
|||||||
Resolution: Editors to add clarifications (sample text included in proposal) to the Core spec, clarifying that references from WSDL components to XML Schema components, and from WSDL components to WSDL components, operate consistently with XML Schema to XML Schema references - that is, an import statement is needed for each namespace used in such a reference. |
|||||||
139 | Part 1 | Design | Closed | Martin Gudgin | |||
Title: Non-deterministic schema | |||||||
Description: The content model of wsdl:definitions is non-deterministic. I notice it has been this way since the substitution group based extensibility was removed on 2003-08-04. I note in passing that one of the reasons we went with substitution groups was that it gave us a deterministic content-model. [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: The only fix I can see given the current grammer is to change the content model of wsdl:definitions to be <xs:any namespace='##any' minOccurs='0' maxOccurs='unbounded' />, which doesn't capture any of the contraints regarding wsdl:include, wsdl:import, wsdl:types, but there you go! |
|||||||
Resolution: Adopted proposed resolution |
|||||||
140 | Part 1 | Design | Closed | Tom Jordahl | |||
Title: Version attribute proposal | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: See email for complete proposal. |
|||||||
Resolution: No action. |
|||||||
141 | Part 3 | SOAP/HTTP | Design | Closed | Jacek | ||
Title: Should WSDL say anything about whitespace in SOAP:Body? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: TBD |
|||||||
Resolution: Closed 5/21/2004 FTF. We don't say how an infoset must be serialized, only that it should match (validate against) the schema. SOAP canonicalization should handle this case. |
|||||||
142 | Part 1 | Design | Closed | Bijan Parsia | |||
Title: Name of "message" property on Message|Fault Reference component | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: TBD |
|||||||
Resolution: Rename {message} property to {element}. |
|||||||
143 | Part 1 | Design | Closed | Bijan Parsia | |||
Title: Referencing other type systems | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Adopted proposed resolution, as well as "properties and" in section 3.2. Reaffirmed our desire to provide guidance on how to support non-XML type systems. |
|||||||
144 | Part 1 | Design | Closed | Bijan Parsia | |||
Title: Why can't message reference simpleTypes? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: TBD |
|||||||
Resolution: No action, mooted by resolution of issue 143. |
|||||||
145 | Part 1 | Design | Closed | Bijan Parsia | |||
Title: How can you tell which type system is in use? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: TBD |
|||||||
Resolution: No action, mooted by resolution of issue 143. |
|||||||
146 | Part 1 | Design | Closed | Jacek | |||
Title: should WSDL be able to describe an operation with *anything* in the message? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: element="" (no GED) means anything goes. |
|||||||
Resolution: Proposal accepted (#empty changed to #none) |
|||||||
147 | Part 3 | HTTP | Design | Closed | Youenn | ||
Title: HTTP binding uses static content-type header | |||||||
Description: [Search or Google WG archive for relevant posts.] | |||||||
Proposal: | |||||||
Resolution: Closed 5/20/2004 FTF. http:inputSerialization and http:outputSerialization attributes will be added, per the proposal at http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0057.html. |
|||||||
148 | Part 1 | Design | Closed | Jonathan Marsh | |||
Title: Double check URI comparison algorithm and relative URI use | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Double-check that we have a URI-comparison algorithm in place for any URIs we need to compare. Double-check our use of relative URIs is reasonable and consistent. |
|||||||
Resolution: Change all URIs EXCEPT import/@location and include/@location to absolute URIs at the XML document level. |
|||||||
149 | Part 1 | Design | Closed | Jonathan Marsh | |||
Title: Duplicate features with conflicting @required | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email Conflicts should be allowed with the required="true" taking precedence. |
|||||||
Resolution: clarify that the strongest value wins. |
|||||||
150 | Part 1 | Design | Closed | DaveO, WG | |||
Title: Indicating empty bodies | |||||||
Description: [email], factored at 26 Feb 2004 telcon. There doesn't appear to be an explicit way (post-message removal) to describe a message with an empty body. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: Proposal accepted (#empty changed to #none) |
|||||||
151 | Part 1 | Design | Closed | WSD WG | |||
Title: Reference attribute name consistency | |||||||
Description: From minutes of 5 Mar 2004 FTF, there may be inconsistencies between attributes refering to other components. We should use a single strategy, e.g. @ref, or @{componentType}Ref. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] |
|||||||
Resolution: Proposal accepted. |
|||||||
152 | Part 1 | Design | Closed | Jacek | |||
Title: Importing the targetNamespace | |||||||
Description: From 5 Mar 2004 FTF minutes: Are imports for the same namespace as the targetNamespace of the importing document allowed? If so, what does that mean? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal:
|
|||||||
Resolution: No action: keep consistent with Schema, disallow imports of the targetNamepace. |
|||||||
153 | Part 3 | HTTP | Design | Closed | Philippe | ||
Title: Base URI for operation/@location in HTTP binding | |||||||
Description: [proposal] Should it be relative to the address of the service or to the [base URI] property of the location element information item? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: @location will be relative to the address of the service. |
|||||||
154 | Part 3 | HTTP | Design | Closed | Philippe | ||
Title: Multi-part post in HTTP binding | |||||||
Description: [proposal] Do we want the "multipart/related" format? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Use XOP. Plan to revisit this after competing SOAP 1.2 HTTP binding XOP support. |
|||||||
Resolution: XOP is SOAP-specific. Use case appears marginal. Close with no action. |
|||||||
155 | Part 3 | HTTP | Design | Closed | Philippe | ||
Title: Out patterns in HTTP binding | |||||||
Description: [proposal] Doesn't list the Out patterns for the moment. Waiting to see how the dicussion on addressing is going to stabilize. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Plan to revisit this after competing SOAP 1.2 HTTP binding Output operations . |
|||||||
Resolution: Closed at 5/21/2004 FTF. Add wording to say that our bindings only support the identified MEPs but others can be handled if appropriate rules are defined elsewhere. |
|||||||
156 | Part 1 | Editorial | Closed | Ugo Corda | |||
Title: Endpoints and QNames | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Clarify that even though we identify operations and endpoints and other stuff by QName, they are not referencible by QName because those QNames are only unique within that component (within the interface or within the service). |
|||||||
157 | Part 1 | Design | Closed | Glen | |||
Title: f&p at the service level | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Allow f&p markup within <wsdl:service> |
|||||||
Resolution: Yes, allow f&p within service and endpoint, and in message references, fault references, and binding message references as well. Also see issue 228 roe remaining locations f&p could be allowed. |
|||||||
158 | Part 3 | HTTP | Design | Closed | Philipe Le Hegaret | ||
Title: Setting HTTP headers in the HTTP binding | |||||||
Description: From issue 85, there remains an open question about facilities for setting HTTP headers within the HTTP binding. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Subsumed by adopting proposal for Issue 112. |
|||||||
159 | Part 1 | Design | Closed | WG | |||
Title: Messages with mixed Body content or multiple element content | |||||||
Description: @element="#any" means any single element, preventing the desctiption of messages with text, mixed content, or a sequence of elements. Are there compelling use cases for adding these capabilities? [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No new facilities. Add a note pointing out that our SOAP binding only allows a single element in the body. |
|||||||
160 | Part 1 | Design | Closed | Jacek | |||
Title: Formalize processing model | |||||||
Description: Should we describe reasonable paths through document for the purpose of concretely defining processor conformance? Alternatively should we just rely on document conformance? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] |
|||||||
Resolution: Accepted proposal. |
|||||||
161 | Media type description | Design | Closed | Media Type TF | |||
Title: Should media-type values allow wild cards | |||||||
Description: HTTP/MIME allow wildcards for declaring accepted media-types. Should this specification also allow wildcards for acceptedMediaTypes and/or mediaType attribute values, such as "image/*"?. There is already an issue recorded for this problem by XMLP as stated in XMLP Issue 443. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: wildcards (/*) are allowed. */* is not at this point (see issue 245). |
|||||||
162 | Media type description | Design | Closed | Media Type TF | |||
Title: Allowing other choices for mediaType values | |||||||
Description: Should other choices be allowed to represent media-type values? Even if allowed, should this specification utilize them? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Obsolete. IANA media types are sufficient. |
|||||||
163 | Media type description | Editorial | Closed | Media Type TF | |||
Title: Publishing WSDL 2.0 schema | |||||||
Description: We need a WSDL 2.0 published schema to refer to to fix the table" [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: http://www.w3.org/2004/03/wsdl |
|||||||
164 | Part 3 | HTTP | Design | Closed | Youenn | ||
Title: Support for HTTP chunking and other HTTP options | |||||||
Description: [email]. Should we describe the availability of chunking and other HTTP 1.1 options in the description so that clients don't have to undergo the performance hit (and apparent real-world interop problems) of runtime negotiation of HTTP features like chunking, and transfer-encoding? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Prasad suggests a space-separated list of supported HTTP options. |
|||||||
Resolution: Closed 5/20/2004 FTF. Will support an http:transfer-coding attribute on bindings. |
|||||||
165 | Part 3 | HTTP | Design | Closed | Youenn | ||
Title: HTTPS support | |||||||
Description: [email] "adding support to basic https options like basic/mutual authentication." Issue is whether to add description support for any authentication requirements a service may impose on a client. See also issue 56. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/20/2004 FTF. Will add http:authenticationType and http:authenticationRealm to endpoint. |
|||||||
166 | Part 3 | HTTP | Design | Closed | Hugo | ||
Title: Binding of Faults in HTTP Binding | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: The serialization should be done the same way as out messages. Adding a column "Fault serialization" in Table 3-1 in section 3.1.1.1 of Part 3 whose value is application/xml in all cases should do the trick. For the HTTP status code, I think that we have 3 options:
I don't think that the latter is necessary. It would be good IMO to go with the second option with a SHOULD, i.e. recommend using a 4xx or 5xx status code when a fault is returned. |
|||||||
Resolution: Provide an http:code attribute to specify the code on binding/fault. Ensure that for http:faultSerialization="application/xml" that the body of the fault response contains the XML specified in binding/fault/@ref. |
|||||||
167 | Part 1 | Editorial | Closed | Hugo | |||
Title: Synchronize pseudo-schema | |||||||
Description: [email] Pseudo-schema doesn't quite match the draft. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Part 1, Part 3, schema, and pseudo-schema all need to be synchronized about where f&p are allowed. See issue 157. |
|||||||
168 | Part 1 | Design | Closed | Mark Baker | |||
Title: Which operation | |||||||
Description: [email] Is the Operation being invoked indicated by the name of the wsdl:operation, or by the operation of the binding? Spec is unclear. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Unique GED requirement addresses this, commenter agrees he's unlikely to get more. |
|||||||
169 | Part 1 | Design | Closed | David Orchard/Mark Baker/WSDL WG | |||
Title: Syntax for webMethod - property or attribute? | |||||||
Description: [email] David Orchard proposed an attribute-based syntax for Web Method, rather than the generic property syntax proposed by Hugo. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: wsdl:interface/wsdl:operation/@webMethod (?) |
|||||||
Resolution: Closed with no action |
|||||||
170 | Part 3 | HTTP | Design | Closed | David Orchard/Mark Baker | ||
Title: Shortcut syntax for synchronizing webMethod and HTTP verb | |||||||
Description: [email] David Orchard proposes a syntax. WG on 22 April 2004 discusses this as a shortcut syntax issue. [Precursor email from Mark Baker] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] I'd like to think of a way of using that web method/rest name in the binding. Strawman: the http:binding could have an attribute for re-using the webMethod, ie UseWebMethodAsHTTPOperations="true"... |
|||||||
Resolution: Closed at 5/21/2004 FTF. Obsolete: webMethod has been removed. |
|||||||
171 | Part 3 | HTTP | Design | Closed | WG | ||
Title: Indicate XML version for XML in SOAP and HTTP bindings? | |||||||
Description: Discussed the implications of XML 1.1 a the 29 April 2004 telcon, thought there might be a need to indicate which version of XML is used in XML messages. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Marsh] For SOAP/HTTP binding, this is a non-issue (XMLP WG says it must be XML 1.0.) For XML bodies in HTTP messages, there might be other ways that parsing can fail (e.g. invalid, dependent on external resources, etc.) - why we should single out XML version? |
|||||||
Resolution: Closed with no action: XML serialization is not constrained by WSDL. |
|||||||
172 | Part 3 | Design | Closed | Sanjiva | |||
Title: Change wsoap:code/wsoap:value to an attribute | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Change: <wsoap:code> <wsoap:value>xs:QName</wsoap:value> <wsoap:subcode> <wsoap:value>xs:QName</wsoap:value> <wsoap:subcode>...</wsoap:subcode> </wsoap:subcode>? </wsoap:code> to <wsoap:code value="xs:QName"> <wsoap:subcode value="xs:QName"> <wsoap:subcode>...</wsoap:subcode> </wsoap:subcode>? </wsoap:code> This makes the syntax more consistent with the rest of the SOAP binding which is rather attribute-heavy. |
|||||||
Resolution: Proposal accepted. |
|||||||
173 | Part 3 | SOAP/HTTP | Design | Closed | Paul | ||
Title: Convert nested subcodes into a flat list (attribute) | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. |
|||||||
174 | Part 1 | Design | Closed | Arthur | |||
Title: Tie WSDL conformance to XML conformance? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: proposal accepted. |
|||||||
175 | Part 1 | Design | Closed | Paul | |||
Title: Is it valid for a XML 1.1 document to import or include a XML 1.0 document (and vice versa)? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: proposal accepted. |
|||||||
176 | Part 1 | Design | Closed | JJM | |||
Title: Can a WSDL 2.0 XML 1.1 document contain (or reference), a XML Schema 1.0 type description? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: proposal accepted. |
|||||||
177 | Part 1 | Design | Closed | JJM | |||
Title: Normative dependence on XML Schema 1.0 precludes XML 1.1 | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: proposal, plus a note warning people that changes in Schema support for XML 1.1 might cause this to change prior to Recommendation. |
|||||||
Resolution: Proposal adopted, with a note that "processing of documents encoded in XML 1.1 is not a conformance requirement". |
|||||||
178 | Test suite | SOAP/HTTP | Design | Closed | TAG | ||
Title: Track operation safety | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Moved to CR comments list. 3/29/06 |
|||||||
179 | Part 3 | SOAP/HTTP | Editorial | Closed | Hugo | ||
Title: PUT & DELETE need to be added | |||||||
Description: Spec review at FTF: PUT & DELETE decision not reflected in draft. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Added to EDTODO. |
|||||||
180 | Part 3 | SOAP/HTTP | Design | Closed | Roberto | ||
Title: Inconsistent propogation of soap:module and features & properties | |||||||
Description: Spec review at FTF. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved to use inside-out lexical scoping:nearest enclosing scope wins (as opposed to highest level of "required" as previously. |
|||||||
181 | Part 3 | SOAP/HTTP | Editorial | Closed | JJM | ||
Title: Bind to other protocols | |||||||
Description: Spec review at FTF: text implies only SOAP HTTP protocol can be used. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved to fix wording to make it clear other transports were possible (when they have been defined and given a URI.) |
|||||||
182 | Part 3 | SOAP/HTTP | Design | Closed | Jonathan | ||
Title: defaultMEP inheritance-syntax or model? | |||||||
Description: Spec review at FTF: defaultMEP and defaultWebMethod appear in the component model: is there semantics associated with using defaults instead of local attributes? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No difference - default* will be removed from the spec, XML mapping updated to propogate the defaults into the corresponding property. |
|||||||
183 | Part 3 | SOAP/HTTP | Editorial | Closed | Sanjiva | ||
Title: wsoap:prefix | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: will use wsoap: convention instead of wsoap12:. |
|||||||
184 | Part 3 | SOAP/HTTP | Design | Closed | Ugo | ||
Title: MTOM serialization into SOAP body | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed at 5/21/2004 FTF: Wording will be updated to ensure MTOM is not precluded. |
|||||||
185 | Part 3 | SOAP/HTTP | Design | Closed | Sanjiva | ||
Title: Eliminate soap:header | |||||||
Description: Spec review at FTF. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Remove soap:header - use soap:module for this. |
|||||||
186 | Part 3 | SOAP/HTTP | Design | Closed | Umit | ||
Title: Interaction and placement of soap:header and soap:module | |||||||
Description: Spec review at FTF [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed soap:header (Issue 185), placement of soap:module will not change. |
|||||||
187 | Part 3 | SOAP/HTTP | Design | Closed | Youenn | ||
Title: Interaction between MEPdefault and webMethodDefault | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed at 5/21/2004 FTF. Obsolete since webMethodDefault is removed in issue resolution of Issue 190. |
|||||||
188 | Part 3 | SOAP/HTTP | Design | Closed | DaveO | ||
Title: wsoap:address vs. http:address? | |||||||
Description: Spec reveiw at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed at 5/21/2004 FTF. |
|||||||
189 | Part 3 | SOAP/HTTP | Design | Closed | DaveO | ||
Title: Binding message content to URI | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Part 1 and 2b and counterproposal adopted. Part 2a and 3 rejected. |
|||||||
190 | Part 3 | SOAP/HTTP | Design | Closed | DaveO | ||
Title: Layering of SOAP webMethod on top of HTTP binding | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed at 5/21/2004 FTF. |
|||||||
191 | Part 3 | SOAP/HTTP | Design | Closed | Hugo | ||
Title: Relationship of SOAP MEPs and WSDL MEPs | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/20/2004 FTF. Will add a statement to the introduction of Part 2 along the lines of "if you are familiar with soap meps, wsdl meps are the same but a little bit more abstract". Will add a statement to Part 3 relating WSDL MEPs and the SOAP MEPs bound. |
|||||||
192 | Part 3 | SOAP/HTTP | Editorial | Closed | Amy | ||
Title: 2.4.1, 2.5.1 "increasing specificity" -> "decreasing ..." | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
193 | Part 3 | SOAP/HTTP | Design | Closed | Youenn | ||
Title: Module declaration at different levels | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved to allow soap:module at i/o, ops, and binding - module determines what the layers mean. |
|||||||
194 | Part 1, Part 3 | SOAP/HTTP | Design | Closed | Glen | ||
Title: Why interleave wsdl: and wsoap: namespaced elements? | |||||||
Description: Spec review at FTF: [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed 5/21/2004 FTF. Adopted Sanjiva's proposal for turning subelements into attributes, and Roberto's amendment to add @type to the binding to determine at the top level what the binding binds to. |
|||||||
195 | Part 1 | Design | Closed | DaveO | |||
Title: Property value merging | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action. |
|||||||
196 | Part 3 | SOAP/HTTP | Design | Closed | Asir | ||
Title: Module operation at operation level versus input/output level | |||||||
Description: Spec review at FTF [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No change. We will keep modules at i/o level. |
|||||||
197 | Part 1 | Design | Closed | Umit | |||
Title: Don't override interface feature requiredness in binding | |||||||
Description: May 2004 FTF: Don't like the ability to override a required feature in the interface with a non-required one in the binding. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Add to primer a note saying essentially "Note that overriding in the binding features required at the interface can cause unexpected results." |
|||||||
198 | Media type description | Design | Closed | WG | |||
Title: mismatch between value of media type attribute and pattern | |||||||
Description: [19 May FTF] Mismatch between value of media type attribute and pattern -- says nothing about the data. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Out of scope what to do when messages don't match the description. Close with no action. |
|||||||
199 | Media type description | Design | Closed | WG | |||
Title: mismatch between the media type attribute and the actual data | |||||||
Description: [19 May FTF] Possible error conditions: mismatch between the media type attribute and the actual data. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Out of scope what to do when messages don't match the description. Close with no action. |
|||||||
200 | Media type description | Design | Closed | WG | |||
Title: Where should appInfo go? | |||||||
Description: [19 May FTF] Where should the annotation appear, on the type and/or the element? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Say in the spec that this annotation can appear on element declarations and complex type definitions, where these types are derived from base64binary. |
|||||||
201 | Media type description | Design | Closed | WG | |||
Title: Name of mediaType | |||||||
Description: [19 May FTF] Consider changing name from mediaType to contentType [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Obsolete. |
|||||||
202 | Media type description | Editorial | Closed | WG | |||
Title: More examples | |||||||
Description: [19 May FTF] Would like more examples: e.g using a static type -- i'm always going to use an image/jpeg. What would that look like? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted, editors to add more examples (valid and runnable) illustrating each significant feature. |
|||||||
203 | Media type description | Design | Closed | WG | |||
Title: Limited to base64encoded? | |||||||
Description: [19 May FTF] Explain why this proposal is limited to base64encoded? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Added hexBinary as well. Rationale for contentType on hexBinary (and base64binary): content types can be applied to sequences of octets, therefore the XML Schema types whose value sets are sequences of octets can be annotated with content type. |
|||||||
204 | Media type description | Design | Closed | WG | |||
Title: Why default to */* instead of to "no effect"? | |||||||
Description: [19 May FTF] Explain why */* AND absence means this is opaque application data (i.e. application/octet-stream. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Removed that sentence from the spec. |
|||||||
205 | Media type description | Design | Closed | WG | |||
Title: Explain priority | |||||||
Description: [19 May FTF] Pattern includes use of priority -- either explain relationship or get rid of it. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Obsolete. Closed with no action. |
|||||||
206 | Media type description | Design | Closed | WG | |||
Title: Annotations and schema component model. | |||||||
Description: [19 May FTF] How do annotations show up in component model? (currently limited to a "binary information element") [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Obsolete and duplicate. |
|||||||
207 | Part 3 | SOAP/HTTP | Design | Closed | Hugo | ||
Title: How to mark which elements to optimize | |||||||
Description: [email] A service may want to indicate that it wants the HTTP Transmission Optimization Feature to be used, and that the content of a particular element (e.g. a large Base64-encoded image) must be optimized. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] One way we could approach this would be to have a xop:optimize element under binding, which references to the elements to be optimized: <binding> ... <xop:optimize> <element ref="id_of_element1_to_be_optimized" hint="required" /> <element ref="id_of_element2_to_be_optimized" hint="recommended" /> </xop:optimize> ... </binding> Solicit input on this from XMLP WG, perhaps any hints should be defined by them. |
|||||||
Resolution: proposal accepted. |
|||||||
208 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Misc. editorial comments | |||||||
Description: [email] - 2.1.2: Is the pseudo-schema normative? Where are its vocabulary and rules explained? - 2.2.1: "The interfaces a given interface extends MUST NOT themselves extend that interface either directly or indirectly." What does "that" refer to? (would be good to mention recursion). - 2.2.2.3: There needs to be a description of, or references to, the properties here (e.g., {message references}) - 2.3.1: "execution of an operation of the interface." -> "execution of *any* operation of the interface." ? - 2.3.1: "The reason... is because that" Poor English. - 2.3.1: "If a non-XML type system is in use... then additional properties would need to be added..." Poor English. - 2.3.1: "...to allow associating such.." Poor English. - 2.3.1: "to allow associating such message types with the message reference" Shouldn't that be *fault* reference? - 2.5.1: "A Message Reference component associates to a message exchanged in an operation an XML element declaration that specifies its message content." Tortured English. - 2.5.1: "Message Reference components are identified by the role the message plays in the {message exchange pattern} that the operation is using. That is, a message exchange pattern defines a set /meof placeholder messages that participate in the pattern and assigns them unique names within the pattern." What does this mean? This passage is *very* confusing. - 2.5.1: "element" is used often, but not defined; is this Element Information Item? - 2.6.1: "A Fault Reference component associates a Fault component that defines the fault message type for a fault that occurs related to a message participating in an operation. Fault Reference components are identified by the role the related message plays in the {message exchange pattern} that the operation is using." What? Please have pity on your readers. - 2.6.1: "The purpose of a Fault Reference component is to associate..." Bad English. Try: "A Fault Reference component's purpose is the association of..." - 2.6.2.1: "The ref attribute information item refers to a fault component." Shouldn't this be "*interface* fault component."? - 2.11.1: "Interface Operation components are local to Interface components; they cannot be referred to by QName, despite having both {name} and {target namespace} properties. That is, two Interface components sharing the same {target namespace} property but with different {name} properties MAY contain Interface Operation components which share the same {name} property. Thus, the {name} and {target namespace} properties of the Interface Operation components are not sufficient to form the unique identity of an Interface Operation component. To uniquely identify an Interface Operation component one must first identify the Interface component (by QName) and then identify the Interface Operation within that Interface component (by a further QName)." What is the effect of this statement upon bindings? It doesn't place any direct requirements on them. - 2.13: Shouldn't 2.14 Endpoints come before this section? - 2.13.1: "A Service component describes a set of endpoints (see 2.14 Endpoint) at which the single interface of the service is provided." Circular definition; confusing. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] Editors adopt as much as possible, come back to WG with any that require discussion. |
|||||||
Resolution: Accepted. |
|||||||
209 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Reference frag ids from media type registration | |||||||
Description: [email] - A.1: The "fragment identifiers" section of the media type registration needs to list the mechanism described in C.2. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] accept. |
|||||||
Resolution: Fix the link to point to App C, and associated clarifications to the text. |
|||||||
210 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Refine equivalence algorithm | |||||||
Description: [email] - 2.15: "Two components of the same type are considered equivalent if, for each property, the value in the first component is the same as the value in the second component." Are simple values compared character-by-character? Is any schema information (e.g., defaulting, for canonicalisation) necessary? How are sets compared? Will this work for Properties (which have an associated value)? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Proposals accepted, plus a reference to charmod for string eq. |
|||||||
211 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Omit interface message in binding? | |||||||
Description: [email] - 2.12.1: It seems wasteful to duplicate the interface message into the binding if there is no additional information therein. Can it be omitted with no effect in this case? I.e., the specified properties only serve to identify the message, not to affect the concrete representation of it; it should be explicitly stated that the absence of those properties has no effect on the interpretation of the description. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
212 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Explain using bindings across all operations | |||||||
Description: [email] - 2.11.2: "A REQUIRED ref attribute information item" - this requires all binding operations to refer to corresponding interface operations, despite earlier indications in 2.9.1 that bindings could be specified generically "across all operations of an interface." If that is true, how should one do so? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] I suggest that this requirement was dropped, and guidance given on specifying generic operations. |
|||||||
Resolution: No action |
|||||||
213 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Refine component model property constraints | |||||||
Description: [email] - 2.9.1: In many places in the spec, the semantics and constraints on component properties (e.g., optionality) are described in the Infoset mappings, rather than in the properties themselves. For clarity and applicability to other mappings, it would be better to place them at the component model level. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] I suggest expanding the content model of each component property in the property lists, and removing redundant syntactic constraints from the infoset mappings. Also see email. |
|||||||
Resolution: Accepted. |
|||||||
214 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Refine "properties" terminology | |||||||
Description: [email] - 2.8: The term "properties" is used throughout to denote a part of the component model; this section redefines it as something similar but different. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] Suggest using a distinguished term (perhaps "attributes"?). |
|||||||
Resolution: No action |
|||||||
215 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Clarify rule obviation | |||||||
Description: [email] - 2.4.4: "hence the rules which refer to the output element do not apply." Read literally, this has the (unintended?) effect of obviating the first rule. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
216 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: RPC and XML Schema not orthogonal | |||||||
Description: [email] - 2.4.4: This section implies that you MUST define your messages in XML Schema to use RPC style; such a restriction is not necessary, as long as it is functionally equivalent. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] I suggest rewriting to the effect that other message definitions are allowed, as long as they are functionally equivalent. |
|||||||
Resolution: Proposed resolution accepted, with a friendly amendment not to lose the MUST. |
|||||||
217 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Syntax for multiple styles | |||||||
Description: [email] - 2.4.2.3: The style attribute has a very loose semantic; it seems purpose-built for RPC, and therefore is effectively yet another extensibility mechanism. Also, it is readily imaginable for an operation to have more than one style; e.g., RPC as well as web:method="POST" semantics. Therefore, it needs to be able to carry multiple values; while this could be accommodated by making the value a list of URIs, I suggest it would be better to define this as an rpc-specific attribute with a boolean value (e.g., ext:rpc="1"). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] See Issue 98 resolution. Close without action unless new information is presented (we've already considered and rejected using extension attributes instead of providing a common style attribute extensibility hook. |
|||||||
Resolution: Not reopened, editors will check that multiple styles is on the edtodo list, along with anything else that might have been resolved at the same time. |
|||||||
218 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Justify interface faults. | |||||||
Description: [email] - 2.3.1: Why is it advantageous to define a fault at the Interface level, if it's just repeating information in the operations? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] I suggest either removing this functionality or better motivating it. Concrete proposal. |
|||||||
Resolution: Proposal accepted, including Mark's amendment, plus note that errors are an open set. |
|||||||
219 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Actual value vs. normalized value | |||||||
Description: [email] - Table 2-2 (and elsewhere): What is an "actual value"? Does this imply that it is not the [normalized value]? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] Consistify our info-speak. |
|||||||
Resolution: Determined that actual value is the correct term; we will include or import defn of "actual value" from XML Schema. |
|||||||
220 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Document interface extension semantics | |||||||
Description: [email] - 2.2.1: What are the semantics of interface extension? E.g., how are duplicate operations in the set handled? This is mentioned in a few places, but not comprehensively documented. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
221 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Identify components by URI | |||||||
Description: [email] - 2.1.1: Why are QNames, rather than URIs, used to identify components? If there are good reasons for not using the primary identification mechanism in the Web, they should be documented here, along with caveats as to their use (e.g., if signing content, etc). If not, URIs should be used. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] Close with no action. QNames make WSDL internal references simpler. We provide a mapping to URIs for external use. We don't need to document the rationale of every design decision we've made in the spec. |
|||||||
Resolution: Proposal withdrawn. |
|||||||
222 | Part 1 | Editorial | Closed | Mark Nottingham | |||
Title: Name[space] for the intended semantics | |||||||
Description: [email] - 2.1.1: "an unambiguous name for the intended semantics of the components." -> "an unambiguous name *space* for the intended semantics of the components." (the namespace isn't used as a name on its own, is it?) [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] Accept above edit. |
|||||||
Resolution: Change it from "an unambiguous name for the intended semantics of the components." to "an unambiguous name for the intended semantics of the *collection of * components." |
|||||||
223 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Import/include processing model | |||||||
Description: [email] - 2.1.1: "imported/included" - There needs to be a reference to these processes. Also, the definition of how to arrive at a component model and how to interpret it are intertwined; while it makes sense to specify the semantics and mapping of individual components together, the separation of the import and exclude functionalities is awkward. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] I suggest that the import/include mechanism be documented along with the (expanded) definition of the component model, rather than after the use of that model. An explicit processing model could also be documented there, whereby one can deterministically convert an Infoset into a component model. |
|||||||
Resolution: proposal accepted. |
|||||||
224 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Formalize component model | |||||||
Description: [email] - 2.1.1: The component model is not well-defined; no where is it said that components have properties, nor is are their aspects explained, and the {} notation's significance is not documented. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Mark] I suggest adding a section detailing the principles and notation of the component model. |
|||||||
Resolution: proposal accepted. |
|||||||
225 | Part 1 | Design | Closed | Mark Nottingham | |||
Title: Non-XML type system extensibility. | |||||||
Description: [email] - 2.1.1: "Type system components are element declarations drawn from some type system. They define the [local name], [namespace name], [children] and [attributes] properties of an element information item." This effectively limits web services to an Infoset data model. However, in other places it the document indicated that other data models are allowed by WSDL; which is it? E.g., in 2.5.1: "If a non-XML type system is in use (as considered in 3.2 Using Other Schema Languages) then additional properties would need to be added to the Message Reference Component (along with extensibility attributes to its XML representation) to allow associating such message types with the message reference." What is the benefit of this approach, instead of just using a more neutral reference mechanism (i.e., "content" or "ref" instead of "element") to determine the type of a message? To me, this is a base requirement for WSDL; a good proportion of the content on the Web is NOT most naturally expressed or modeled as an XML Infoset, and even WSDL itself has chosen to specify its data model in a layer above the Infoset (the "Component Model"). Why should the messages WSDL describes be confined to the Infoset, or prejudiced by XMLisms like "element"? I suggest removing any language (such as that above) that requires messages to be modelled as Infosets, and changing attributes named "element" (and similar) to "content" or another, more neutral term. I do not believe that this is a large change, nor is it one that will impact existing implementations greatly, but it will provide great benefit to the Web. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [Jonathan] WG had previously agreed (informally?) that WSDL only describes XML Web services. Other type systems are limited to those that support XML elements. Status quo proposal: reconfirm that decision, and explain the limitations on extensible type systems in the spec. |
|||||||
Resolution: Adopted Proposal 1 and 3, rejected proposal 2. Spec was deemed adequately clear already that <types> holds any type declarations, though {element declarations} holds only those declarations in an Infoset-based type system. |
|||||||
226 | Part 3 | HTTP | Editorial | Closed | Asir | ||
Title: Cross-binding HTTP features | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: WG believes this can be resolved editorially. |
|||||||
Resolution: Accepted. |
|||||||
227 | Part 1 | Editorial | Closed | MarkN | |||
Title: Description of Binding Operation component | |||||||
Description: [email] Part 1, 2.11: "A Binding Operation component describes a concrete binding of a particular operation of an interface to a particular concrete message format." This doesn't hold; the binding operation isn't constrained to a single concrete message format, and also describes protocol details. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: "The Binding Operation component describes the concrete message format(s) and protocol interaction(s) associated with a particular interface operation for a given endpoint." |
|||||||
Resolution: Accepted. |
|||||||
228 | Part 1 | Design | Closed | WG | |||
Title: Should f&p be allowed in more places? | |||||||
Description: [wg discussion relative to issues 157, 167.] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Definitions, Interface Fault, Binding Fault seem to be the only remaining candidates. |
|||||||
Resolution: Add f&p to Interface Faults, Binding Faults, and Fault References. |
|||||||
229 | Part 3 | Design | Closed | WG | |||
Title: useOperationWebMethod | |||||||
Description: [wg discussion relative to issue 169.] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action |
|||||||
230 | Part 1/Part 2 | Editorial | Closed | MarkN | |||
Title: {label} vs. {message label} | |||||||
Description: [email] Part 2 refers to {label} properties, whereas part one uses {message label}; should these be the same? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Editorial: Use {message label} in Part 2. |
|||||||
231 | Part 2 | Editorial | Closed | MarkN | |||
Title: Clarify "patterns" | |||||||
Description: [email] * The draft uses "patterns" and "WSDL patterns" often; suggest either normalising to "WSDL Message Exchange Patterns" or beginning the introduction with "Web Services Description Language (WSDL) message exchange patterns (hereafter, 'patterns')..." [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Begin the introduction with "Web Services Description Language (WSDL) message exchange patterns (hereafter, 'patterns')..." |
|||||||
Resolution: Accepted. |
|||||||
232 | Part 2 | Editorial | Closed | MarkN | |||
Title: Differentiate our MEPs from underlying protocol MEPs | |||||||
Description: [email] * It might be advisable to differentiate the MEPs described here from the messages in underlying protocols (to use SOAP terminology); perhaps "Interface Message Exchange Patterns"? (I don't feel strongly about this, just a suggestion [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
233 | Part 2 | Design | Closed | MarkN | |||
Title: Dynamically override Fault destination? | |||||||
Description: [email] * Can the destination or occurrence of a Fault be overridden dynamically? E.g., can I specify a SOAP header that says "send any faults over there" or "keep that fault to yourself"?) If so, the mechanisms in section 2 should be couched as "Default Fault Generation Rules," or "Default Fault Transmission Rules", with appropriate explanatory text, if the previous suggestion is accepted. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Add informative note in part 2 could describing how various extensions may effect message delivery including delivery of faults |
|||||||
234 | Part 2 | Editorial | Closed | MarkN | |||
Title: Ruleset terminology | |||||||
Description: [email] * Section 2 uses "generation" in reference to Faults, which seems to have a different meaning than in SOAP. When A SOAP Fault is generated, it is not necessarily transmitted on the wire; here, the implication seems to be that it is. Suggest using "Fault transmission," "Fault delivery," or "Fault destination" throughout instead. This would make the first sentences in the section something like: "WSDL patterns specify the destination and transmission of any Faults generated in a message exchange using standard rules. The most common such rules are defined here and referenced by patterns later in this document. A Fault, regardless of the rule in effect, terminates the message exchange it occurs in." [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: fault propagation rulset |
|||||||
Resolution: Accepted. |
|||||||
235 | Part 1/Part 2 | Editorial | Closed | MarkN | |||
Title: Definition of Fault | |||||||
Description: [email] * A short, formal definition of what a Fault is, in WSDL terms, may be useful (not necessarily in this document, but somewhere). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: Add to part one text that relates fault syntax to the semantic of application fault. |
|||||||
Resolution: Proposal accepted. |
|||||||
236 | Part 1 | Editorial | Closed | Umit | |||
Title: MTOM/XOP support | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
237 | Part 3 | Editorial | Closed | Hugo | |||
Title: Editorial issues with Part 3 | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Move pseudo-schema up front. |
|||||||
238 | Part 1 | Editorial | Closed | Sanjiva | |||
Title: Consistent placement of <feature> and <property> | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
239 | Part 1 | Editorial | Closed | Asir | |||
Title: Part 1 Editorial Issues | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
240 | Part 3 | Design | Closed | DaveO | |||
Title: input serialization flexibility | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
241 | Part 2 | Design | Closed | Hugo | |||
Title: AD Feature: HTTP header conflicts | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Indicate error for AD HTTP binding in case of conflict. |
|||||||
242 | Media type description | Design | Closed | Hugo | |||
Title: Binding accepts header and output serialization | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Reference Accepts header meaning (not just value) similarity to Accepts header. |
|||||||
243 | Part 1 | Design | Closed | Asir | |||
Title: Component reference vs. QName | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Proposed resolution adopted. |
|||||||
244 | SOAP 1.1 | Design | Closed | Asir | |||
Title: Decouple SOAP Version from SOAP Binding? | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Agreed. | |||||||
245 | Media type description | Design | Closed | Hugo | |||
Title: Define expectedMediaTypeItem to be RFC 2616 Accepts header | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted the addition of the "q" parameter and the ability to specify "*/*". Items will remain a schema list, easily translated to the comma-separated list of RFC2616. |
|||||||
246 | Part 3 | Design | Closed | Hugo | |||
Title: HTTP binding and interface operation MEP | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Proposed resolution adopted. |
|||||||
248 | Part 1 | Design | Closed | Roberto | |||
Title: Property component's dependency on XML Schema | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Proposed resolution adopted. |
|||||||
249 | Part 3 | Editorial | Closed | Hugo | |||
Title: HTTP binding mismatch and identification missing | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
250 | Part 3 | Design | Closed | Asir | |||
Title: Properties within wsoap:module | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
251 | Part 3 | Editorial | Closed | Asir | |||
Title: Schemas for SOAP and HTTP Binding | |||||||
Description: [email] The schema for SOAP Binding [1] is old and out of sync with Part 3. What is the schemaLocation for the schema for HTTP Binding? [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Editors to update these schemas. |
|||||||
252 | Media type description | Design | Closed | Jonathan | |||
Title: Syntax of media type annotation | |||||||
Description: Should the expected media type be an attribute instead of an appinfo annotation? WG substantially in favor of this if tooling doesn't prevent it. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: We will use attribute syntax, accompanied by an ednote asking for feedback, and pointing this out to the XMLP WG in case they have better evidence that appinfo annotations are supported substantially better than attributes. |
|||||||
253 | Media type description | Editorial | Closed | Bjoern Hoehrmann | |||
Title: Normative/informative reference | |||||||
Description: [email] Please change the document so that it is clear which sections and which references are normative and which are informative. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
254 | Media type description | Editorial | Closed | Bjoern Hoehrmann | |||
Title: Editorial Note uses table markup but no tabular data | |||||||
Description: [email] The document has several sections labeled "Editorial note", these use table markup but do not really contain tabular data, please change the markup to something else, e.g. <dl> or just a <p> with a <strong> leading "Editorial note:". Also note that "Editorial note:" is not a proper table summary (as specified in the summary attribute). [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
255 | Media type description | Editorial | Closed | Bjoern Hoehrmann | |||
Title: Update reference to XML Infoset | |||||||
Description: [email] The xml-infoset reference refers to the first edition of the document, please change it to refer to the second edition. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
256 | Media type description | Editorial | Closed | Bjoern Hoehrmann | |||
Title: Remove the use of charset parameter in example containing text/xml | |||||||
Description: [email] Section 1 has an example "text/xml; charset=utf-16", please change this example to something else, use of text/xml is discouraged and for XML documents using a charset parameter is claimed to be unnecessary and harmful. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Declined, we want to emphasize charset in this example, which is highly recommended should one use text/xml. |
|||||||
257 | Media type description | Editorial | Closed | Bjoern Hoehrmann | |||
Title: Clarify the use of example.org and example.com | |||||||
Description: [email] Section 1.1 states: Namespace names of the general form "http://example.org/..." and "http://example.com/..." represent application or context-dependent URIs [IETF RFC 2396]. Please clarify in the document what you mean here, the statement does not really make sense to me. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Declined. Editors see no reasonable way to improve the statement. |
|||||||
258 | Media type description | Design | Closed | Bjoern Hoehrmann | |||
Title: Namespace name too long and had dates | |||||||
Description: [email] Section 1.1 notes "http://www.w3.org/2004/11/xmlmime" is defined by the document, the namespace URI is too long and it generally makes little sense to put dates into namespaces URIs, please change this at least to e.g. "http://www.w3.org/2004/xmlmime" to be consistent with a wide range of W3C namespaces URIs. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: We will (and already planned to) update the namespace for the final publication. |
|||||||
259 | Media type description | Design | Closed | Bjoern Hoehrmann | |||
Title: Production rules for expectedMediaType | |||||||
Description: [email] Section 2.2 states The value and the meaning of the expectedMediaType attribute is similar to the value allowed for the 'Accept' header defined by HTTP 1.1 specification, Section 14.1 [IETF RFC 2616] and MUST follow the production rules defined in that section. The 'q' parameter defined by HTTP 1.1 specification, Section 3.9 [IETF RFC 2616] is allowed, but other accept-extensions are not allowed. The production rule in RFC 2616 cannot be used here, it is defined in terms of octets while the information item is a sequence of characters. In order to re-use the production rule you would need to define how to map the characters to octets before attempting to match; the alternate solution would be to create a new production rule that is defined in terms of characters. Please change the section so that it is clear what the differences are, you note these are "similar" and cite one difference, but it is not clear to me whether this is the only difference. Please change the section so that it is clear which production rule you actually mean, section 14.1 of RFC 2616 has several. It would seem that you mean the production rule for "Accept", but as that contains "Accept:" you probably don't, so you might mean the Accept production rule without the leading "Accept:" or media-range. Whatever you do, please ensure that parameters can be used, e.g. x:expectedMediaType = 'application/xhtml+xml;profile=http://...'[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: (1) Add a restriction to the paragraph to indicate that "Accept:" prefix is not allowed. This will resolve (a). (2) Use the future resolution for LC 260 [3], to remove/retain the restriction on accept-extensions. (b) (3) Restrict the usage of production rules in RFC2616 to exclude quoted octets, hence restrict the usage of production rules as to only allow CHARs. |
|||||||
260 | Media type description | Design | Closed | Bjoern Hoehrmann | |||
Title: Allow expectedMediaType to specify any XML document | |||||||
Description: [email] It seems that re-using the Accept header syntax here makes it impossible to state that any kind of "XML" is accepted, I however think that this is an important use case for such an attribute. It is often not possible to include XML documents in other XML documents (e.g. if the document has a document type declaration). Using e.g. x:expectedMediaType = 'application/xml' would likely not work as e.g. image/svg+xml does not match. I think the syntax should be extended so that it is possible to express that XML is expected whatever type might be used. This would be useful e.g. for a web service interface to the W3C Markup Validator. The attribute could allow a special string like x:expectedMediaType = 'xml' in place of a media-range, this would allow the W3C Markup Validator to use it like x:expectedMediaType = 'xml, text/html, text/sgml' If accept-extensions continues to be disallowed, please include a rationale for the exclusion in the document. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Remove the restriction to allow accept-extensions. In this manner, extensions may be used to designate groupings, including xml. |
|||||||
261 | Media type description | Design | Closed | Bjoern Hoehrmann | |||
Title: Allow expecteMediaType to contain '*' | |||||||
Description: [email] Section 3.1 states When the expectedMediaType annotation attribute has a wildcard ("*") or a list of acceptable media types, the schema SHOULD require the contentType attribute to be present. This seems to imply that x:expectedMediaType = '*' would be allowed which does not seem to be the case. If the intention is to allow this syntax, please change the definition accordingly, if it is not allowed, please re-word the paragraph to make it clear what you mean." [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accept proposed resolution. |
|||||||
262 | Media type description | Design | Closed | Bjoern Hoehrmann | |||
Title: Value of contentType and the range specified by expectedMediaType | |||||||
Description: [email] Section 3.1 states The value of the contentType attribute, if present, SHOULD be within the range specified by the expectedMediaType annotation attribute, if specified in the schema. It is not clear to me how it is determined whether this requirement has been met. If there is an algorithm, please reference it normatively, or provide your own. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accept proposed resolution. |
|||||||
263 | Media type description | Design | Closed | Bjoern Hoehrmann | |||
Title: Lexical and value space of the attributes and XML schema decl | |||||||
Description: [email] Section 2.1 does not define the lexical or value space of the attribute, it states it is xs:string but it would seem you would rather want to say that this relates to RFC 2616 Content-Type in some way. When fixing this please consider my remarks about the "Accept:" header reference here, too. The XML Schema for the attributes seems overly lax, for example, as currently defined, x:expectedMediaType requires that the string has at least three characters, please change the definition so that a XML Schema Validator can determine conformance of the attribute value as much as possible. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accept. Update the reference so it's clearer, and add a 3-char minimum to the xs:string schema type. |
|||||||
264 | Media type description | Editorial | Closed | Bjoern Hoehrmann | |||
Title: Add NS prefix to all occurences of expecteMediaType and contentType | |||||||
Description: [email] Please add a namespace prefix to all occurences of "expectedMediaType" and "contentType" in the document where you do not specifically refer to the local name of the attribute, this helps to avoid misunderstandings by people not totally namespace-aware and make the document more readable. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
265 | Media type description | Editorial | Closed | Klotz Leigh | |||
Title: Update XOP reference | |||||||
Description: [email] The reference to XOP in this Working Draft http://www.w3.org/TR/2004/WD-xml-media-types-20041102/ is to the Working Draft revision of XOP at http://www.w3.org/TR/2004/WD-xop10-20040209/ and should be to the CR version http://www.w3.org/TR/2004/CR-xop10-20040826/ as it incorporates the xmlmime:contentType attribute defined in this Working Draft. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
266 | Media type description | Design | Closed | John Cowan | |||
Title: How to distinguish between hexBinary and base64Binary in the absence of XML schema | |||||||
Description: [email] The introduction to the 2 November 2004 Last Call WD of "Assigning Media Types to Binary XML" states that XML Schema is not required in order to make use of the xmlmime:contentType attribute. Unfortunately, without type information it is not possible to reliably distinguish between elements with base64 binary and hex binary content: for example, the content "0000" decodes to the octets "0x00 0x00" in hex binary, but "0xD3 0x4D 0x34" in base64 binary. Therefore, either an xmlmime:contentTransferEncoding is required for schema-free operations, or the recommendation should specify the use of xsi:type with the values "xs:base64Binary" and "xs:hexBinary" for use in schema-free operations. I would prefer the latter alternative." [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Add note saying content-type is not sufficient, information to be provided via other mechanism, for example xsi:type |
|||||||
267 | Media type description | Editorial | Closed | Paul Cotton | |||
Title: Bad namespace prefix | |||||||
Description: [email] Table 1. "Prefixes and Namespaces used in this specification" defines the prefix "xmlmime" for the namespace URI "http://www.w3.org/2004/11/xmlmime". This is an invalid namespace prefix since a namespace prefix is not allowed to start with the reserved string "xml". The XML spec says: === Namespace Constraint: Leading "XML" Prefixes beginning with the three-letter sequence x, m, l, in any case combination, are reserved for use by XML and XML-related specifications. ===[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
268 | Media type description | Design | Closed | Larry Masinter | |||
Title: Interop problems with Accept HTTP header | |||||||
Description: [email] I'm suspicious of the attempt to use HTTP "accept" headers to "indicate in XML Schema what media type the character content of an element will have." In practice, HTTP Accept headers have turned out to have severe interoperability problems, and have not been useful for content negotiation. It's a bad practice to try to follow something that hasn't worked for the stated purpose. For example, a description of "image/*" is, in practice, not useful because of the wide variety of image types that are likely *not* implemented. In general, indicating ranges of acceptable media type is quite difficult; the best practice in this area is likely to be either CCPP (www.w3.org/Mobile/CCPP/) or media feature expressions (RFC 2533 plus RFC 2913). However, neither have widespread deployment and interoperability experience. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Reject comment: this facility is not intended for dynamic content negotiation; other solutions are equally bad; this is not a recommendation track and so can be more easily superceded with a better solution if one emerges; if there are specific problems with our spec we're happy to consider them. |
|||||||
269 | Media type description | Editorial | Closed | Larry Masinter | |||
Title: ContentType of media type | |||||||
Description: [email] I think the document suffers from an editorial problem which starts with the title. "text/xml;charset=utf-8" is not a "IANA media type" or a "media type token", it is a "content-type string", the difference being that a content-type string starts with a media type followed by parameters for that type. I think it's important to avoid confusion by careful editing:
|
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
270 | Media type description | Design | Closed | Larry Masinter | |||
Title: Normalization for content-type strings | |||||||
Description: [email] [normalized value]: I think defining a normalization for content-type strings is difficult, and you should avoid it. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: [normalized value] is Infoset speak, and doesn't imply that we're defining a normalization for content-type strings, just that we get the value from the infoset. |
|||||||
271 | Media type description | Design | Closed | Ian Hickson | |||
Title: Why is contentType attribute required? | |||||||
Description: [email] I am confused as to why the mime:contentType attribute is required. It would seem that applications that expect binary content will have to be hardcoded to support the elements in which that content appears anyway, so supporting an attribute on those elements as well seems like it wouldn't require the use of namespaces. As a data point: XLink is used in SVG on elements that refer to external resources, as in <style xlink:href="">. The theory is that by reusing the same attribute for all links, the implementation is somehow able to reuse code. However, in practice, the UAs have to have code for each embedding mechanism, and the attribute doesn't help at all by being in the XLink namespace. So while I can understand that XML Schema may need to be extended to support MIME types as a first-class data type, it would seem that the actual mime:contentType attribute is superfluous. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No change to the spec. The contentType attribute is not required, though the spec recommends it's use. A particular application may not utilize this information, but its presence makes the content more self-describing, which makes the data more reusable and flexible. |
|||||||
272 | Media type description | Design | Closed | Henry Thompson | |||
Title: Architectural issues | |||||||
Description: See [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Reject proposal to define a type hierarchy, as this is not automatically extensible when new media types are defined. No consensus to redesign based on NOTATIONs. |
|||||||
273 | Media type description | Design | Closed | Henry Thompson | |||
Title: Whitespace significance | |||||||
Description: [email] 2a) Using xs:string is almost certainly not what you want -- that makes whitespace variation significant, so that e.g. xmlmime:contentType="image/png " is not the same as xmlmime:contentType="image/png". I would recommend xs:token instead. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accept that leading and trailing whitespace should not cause mismatches. However, xs:token is not the appropriate type because it might turn allowed characters inside quoted strings for parameters (e.g. tabs) into spaces. We will instead say in prose that leading and trailing whitespace should not be considered significant when comparing values. |
|||||||
274 | Media type description | Editorial | Closed | Henry Thompson | |||
Title: IANA Media type token example | |||||||
Description: [email] 2b) Please provide a concrete reference for "IANA media type token". [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
275 | Media type description | Editorial | Closed | Henry Thompson | |||
Title: Error in example 1 | |||||||
Description: [email] 2c) In example 1, you probably mean <xs:restriction base="xmlmime:base64Binary">[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Examples clarified. |
|||||||
276 | Media type description | Editorial | Closed | Henry Thompson | |||
Title: Error in example 4 | |||||||
Description: [email] In example 4, you probably mean <xs:complexType name="JPEGPictureType> <xs:complexContent> <xs:restriction base="xmlmime:base64Binary" xmlmime:expectedMediaType="image/jpeg"/> </xs:complexContent> </xs:complexType>[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Example clarified. |
|||||||
277 | Media type description | Editorial | Closed | Kevin Liu | |||
Title: Add examples | |||||||
Description: See [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted. |
|||||||
278 | Media type description | Design | Closed | Addison Phillips for I18N | |||
Title: I18N Comments: Allow Accept-extensions | |||||||
Description: See [email] 1. section 2.2, "expectedMediaType attribute": is set up much as if it were an "Accept" header, complete with q (quality) values. Accept-extensions are explicitly not permitted, nor are additional content selection attributes provided. We think that it might be important that the remainder of the Accept-* set of content negotiation headers be provided for here. Of particular interest to I18N are the equivalents to HTTP's Accept-Language and Accept-Charset headers. These values may be important in describing in a Web service the preferences or capabilities of the service provisioned at the end point. For example: a Web service that performs spell checks might only support content in a specific language. Or a particular device (such as a mobile phone) might support only a limited range of encodings. The ability to provide meta data about the character of the content that can be sent (either informatively to the end user or because content not matching the value will be rejected) seems like an important capability to consider. Also it is possible to imagine services that will use this information to perform HTTP requests on behalf of the service provider. That is, consider the difference between: <xs:complexType name="PurchaseOrderType" type="xs:base64Binary" xmime:expectedMediaType="application/xml"/> And: <xs:complexType name="PurchaseOrderType" type="xs:base64Binary" xmime:expectedMediaType="application/xml" xmime:acceptLang="ja" xmime:acceptCharset="utf-8, *"/> [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: 2005-03-04: Previously agreed to allow additional accept extensions. |
|||||||
279 | Media type description | Editorial | Closed | Addison Phillips for I18N | |||
Title: I18N Comments: Encourage charset with text/* | |||||||
Description: See [email] 2. section 3. "Declaring media type for binary data": there are two examples in-line in the text (one is image/png and the other is text/xml;charset=utf-16). The XML example is good, in that it uses a charset parameter. However, we note: a. There should be mention that the charset parameter for textual types is STRONGLY RECOMMENDED similar to that in the other binary XML documents. Cf. [1], which says: If the media type identified by the value of an xmime:contentType attribute information item is a text based media type then the value of the xmime:contentType attribute information item SHOULD include a charset parameter. b. There should probably be an example of the charset parameter in use. The examples (quite properly) use a binary image as an example, but it is entirely probable that this mechanism will be used to send content such as HTML or XML documents too. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: 2005-03-04: Agreed to add such a note and example. |
|||||||
280 | Media type description | Editorial | Closed | Addison Phillips for I18N | |||
Title: I18N Comments: xmlmime prefix illegal | |||||||
Description: See [email] 3. We note that the document uses the namespace prefix 'xmlmime'. Isn't this prefix illegal per XML Namespaces (http://www.w3.org/TR/REC-xml-names/#xmlReserved)? Perhaps another prefix should be used, such as 'xmime' as in the quote from [1] above. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: 2005-03-04: Actioned editors to make such a change. |
|||||||
281 | Test Suite | Design | Closed | John Kaputin | |||
Title: WSDL 2.0 test case problems - unknown host & schema visibility | |||||||
Description: [email] This WSDL test case has element references that are prefixed with a namespace that is schema imported within <types>, however the schemaLocation URL cannot be resolved (java.net.UnknownHostException: greath.example.com). A wsdl processor might use a catalog to resolve such a host name, but I guess that's not the objective of this test case. See: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/documents/good/CreditCardFaults-1G/use-credit-card-faults.wsdl <types> <xs:import namespace="http://greath.example.com/2004/schemas/resSvc" schemaLocation="http://greath.example.com/2004/schemas/resSvc.xsd" /> </types> I think there is another problem too. This wsdl imports another wsdl document containing a schema import of "credit-card-faults.xsd". That schema should not be visible to the top level wsdl, unless it imports the schema directly in its <types> element (i.e. if WSDL B xs:imports Schema X and WSDL A wsdl:imports WSDL B, Schema X is not visible to WSDL A. WSDL A must xs:import Schema X directly). However in this test case, the top level wsdl does have element references to that schema's namespace. For this test case to work, I think the top level schema needs to xs:import "credit-card-faults.xsd" in its <types> element. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Already fixed. |
|||||||
282 | RDF Mapping | Design | Closed | Arthur Ryman | |||
Title: Description Component | |||||||
Description: [email] At the F2F today, Jack said that the Description component was not important for the RDF mapping. I think the Description component is important because it acts as a container for top level components. It provides a context. A top level component might be a member of many Description components, e.g. if it gets imported in many contexts. The Description component itself models a component model instance in that it represents a set of related components. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: [email] |
|||||||
Resolution: Proposal accepted - confirmed 2006-01-05. |
|||||||
283 | RDF Mapping | Design | Closed | David Booth | |||
Title: Review of WSDL 2.0 - RDF Mapping: General comments | |||||||
Description: [email]: GENERAL COMMENTS The document thus far only describes the ontology that will be used for the resulting RDF. The mapping itself is still marked as a "to do", so I cannot comment on that. I wonder: Will the mapping be defined in XSLT? That would be really convenient if it is feasible. And if not, I am curious to know why not, since the need to map from the XML world to the RDF world is likely to be increasingly common. The document notes that the customer base for this work product is unclear. However, even apart from its value for direct use, I view this work as a valuable exercise in bridging from XML to RDF. Lessons learned will be helpful to others. The design of the ontology corresponds almost directly to the design of the WSDL 2.0 component model, which makes it easy to understand. The deviations also seem to be straightforward and sensible. In general, the document is written quite clearly. The document clearly says that the ontology is less constraining than the WSDL 2.0 specfication. I wonder: would it be feasible to itemize the constraints that are present in the specification but not enforced by the ontology? To what extent would this be feasible? If it is feasible I think it would provide greater insight into the ontology.[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: No normative XSLT mapping. No to a comprehensive list of unenforced constraints, yes to a general statement that there are unenforced constraints. Confirmed here. |
|||||||
284 | RDF Mapping | Design | Closed | David Booth | |||
Title: Review of WSDL 2.0 - RDF Mapping: Comments by Section | |||||||
Description: [email]: COMMENTS BY SECTION Section 1. Introduction: Good motivation. If the creation of WSDL2.0-->RDF mapping helped to expose unnoticed issues in the WSDL 2.0 definition, that would be good to mention also. Section 2.2 Handling Features, Properties and Generic Extensions: Good overview of WSDL 2.0 extensibility. Section 3. Differences from the WSDL Component Model: I found myself getting confused about whether a paragraph was discussing the RDF that results from mapping a legal WSDL document, versus arbitrary RDF that might be written using the ontology and thus may not correspond to any legal WSDL document. The document as a whole is about the mapping from legal WSDL documents, and thus as a reader I kept expecting to be reading about the RDF that results from mapping a legal WSDL document. Section 3.1 Component naming: Re: "The original names and namespaces are not explicitly modeled in the RDF representation" I found myself wondering which namespace this section was discussing, but I think it is referring to the wsdl:targetNamespace. It would be good to clarify. I notice that in section 3.1 the ontology runs into the issue of the dependency between the meaning of a hash URI and the mime type of the content that is returned from that URI, and thus the need to dereference the URI to determine the mime type. This is exactly the kind of problem I describe in my discussion of how URIs/IRIs should be minted: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0056.html Section 3.2 Documents, imports and includes: I don't understand this sentence: "Strictly speaking, interfaces don't need to belong to any Description, and interface operations don't actually need to belong to any interface in the RDF representation.". Is it referring to your ontology in general or to your mapping? I thought a wsdl:interface MUST belong to a wsdl:description, so I would think that in any RDF resulting from applying the mapping that you describe, each interface *would* belong to a Description and each interface operation *would* belong to an interface. In retrospect, it looks like that sentence is referring to the ontology in general. This is an example of the confusion I mentioned under section 3.1 above. I don't understand the implications of section 3.2. Appendix A: the owl ontology source: I notice that a lot of properties have rdfs:range defined, but not rdfs:domain. I assume this is because these properties could be applied to more than one class. Would it make sense to create some superclasses for these, so that the rdfs:domains can be specified?[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with editorial changes detailed here. |
|||||||
285 | RDF Mapping | Editorial | Closed | David Booth | |||
Title: Review of WSDL 2.0 - RDF Mapping: Editorial comments | |||||||
Description: [email]: s/and that it doesn't mandate/and it doesn't mandate/ s/should also provide URIs/should also provide IRIs/ s/langauges/languages/ This is a key conceptual point: [[ a Z based validator will complain that that representation is ill formed (given the WSDL specification). An OWL reasoner encountering it will, all other things being equal, conclude that there *is* such a property, albeit unknown. ]] The last sentence may be confusing to readers who are not so familiar with the open world assumption. Perhaps the following might be slightly clearer: [[ An OWL reasoner encountering it will, all other things being equal, conclude that there *is* such a property, even though the reasoner has not yet seen it. ]] s/extentions/extensions/ s/WSDL spec prescribes/WSDL specification prescribes/ s/RD representation/RDF representation/ s/may extend other interface/may extend other interfaces/ s/The one notable exception are/The notable exceptions are/[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Accepted, see Jacek's recommendation - confirmed 2006-01-05. |
|||||||
286 | RDF Mapping | Design | Closed | Jacek Kopecky | |||
Title: reusing Part-Whole ontology? | |||||||
Description: [email] this is the first RDF mapping issue that I think deserves the WG attention: Should the RDF mapping use (and/or extend) the simple part-whole relations vocabulary [1] in development by the Semantic Web Best Practices and Deployment Working Group? I see the following options here: 1. not to use the is_part_of properties, i.e. not indicate the part-whole relationship (status quo) 2. use both our own properties and the is_part_of properties (perfectly legal, perhaps somewhat suboptimal, maybe) 3. use the is_part_of* properties between parent components and the components they own and not our properties, 4. use our own properties that also indicate the is_part_of relationship (our properties would be subproperties of is_part_of) (*) technically, it would be is_part_of_directly property from the document [1] I think we need to investigate the status of the part-whole ontology in SWBPD WG first; I can take an action at the first possible opportunity so that I'm pushed to do this.[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Closed with no action, as recorded here. |
|||||||
287 | RDF Mapping | Editorial | Closed | Jacek Kopecky | |||
Title: modularization of the ontology? | |||||||
Description: [email] currently, the RDF mapping mostly uses a single namespace ( http://www.w3.org/2005/10/wsdl-rdf ), except where the URIs are already provided by the WSDL spec, for example MEPs, operation styles, binding types. The issue is - should we adopt some kind of consistent way of naming these namespaces, that would fit the already existing URIs? Probably yes, but if so, what would it look like? Should we split the RDF ontology file into multiple files for these namespaces? I think this is an editorial issue, but I'd like it to be tracked in the issues list so that people can voice opinions easier. 8-)[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Close with no action 3/30/2006. |
|||||||
288 | RDF Mapping | Design | Closed | Jacek Kopecky | |||
Title: WSDL RDF mapping issue: coordination with SOAP WG | |||||||
Description: [email] the RDF mapping currently uses the URI http://www.w3.org/2005/10/wsdl-rdf#SOAPMessageExchangePattern to point to the concept of a SOAP 1.2 message exchange pattern; this URI is WSDL-specific, we should probably request the XMLP WG to coin a URI for us because this concept is clearly in their scope.[Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: use the URI defined by XMLP. |
|||||||
289 | RDF Mapping | Design | Active | Jacek | |||
Title: URIs where we should provide RDF representation | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
290 | Discussion of Alternative Schema Languages | Editorial | Active | Elliotte Rusty Harold | |||
Title: Typo in http://www.w3.org/TR/2005/NOTE-wsdl20-altschemalangs-20050817/ | |||||||
Description: [email]: In the very first sentence, "This document captures the result of discussions by the Web Services Description Working Group regarding WSDL 2.0 type system extensibilty at the time of its publication." should be "This document captures the result of discussions by the Web Services Description Working Group regarding WSDL 2.0 type system extensibility at the time of its publication." That is, extensibility is misspelled. [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: | |||||||
291 | RDF Mapping | Design | Closed | Eric Prud'hommeaux | |||
Title: Comment: wsdl20-rdf should use c14n | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
292 | RDF Mapping | Design | Closed | Eric Prud'hommeaux | |||
Title: Comment: wsdl20-rdf should canonicalize extension attributes | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
293 | RDF Mapping | Design | Closed | Karl Dubost | |||
Title: [selectors-api] Normative/Informative dependencies | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
294 | RDF Mapping | Design | Closed | Karl Dubost | |||
Title: [selectors-api] Class of products | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
295 | RDF Mapping | Design | Closed | Karl Dubost | |||
Title: [selectors-api] Conformance Section | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
296 | RDF Mapping | Design | Closed | Karl Dubost | |||
Title: [selectors-api] Use of normative languages, RFC 2119 | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
297 | RDF Mapping | Design | Closed | Karl Dubost | |||
Title: [selectors-api] Generic Extension Mechanism | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |
|||||||
298 | RDF Mapping | Editorial | Closed | Karl Dubost | |||
Title: [selectors-api] Editorial | |||||||
Description: [email] [Search or Google WG archive for relevant posts.] |
|||||||
Proposal: | |||||||
Resolution: Resolved: accepted. |