- From: Jonathan Marsh <jonathanMarsh@dev.w3.org>
- Date: Wed, 01 Sep 2004 18:50:32 +0000
- To: public-ws-desc-eds@w3.org
Update of /sources/public/2002/ws/desc/issues/last-call
In directory hutz:/tmp/cvs-serv8517/issues/last-call
Modified Files:
concerning.html actions_owner.html actions.html type_sort.html
ack_sort.html validate.html state_sort.html issues.xml
issues.html graph_types.svg originators.html
Log Message:
Added issues up to LC8
Index: originators.html
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/originators.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** originators.html 1 Sep 2004 17:32:29 -0000 1.1
--- originators.html 1 Sep 2004 18:50:30 -0000 1.2
***************
*** 2,6 ****
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><title>WSDL 2.0 Last Call Issues</title><link type="text/css" title="Normal view" rel="stylesheet" media="screen" href="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/issues.css" id="normalLink" /><link type="text/css" title="Hide issues details" rel="alternate stylesheet" media="screen" href="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/originators.css" id="hideLink" /><script src="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/view.js" type="text/javascript"> </script><script src="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/view-originators.js" type="text/javascript"> </script></head><body onload="init()"><!-- ################################################# --><!-- THIS PAGE HAS BEEN GENERATED! DO NOT EDIT! --><!-- ################################################# --><h1><a title="W3C Home" href="http://www.w3.org/"><img border="0" width="72" src="http://www.w3.org/Icons/w3c_home" height="48" alt="W3C" />/a>WSDL 2.0 Last Call Issues</h1><h2>Individual view</h2><map id="outsidenav"><p>
Other views: <a href="issues.html">issues</a> | <a href="graph_types.svg">types</a> | <a href="graph_states.svg">states</a> | <a href="concerning.html">concerning</a> |
! <a href="actions.html">open actions</a></p></map><hr /><p>This list received comments from 0 groups and 1 individual.</p><form action="originators.html" method="get" id="form"><label title="hide issue details"><input id="hideCheckbox" name="hide" value="1" type="checkbox" />Hide issue details</label><input title="Reformat" value="Reformat" type="submit" /></form><h2>Comments from individuals</h2><ol><li>Glen Daniels (gdaniels@sonicsoftware.com)
[1 issue ]<ol class="issues"><li><a href="issues.html#LC1">LC1</a> :
Property Requiredness [open]</li></ol></li></ol><hr /><address><small>Maintained by <a href="http://www.w3.org/2002/ws/desc/">WSDL Working Group</a>.</small></address><p>Last update: $Date$</p><hr /><p>This page was generated as part of the
--- 2,17 ----
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><title>WSDL 2.0 Last Call Issues</title><link type="text/css" title="Normal view" rel="stylesheet" media="screen" href="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/issues.css" id="normalLink" /><link type="text/css" title="Hide issues details" rel="alternate stylesheet" media="screen" href="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/originators.css" id="hideLink" /><script src="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/view.js" type="text/javascript"> </script><script src="http://dev.w3.org/cvsweb/~checkout~/2002/issues/xsl/view-originators.js" type="text/javascript"> </script></head><body onload="init()"><!-- ################################################# --><!-- THIS PAGE HAS BEEN GENERATED! DO NOT EDIT! --><!-- ################################################# --><h1><a title="W3C Home" href="http://www.w3.org/"><img border="0" width="72" src="http://www.w3.org/Icons/w3c_home" height="48" alt="W3C" />/a>WSDL 2.0 Last Call Issues</h1><h2>Individual view</h2><map id="outsidenav"><p>
Other views: <a href="issues.html">issues</a> | <a href="graph_types.svg">types</a> | <a href="graph_states.svg">states</a> | <a href="concerning.html">concerning</a> |
! <a href="actions.html">open actions</a></p></map><hr /><p>This list received comments from 0 groups and 5 individuals.</p><form action="originators.html" method="get" id="form"><label title="hide issue details"><input id="hideCheckbox" name="hide" value="1" type="checkbox" />Hide issue details</label><input title="Reformat" value="Reformat" type="submit" /></form><h2>Comments from individuals</h2><ol><li>Asir Vedamuthu (asirv@webmethods.com)
! [1 issue ]<ol class="issues"><li><a href="issues.html#LC2">LC2</a> :
! Editorial: Issue 177 Implementation [open]</li></ol></li><li>Bijan Parsia (bparsia@isr.umd.edu)
! [2 issues ]<ol class="issues"><li><a href="issues.html#LC3">LC3</a> :
! {namespace name} property [open]</li><li><a href="issues.html#LC4">LC4</a> :
! Table of components/properties [open]</li></ol></li><li>David Booth (dbooth@w3.org)
! [1 issue ]<ol class="issues"><li><a href="issues.html#LC8">LC8</a> :
! Permit URI References instead of URIs [open]</li></ol></li><li>Dominique Haza�l-Massieux (dom@w3.org)
! [3 issues ]<ol class="issues"><li><a href="issues.html#LC5">LC5</a> :
! QA Review on WSDL 2.0 Part 1, intro and conformance issues [open]</li><li><a href="issues.html#LC6">LC6</a> :
! QA Review on WSDL 2.0 Part 1, Technical comments [open]</li><li><a href="issues.html#LC7">LC7</a> :
! QA Review on WSDL 2.0 Part 1, Editorial comments [open]</li></ol></li><li>Glen Daniels (gdaniels@sonicsoftware.com)
[1 issue ]<ol class="issues"><li><a href="issues.html#LC1">LC1</a> :
Property Requiredness [open]</li></ol></li></ol><hr /><address><small>Maintained by <a href="http://www.w3.org/2002/ws/desc/">WSDL Working Group</a>.</small></address><p>Last update: $Date$</p><hr /><p>This page was generated as part of the
Index: issues.html
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/issues.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** issues.html 1 Sep 2004 17:40:16 -0000 1.2
--- issues.html 1 Sep 2004 18:50:30 -0000 1.3
***************
*** 6,13 ****
| <a href="#detailsList">Issue details</a>
(<a href="http://www.w3.org/2001/03/webdata/xsv?docAddrs=http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/last-call/issues.xml&warnings=on&keepGoing=on&style=xsl">Validate data</a>)
! </p></map><p>List and dispositions of issues recorded against:</p><ul><a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/">Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</a>.<a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions</a>.<a href="http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings</a>.</ul><p>Issues list for other deliverables of the WG can be found on the
<a href="http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html">WS Description WG Issues List</a>.</p><h2>Status of this Document</h2><p>This document is a live document and can change at any time, in particular to update the
status of issues may change over time.</p><div class="summary"><h2><a name="summaryList" id="summaryList">Issue summary</a>
! (1 issues)
</h2><form action="issues.html" method="get" id="form"><fieldset><legend accesskey="4">Reformat summary with options</legend><label for="view" title="Select a view">Highlight for</label>:
<select id="view" name="view"><option id="normalOption" value="normal">Normal</option><option id="directorOption" value="director">Director</option><option id="wgOption" value="wg">Working group</option></select><input title="Reformat" value="Reformat" type="submit" /><div><label title="closed issues"><input id="closedCheckbox" name="closed" value="1" type="checkbox" /> Show open issues only</label><label title="Expert mode"><input id="expertCheckbox" name="expert" value="1" type="checkbox" /> Expert mode</label></div><fieldset class="expertMode"><legend accesskey="5">Expert mode options</legend><div>
--- 6,13 ----
| <a href="#detailsList">Issue details</a>
(<a href="http://www.w3.org/2001/03/webdata/xsv?docAddrs=http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/last-call/issues.xml&warnings=on&keepGoing=on&style=xsl">Validate data</a>)
! </p></map><p>List and dispositions of issues recorded against:</p><ul><li><a href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/">Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</a>.</li><li><a href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions</a>.</li><li><a href="http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings</a>.</li></ul><p>Issues list for other deliverables of the WG can be found on the
<a href="http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html">WS Description WG Issues List</a>.</p><h2>Status of this Document</h2><p>This document is a live document and can change at any time, in particular to update the
status of issues may change over time.</p><div class="summary"><h2><a name="summaryList" id="summaryList">Issue summary</a>
! (8 issues)
</h2><form action="issues.html" method="get" id="form"><fieldset><legend accesskey="4">Reformat summary with options</legend><label for="view" title="Select a view">Highlight for</label>:
<select id="view" name="view"><option id="normalOption" value="normal">Normal</option><option id="directorOption" value="director">Director</option><option id="wgOption" value="wg">Working group</option></select><input title="Reformat" value="Reformat" type="submit" /><div><label title="closed issues"><input id="closedCheckbox" name="closed" value="1" type="checkbox" /> Show open issues only</label><label title="Expert mode"><input id="expertCheckbox" name="expert" value="1" type="checkbox" /> Expert mode</label></div><fieldset class="expertMode"><legend accesskey="5">Expert mode options</legend><div>
***************
*** 26,31 ****
<span class="key error">error</span> <span class="key warning">warning</span> <span class="key note">note</span></p><table><tbody><tr><th class="title">
Id:Title
! </th><th class="state"><a href="state_sort.html">State</a></th><th class="type"><a href="type_sort.html">Type</a></th><th class="decision"><a href="ack_sort.html">Ack.</a></th></tr><tr class="issue open proposal state-agreed ack-noreply"><td class="title"><a href="#LC1">LC1</a> :
! Property Requiredness</td><td class="state decided agreed">agreed</td><td class="type">proposal</td><td class="decision agreed noreply">No reply from reviewer</td></tr></tbody></table></div><div class="documentation"><div class="state"><h2><a name="state" id="state">State description</a></h2><ul><li><a name="state_raised" id="state_raised">Raised</a>:
Initial state; The group has not accepted the issue yet.
</li><li><a name="state_accepted" id="state_accepted">Accepted</a>:
--- 26,38 ----
<span class="key error">error</span> <span class="key warning">warning</span> <span class="key note">note</span></p><table><tbody><tr><th class="title">
Id:Title
! </th><th class="state"><a href="state_sort.html">State</a></th><th class="type"><a href="type_sort.html">Type</a></th><th class="decision"><a href="ack_sort.html">Ack.</a></th></tr><tr class="issue open error state-agreed ack-noreply"><td class="title"><a href="#LC1">LC1</a> :
! Property Requiredness</td><td class="state decided agreed">agreed</td><td class="type">error</td><td class="decision agreed noreply">No reply from reviewer</td></tr><tr class="issue open clarification state-nodecision"><td class="title"><a href="#LC2">LC2</a> :
! Editorial: Issue 177 Implementation</td><td class="state raised">no decision<br />(raised)</td><td class="type">clarification</td><td class="decision"><!--empty--></td></tr><tr class="issue open editorial state-nodecision"><td class="title"><a href="#LC3">LC3</a> :
! {namespace name} property</td><td class="state raised">no decision<br />(raised)</td><td class="type">editorial</td><td class="decision"><!--empty--></td></tr><tr class="issue open editorial state-nodecision"><td class="title"><a href="#LC4">LC4</a> :
! Table of components/properties</td><td class="state raised">no decision<br />(raised)</td><td class="type">editorial</td><td class="decision"><!--empty--></td></tr><tr class="issue open clarification state-nodecision"><td class="title"><a href="#LC5">LC5</a> :
! QA Review on WSDL 2.0 Part 1, intro and conformance issues</td><td class="state raised">no decision<br />(raised)</td><td class="type">clarification</td><td class="decision"><!--empty--></td></tr><tr class="issue open error state-nodecision"><td class="title"><a href="#LC6">LC6</a> :
! QA Review on WSDL 2.0 Part 1, Technical comments</td><td class="state raised">no decision<br />(raised)</td><td class="type">error</td><td class="decision"><!--empty--></td></tr><tr class="issue open editorial state-nodecision"><td class="title"><a href="#LC7">LC7</a> :
! QA Review on WSDL 2.0 Part 1, Editorial comments</td><td class="state raised">no decision<br />(raised)</td><td class="type">editorial</td><td class="decision"><!--empty--></td></tr><tr class="issue open clarification state-nodecision"><td class="title"><a href="#LC8">LC8</a> :
! Permit URI References instead of URIs</td><td class="state raised">no decision<br />(raised)</td><td class="type">clarification</td><td class="decision"><!--empty--></td></tr></tbody></table></div><div class="documentation"><div class="state"><h2><a name="state" id="state">State description</a></h2><ul><li><a name="state_raised" id="state_raised">Raised</a>:
Initial state; The group has not accepted the issue yet.
</li><li><a name="state_accepted" id="state_accepted">Accepted</a>:
***************
*** 80,84 ****
prose and the model.</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0319.html">raised</a> on 26 Jul 2004 by Glen Daniels (gdaniels@sonicsoftware.com)</dt><dd /><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0056.html">agreed</a> on 4 Aug 2004</dt><dd><p>RESOLUTION: to remove the required flag on
property element and make appropriate changes
! to the component model.</p><h5>Acknowledgment cycle</h5><dl><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0000.html">announced by group on 1 Sep 2004</a></dt></dl></dd></dl></div></div><hr /><address><small>Maintained by <a href="http://www.w3.org/2002/ws/desc/">WSDL Working Group</a>.</small></address><p>Last update: $Date$</p><hr /><p>This page was generated as part of the
<a href="http://www.w3.org/2003/12/exit/">Extensible Issue
Tracking System (ExIT)</a></p><p class="copyright"><a href="/Consortium/Legal/ipr-notice#Copyright" rel="Copyright">Copyright</a> ©
--- 87,404 ----
prose and the model.</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0319.html">raised</a> on 26 Jul 2004 by Glen Daniels (gdaniels@sonicsoftware.com)</dt><dd /><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0056.html">agreed</a> on 4 Aug 2004</dt><dd><p>RESOLUTION: to remove the required flag on
property element and make appropriate changes
! to the component model.</p><h5>Acknowledgment cycle</h5><dl><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0000.html">announced by group on 1 Sep 2004</a></dt></dl></dd></dl></div><div class="issue"><h3><a name="LC2" id="LC2">LC2</a>: Editorial: Issue 177 Implementation [<a href="issues.html#LC2">link to this issue</a>]</h3><pre>ref: issue 177 [1]
!
! On July 8th, we adopted [2] Jonathan's proposal [3]. I have one editorial
! issue with 177 implementation.
!
! The types of the following properties in Part 3, SOAP Binding, are defined
! using prose instead of wsdls:* types. I request the following property-type
! associations,
!
! {soap underlying protocol} => wsdls:anyURI
! SOAP Module.{uri} => wsdls:anyURI
! SOAP Module.{required} => wsdls:boolean
! {soap fault code} => wsdls:QName
! {soap fault subcodes} => list of wsdls:QName
! {soap mep} => wsdls:anyURI
! {soap action} => wsdls:anyURI
!
! Rationale
!
! (a) Consistent with Part 1 and HTTP Binding
! (b) Otherwise, we will be using two similar types (xs:QName vs. wsdls:QName)
! in the component model
! (c) Equivalence in Part 1 is defined using wsdl simple types
! (d) Part 3 is refuting Part 1 claim, "The component model uses a small set
! of predefined simple types, such as boolean, string, token. In order to
! avoid introducing a dependency on any particular serialization of the
! component model, this specification provides its own definition of those
! types" [5]
!
! [1]
! http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x177
! [2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0109.html
! [3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0258.html
! [4]
! http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
! type=text/html;%20charset=utf-8#string_type
! [5]
! http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
! type=text/html;%20charset=utf-8#simpletypes</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0006.html">raised</a> on 2 Aug 2004 by Asir Vedamuthu (asirv@webmethods.com)</dt><dd /></dl></div><div class="issue"><h3><a name="LC3" id="LC3">LC3</a>: {namespace name} property [<a href="issues.html#LC3">link to this issue</a>]</h3><pre>"2.18 QName resolution
!
! In its serialized form WSDL makes significant use of references between
! components. Such references are made using the Qualified Name, or
! QName, of the component being referred to. QNames are a tuple,
! consisting of two parts; a namespace name and a local name. For
! example, in the case of an Interface component, the namespace name is
! represented by the {namespace name} property and the local name is
! represented by the {name} property."
!
! I can't find any {namespace name} *property* (component). Perhaps it is
! the {targetNamespace}?
!
! I see lots of references to [namespace name] Infoset properties.
!
! Ah, I see in 2.17:
!
! "Within a symbol space, all qualified names (that is, the combination
! of {name} and {target namespace} properties) are unique. Between symbol
! spaces, the combination of these two properties need not be unique.
! Thus it is perfectly coherent to have, for example, a binding and an
! interface that have the same name."
!
! This suggests that it is {targetNamespace}.</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0011.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC4" id="LC4">LC4</a>: Table of components/properties [<a href="issues.html#LC4">link to this issue</a>]</h3><pre>I would find a table/index of components and
! component properties very handy (perhaps in the Primer).
!
! (E.g., something like:
! http://www.w3.org/TR/owl-ref/#appA)
!
! Whoa, they liked it so much that the did it twice:
! http://www.w3.org/TR/2004/REC-owl-guide-20040210/#TermIndex
!
! If people thought it was worth having, I'd volunteer to compile such an
! index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC5" id="LC5">LC5</a>: QA Review on WSDL 2.0 Part 1, intro and conformance issues [<a href="issues.html#LC5">link to this issue</a>]</h3><pre>Conformance issues (these comments have been mostly inspired from specGL
! [4]):
!
! a) Document conformance
! http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
! "Note that the WSDL language is defined in terms of the component model
! defined by this specification. As such, it is explicitly NOT a
! conformance requirement to be able to process documents encoded in a
! particular version of XML, in particular XML 1.1 [XML 1.1]." is both
! very hard to read, and probably in contradiction with the header
! "document conformance"; I guess this needs clarification
! It is particularly unclear to me that defining conformance for an
! "element information item" has any sense at all.
!
! b) Also, section 1.2 ("Notational conventions") adds the definition of
! "valid/not valid WSDL document", with important conformance
! requirements. I suggest it should be moved to the conformance section,
! and the normative schema should be referenced from there. Additionally,
! while using the content-negotiated URI as a namespace URI is a good
! idea, I suggest referring explicitly the schema URI (with the .xsd
! extension) would be better when talking about the schema itself.
!
! c) it would be interesting to list (maybe in an appendix) what
! constraints are not translated in the provided XML Schema
!
! c) Processor conformance
! http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
! """This section defines a class of conformant WSDL processors that are
! intended to act on behalf of a party that wishes to make use of a Web
! service"""
! I suggest that you give a specific label to this class of WSLD
! processors, � la "WSDL 2.0 requesting processor" - you'll probably find
! something better.
!
! e) "a conformant WSDL processor MUST accept any legal WSDL document":
! what is a legal WSDL document? I suggest saying "conformant WSDL
! document" - but I'm still unclear whether you define that at all in the
! section above
!
! f) you use both the expressions "a processor MUST fault" and "a processor
! MUST fail"; do they mean the same thing? In any case, I think you should
! clarify what is meant by those (i.e. what consist failing/faulting in?),
! and if they mean the same thing, only use one of the expressions; also,
! since the name 'fault' is used in a very well defined context in the
! spec, I think you should avoid using the verb 'fault' unless it relates
! to the said context; more generally, I think developing the notion of
! error handling for a WSDL processor would be benefitial
!
! g) "a conformant WSDL processor MUST either agree to fully abide": I
! think this an abusive usage of MUST, since "agreeing" is not an
! operation that a WSDL process does; I would suggest "a conformance WSDL
! processor MUST immediately cease processing (fault) if it doesn't agree
! to fully abide ...."
!
! h) "that it does not choose to implement." -> "it chooses not to
! implement", or maybe "it doesn't implement"
!
! i) the "Note:" under this defines conformance requirements for a provider
! agent, which is out of scope for the given section; I suggest creating a
! different section, even if that's the only requirement for it
!
! j) the section 6.1 on mandatory extensions adds requirements both for
! requesting and providing processors; most are duplicated in the
! conformance section, but I think a few are not (e.g. "the provider agent
! MUST support every extension, Feature or Property that is declared as
! optional in the WSDL document"); I suggest they should be added to the
! conformance section
! http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
!
! k) likewise, section 4.1 makes a suggestion for processors:
! "Processors are encouraged to keep track of the source of component
! definitions, so that multiple, mutual, and circular includes do not
! require establishing identity on a component-by-component basis."
! http://www.w3.org/TR/2004/WD-wsdl20-20040803/#includes
! Maybe this could be added as a SHOULD in the conformance section
!
! l) section 1.1 reads "All parts of this specification are normative, with
! the EXCEPTION of notes, pseudo-schemas, examples, and sections
! explicitly marked as "Non-Normative"."; some of the "Note:"s include
! normative-like language, e.g.
! "Support for the W3C XML Schema Description Language [XML Schema:
! Structures],[XML Schema: Datatypes] is required of all processors."
! or
! "If a WSDL document declares an extension or feature as optional, then
! if that extension or feature could apply to messages sent by the
! provider agent as well, then the provider agent MUST NOT send any
! messages that requires the requester agent to support that extension or
! feature."
! Please fix.
!
! 4. http://www.w3.org/TR/qaframe-spec/
! </pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0000.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>a) the {name} property of the feature and property component uses URIs,
! while all the other {name} properties use QNames; I guess my preference
! would be to have all the {name} properties be URIs, but at the very
! least, I find it confusing to have this inconsistency in the model:
! what's the reasoning behind it? maybe instead of using {name} for those,
! you should use {identifier}?
!
! b) is there any reason why the {value constraint} in properties
! components (2.8) is represented in XML as an element rather than an
! attribute? given its content model (xs:QName), an attribute would look
! more "natural" (and more in-line with the other representations in WSDL)
!
! c) purely cosmetic: why 'wsdlLocation' as attribute name, rather than
! simply 'Location', since the attribute is namespace qualified (in wsdli:
! ) ?
!
! d) C.2 defines fragment identifiers compatible with the XPointer
! Framework; I suspect this means you're defining a new scheme for
! XPointer, in which case this should be said explicitly; also, it would
! probably be wise to mention that at the time of this document, only the
! application/wsdl+xml MIME-type references this scheme as a possible
! xpointer scheme - i.e., I don't think a WSDL resource served as
! application/xml can ben resolved using this XPointer scheme
! </pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0001.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! a) section 1.3 (WSDL terminology) has only one item; I would find
! surprising that this specification only defines one new concept; e.g. a
! 'Web Service Component' would probably deserve to be defined here;
! also, linking to the WS Glossary may be a good idea
!
! b) section 2's title is "Component Model" and uses these phrases a few
! times, but doesn't define it
!
! c) section 2 has most of the meaty stuff (the component model), but it is
! somewhat diluted by the XML serialization formalism; I wonder if moving
! the XML serialization in a different section (or in an appendix) would
! enhance the readability of the spec;
!
! d) I suggest marking up and styling appropriately (or maybe
! capitalizing?) words that are used in a very specific way in the
! specification; e.g. in 2.1.1 "At the abstract level, the Definitions
! component is just a container for two categories of components; WSDL
! components and type system components." would better read IMHO as "At
! the abstract level, the Definitions Component is just a container for
! two categories of component: WSDL Components and Type System Components"
! (I used capitalization in this case, but italicizing may work better).
!
! e) the document introduction still calls Part 2 "Message Exchange
! Patterns", although it's now called Predefined extensions
!
! f) the document refers to the language as "WSDL"; since WSDL has been
! available in several versions, I suggest using "WSDL 2.0" instead - if
! not everywhere, at least in the introduction
!
! g) in 2.1.1 "Note that it is RECOMMENDED that the value of the
! targetNamespace attribute information item SHOULD be a dereferencible
! URI and that it resolve to a WSDL document which provides service
! description information for that namespace"; the "SHOULD" is not needed
! since the sentence is preceded by "RECOMMENDED"
!
! h) I suggest linking the XPointer scheme definition for WSDL (appendix C)
! from section 2.1.1., where dereferenceability of components is mentioned
!
! i) there are only 2 examples of complete WSDL definitions in the whole
! spec (one in an appendix); adding a few simple examples in the course of
! the spec may help the reader a bit more; more generally, having a bit
! more illustrations of what WSDL is about would help [I see that a primer
! is in preparation; still, I don't think a few included examples would
! hurt]
! Also, the first example (in 2.7.1.1.1) should declare that <definitions>
! (and its children) are in the WSDL namespace
! The second example (in C.4) uses a relative URI as its
! xsi:schemaLocation; any reason to use "wsdl20.xsd" instead of
! "http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
!
! j) section 2.2.2.3 introduces the notion of style, which is only
! explained later in 2.4.1.1; would be good to make a link from the former
! to the latter
!
! k) section 2.4.2 reads "If the Interface Operation component uses a
! {message exchange pattern} for which there is no output element, such as
! 'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
! paragraph above "The RPC style MUST NOT be used for Interface Operation
! components whose {message exchange pattern} property has a value other
! than 'http://www.w3.org/2004/08/wsdl/in-only' or
! 'http://www.w3.org/2004/08/wsdl/in-out'.", this should not be "such as",
! but "i.e."; or did I miss something?
!
! l) 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
! what is AII? "be" is repeated twice
! thereafter, it uses the notion of a function signature, without much
! introduction; since "RPC" is never translated into "Remote Procedure
! Call", it looks a bit awkward
!
! m) in section 2.5.1 "by the global element declaration reference by the
! {element} property.", "reference" should read "referenced"
!
! n) section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
! the model described in 2.8.1 where {required} is REQUIRED
!
! o) 2.17, "the combination of these two properties need not be unique" ,
! "need" should read "needs"
!
! p) in section 3, "W3C XML Schema Description Language" isn't a proper way
! to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
! language'
!
! q) section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
! IT'S NOT
!
! r) the document references XML 1.0 Second Edition, while the third has
! been published earlier this year
!
! s) it also references outdated versions of XML Infoset and WebArch (see
! [1])
!
! t) the table of contents should use real markup, rather than &nsbp;; I've
! provided a patch to xmlspec for this purpose [2]
!
! u) a few typos: "compomnent", "dereferencible" (should be dereferenceable
! AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
! spell checker [3]
!
! 1. TR references checker:
! http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2004%2F07%2Freferences-checker&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252F2004%252FWD-wsdl20-20040803%252F&
! 2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
! 3.
! http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0002.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC8" id="LC8">LC8</a>: Permit URI References instead of URIs [<a href="issues.html#LC8">link to this issue</a>]</h3><pre>In sections 2.7 and 2.8, we use URIs to identify Features and
! Properties. For example, section 2.7.1 says:
! [[
! {name} REQUIRED. A wsdls:anyURI as defined in 2.15.4 anyURI Type.
! ]]
! and anyURI is defined as:
! [[
! 2.15.4 anyURI Type
! The value space of the wsdls:anyURI type consists of all Uniform
! Resource Identifiers (URI) as defined by [IETF RFC 2396] and amended by
! [IETF RFC 2732].
! ]]
!
! I think we should allow these to be URI References instead restricting
! them to be only URIs. (I.e., allow them to contain fragment
! identifiers.) That would permit multiple, related Features or
! Properties to be described in the same document, using different
! fragment identifiers to distinguish them, such as:
!
! http://example.org/my_related_features_and_properties#a
! http://example.org/my_related_features_and_properties#b
! http://example.org/my_related_features_and_properties#c
!
! This would also allow conformance to the practice that some recommend
! for the Semantic Web, of using fragment identifiers when identifying
! things that are not documents, such as abstract concepts.</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0021.html">raised</a> on 27 Aug 2004 by David Booth (dbooth@w3.org)</dt><dd /></dl></div></div><hr /><address><small>Maintained by <a href="http://www.w3.org/2002/ws/desc/">WSDL Working Group</a>.</small></address><p>Last update: $Date$</p><hr /><p>This page was generated as part of the
<a href="http://www.w3.org/2003/12/exit/">Extensible Issue
Tracking System (ExIT)</a></p><p class="copyright"><a href="/Consortium/Legal/ipr-notice#Copyright" rel="Copyright">Copyright</a> ©
Index: graph_types.svg
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/graph_types.svg,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** graph_types.svg 1 Sep 2004 17:32:29 -0000 1.1
--- graph_types.svg 1 Sep 2004 18:50:30 -0000 1.2
***************
*** 16,18 ****
stroke-width: 1; stroke: black; stroke-dasharray: 5 2;
}
! </style><g class="graphic-title"><text y="20" x="320" style="text-anchor: middle;">WSDL 2.0 Last Call Issues</text></g><g transform="translate(0, 45)"><g class="graphic-frame"><line y2="376" x2="40" y1="5" x1="40"/><line y2="5" x2="620" y1="5" x1="40" class="graphic-percentage"/><text y="10" x="30" style="text-anchor: end;">100%</text><line y2="190" x2="620" y1="190" x1="40" class="graphic-percentage"/><text y="195" x="30" style="text-anchor: end;">50%</text><line y2="376" x2="620" y1="376" x1="40"/><text y="380" x="30" style="text-anchor: end;">0%</text></g><g id="data"><g transform="translate(63, 375)"><rect height="0" width="95" y="-0" x="0" fill="rgb(1,256,256)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">editorial</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(0)</text></g><g transform="translate(173, 375)"><rect height="0" width="95" y="-0" x="0" fill="rgb(53,206,206)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-ata">clarification</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(0)</text></g><g transform="translate(283, 375)"><rect height="0" width="95" y="-0" x="0" fill="rgb(105,156,156)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">error</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(0)</text></g><g transform="translate(393, 375)"><rect height="370" width="95" y="-370" x="0" fill="rgb(157,106,106)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">proposal</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(1)</text></g><g transform="translate(503, 375)"><rect height="0" width="95" y="-0" x="0" fill="rgb(209,56,56)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">request</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(0)</text></g></g></g></svg>
\ No newline at end of file
--- 16,18 ----
stroke-width: 1; stroke: black; stroke-dasharray: 5 2;
}
! </style><g class="graphic-title"><text y="20" x="320" style="text-anchor: middle;">WSDL 2.0 Last Call Issues</text></g><g transform="translate(0, 45)"><g class="graphic-frame"><line y2="376" x2="40" y1="5" x1="40"/><line y2="5" x2="620" y1="5" x1="40" class="graphic-percentage"/><text y="10" x="30" style="text-anchor: end;">100%</text><line y2="190" x2="620" y1="190" x1="40" class="graphic-percentage"/><text y="195" x="30" style="text-anchor: end;">50%</text><line y2="376" x2="620" y1="376" x1="40"/><text y="380" x="30" style="text-anchor: end;">0%</text></g><g id="data"><g transform="translate(63, 375)"><rect height="139" width="95" y="-139" x="0" fill="rgb(1,256,256)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">editorial</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(3)</text><line y2="-139" x2="0" y1="-139" x1="-23" class="graphic-data-percentage"/><text y="-134" x="-33" class="graphic-data-percentage" style="text-anchor: end;">38%</text>/g><g transform="translate(173, 375)"><rect height="139" width="95" y="-139" x="0" fill="rgb(53,206,206)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">clarification</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(3)</text><line y2="-139" x2="0" y1="-139" x1="-133" class="graphic-data-percentage"/><text y="-134" x="-143" class="graphic-data-percentage" style="text-anchor: end;">38%</text></g><g transform="translate(283, 375)"><rect height="93" width="95" y="-93" x="0" fill="rgb(105,156,156)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">error</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(2)</text><line y2="-93" x2="0" y1="-93" x1="-243" class="graphic-data-percentage"/><text y="-88" x="-253" class="graphic-data-percentage" style="text-anchor: end;">25%</text></g><g transform="translate(393, 375)"><rect height="0" width="95" y="-0" x="0" fill="rgb(157,106,106)"/><text y="15" x="47.5" style="txt-anchor: middle;" class="graphic-data">proposal</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(0)</text></g><g transform="translate(503, 375)"><rect height="0" width="95" y="-0" x="0" fill="rgb(209,56,56)"/><text y="15" x="47.5" style="text-anchor: middle;" class="graphic-data">request</text><text y="30" x="47.5" style="text-anchor: middle;" class="graphic-data">(0)</text></g></g></g></svg>
\ No newline at end of file
Index: type_sort.html
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/type_sort.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** type_sort.html 1 Sep 2004 18:30:35 -0000 1.3
--- type_sort.html 1 Sep 2004 18:50:30 -0000 1.4
***************
*** 105,109 ****
[4]):
! * Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
"Note that the WSDL language is defined in terms of the component model
--- 105,109 ----
[4]):
! a) Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
"Note that the WSDL language is defined in terms of the component model
***************
*** 116,120 ****
"element information item" has any sense at all.
! * Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
--- 116,120 ----
"element information item" has any sense at all.
! b) Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
***************
*** 124,131 ****
extension) would be better when talking about the schema itself.
! * it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
! * Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
--- 124,131 ----
extension) would be better when talking about the schema itself.
! c) it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
! c) Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
***************
*** 136,145 ****
something better.
! * "a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above
! * you use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
--- 136,145 ----
something better.
! e) "a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above
! f) you use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
***************
*** 150,154 ****
error handling for a WSDL processor would be benefitial
! * "a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
--- 150,154 ----
error handling for a WSDL processor would be benefitial
! g) "a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
***************
*** 156,167 ****
to fully abide ...."
! * "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
! * the "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it
! * the section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
--- 156,167 ----
to fully abide ...."
! h) "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
! i) the "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it
! j) the section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
***************
*** 171,175 ****
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
! *likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
--- 171,175 ----
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
! k) likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
***************
*** 178,182 ****
Maybe this could be added as a SHOULD in the conformance section
! * section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
--- 178,182 ----
Maybe this could be added as a SHOULD in the conformance section
! l) section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
***************
*** 252,269 ****
If people thought it was worth having, I'd volunteer to compile such an
index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! - section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
! - section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
! - section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
! - I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
--- 252,269 ----
If people thought it was worth having, I'd volunteer to compile such an
index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! a) section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
! b) section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
! c) section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
! d) I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
***************
*** 274,285 ****
(I used capitalization in this case, but italicizing may work better).
! - the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
! - the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
! - in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
--- 274,285 ----
(I used capitalization in this case, but italicizing may work better).
! e) the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
! f) the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
! g) in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
***************
*** 287,294 ****
since the sentence is preceded by "RECOMMENDED"
! - I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
! - there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
--- 287,294 ----
since the sentence is preceded by "RECOMMENDED"
! h) I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
! i) there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
***************
*** 302,310 ****
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
! - section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
! - section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
--- 302,310 ----
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
! j) section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
! k) section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
***************
*** 315,319 ****
but "i.e."; or did I miss something?
! - 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
--- 315,319 ----
but "i.e."; or did I miss something?
! l) 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
***************
*** 321,350 ****
Call", it looks a bit awkward
! - in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
! - section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
! - 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
! - in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
! - section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
! - the document references XML 1.0 Second Edition, while the third has
been published earlier this year
! - it also references outdated versions of XML Infoset and WebArch (see
[1])
! - the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
! - a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
--- 321,350 ----
Call", it looks a bit awkward
! m) in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
! n) section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
! o) 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
! p) in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
! q) section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
! r) the document references XML 1.0 Second Edition, while the third has
been published earlier this year
! s) it also references outdated versions of XML Infoset and WebArch (see
[1])
! t) the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
! u) a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
***************
*** 354,358 ****
2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
3.
! http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0002.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>- the {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
--- 354,358 ----
2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
3.
! http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0002.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>a) the {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
***************
*** 361,374 ****
you should use {identifier}?
! - is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)
! - purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
! - C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
--- 361,374 ----
you should use {identifier}?
! b) is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)
! c) purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
! d) C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
Index: state_sort.html
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/state_sort.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** state_sort.html 1 Sep 2004 18:30:35 -0000 1.3
--- state_sort.html 1 Sep 2004 18:50:30 -0000 1.4
***************
*** 105,109 ****
[4]):
! * Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
"Note that the WSDL language is defined in terms of the component model
--- 105,109 ----
[4]):
! a) Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
"Note that the WSDL language is defined in terms of the component model
***************
*** 116,120 ****
"element information item" has any sense at all.
! * Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
--- 116,120 ----
"element information item" has any sense at all.
! b) Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
***************
*** 124,131 ****
extension) would be better when talking about the schema itself.
! * it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
! * Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
--- 124,131 ----
extension) would be better when talking about the schema itself.
! c) it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
! c) Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
***************
*** 136,145 ****
something better.
! * "a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above
! * you use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
--- 136,145 ----
something better.
! e) "a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above
! f) you use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
***************
*** 150,154 ****
error handling for a WSDL processor would be benefitial
! * "a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
--- 150,154 ----
error handling for a WSDL processor would be benefitial
! g) "a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
***************
*** 156,167 ****
to fully abide ...."
! * "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
! * the "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it
! * the section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
--- 156,167 ----
to fully abide ...."
! h) "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
! i) the "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it
! j) the section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
***************
*** 171,175 ****
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
! *likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
--- 171,175 ----
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
! k) likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
***************
*** 178,182 ****
Maybe this could be added as a SHOULD in the conformance section
! * section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
--- 178,182 ----
Maybe this could be added as a SHOULD in the conformance section
! l) section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
***************
*** 252,269 ****
If people thought it was worth having, I'd volunteer to compile such an
index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! - section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
! - section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
! - section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
! - I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
--- 252,269 ----
If people thought it was worth having, I'd volunteer to compile such an
index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! a) section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
! b) section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
! c) section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
! d) I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
***************
*** 274,285 ****
(I used capitalization in this case, but italicizing may work better).
! - the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
! - the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
! - in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
--- 274,285 ----
(I used capitalization in this case, but italicizing may work better).
! e) the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
! f) the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
! g) in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
***************
*** 287,294 ****
since the sentence is preceded by "RECOMMENDED"
! - I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
! - there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
--- 287,294 ----
since the sentence is preceded by "RECOMMENDED"
! h) I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
! i) there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
***************
*** 302,310 ****
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
! - section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
! - section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
--- 302,310 ----
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
! j) section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
! k) section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
***************
*** 315,319 ****
but "i.e."; or did I miss something?
! - 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
--- 315,319 ----
but "i.e."; or did I miss something?
! l) 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
***************
*** 321,350 ****
Call", it looks a bit awkward
! - in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
! - section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
! - 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
! - in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
! - section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
! - the document references XML 1.0 Second Edition, while the third has
been published earlier this year
! - it also references outdated versions of XML Infoset and WebArch (see
[1])
! - the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
! - a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
--- 321,350 ----
Call", it looks a bit awkward
! m) in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
! n) section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
! o) 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
! p) in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
! q) section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
! r) the document references XML 1.0 Second Edition, while the third has
been published earlier this year
! s) it also references outdated versions of XML Infoset and WebArch (see
[1])
! t) the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
! u) a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
***************
*** 354,358 ****
2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
3.
! http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0002.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>- the {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
--- 354,358 ----
2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
3.
! http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0002.html">raised</a> on 6 Aug 2004 by Dominique Haza�l-Massieux (dom@w3.org)</dt><dd /></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>a) the {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
***************
*** 361,374 ****
you should use {identifier}?
! - is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)
! - purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
! - C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
--- 361,374 ----
you should use {identifier}?
! b) is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)
! c) purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
! d) C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
Index: ack_sort.html
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/ack_sort.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** ack_sort.html 1 Sep 2004 18:30:35 -0000 1.3
--- ack_sort.html 1 Sep 2004 18:50:30 -0000 1.4
***************
*** 105,109 ****
[4]):
! * Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
"Note that the WSDL language is defined in terms of the component model
--- 105,109 ----
[4]):
! a) Document conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
"Note that the WSDL language is defined in terms of the component model
***************
*** 116,120 ****
"element information item" has any sense at all.
! * Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
--- 116,120 ----
"element information item" has any sense at all.
! b) Also, section 1.2 ("Notational conventions") adds the definition of
"valid/not valid WSDL document", with important conformance
requirements. I suggest it should be moved to the conformance section,
***************
*** 124,131 ****
extension) would be better when talking about the schema itself.
! * it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
! * Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
--- 124,131 ----
extension) would be better when talking about the schema itself.
! c) it would be interesting to list (maybe in an appendix) what
constraints are not translated in the provided XML Schema
! c) Processor conformance
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
"""This section defines a class of conformant WSDL processors that are
***************
*** 136,145 ****
something better.
! * "a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above
! * you use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
--- 136,145 ----
something better.
! e) "a conformant WSDL processor MUST accept any legal WSDL document":
what is a legal WSDL document? I suggest saying "conformant WSDL
document" - but I'm still unclear whether you define that at all in the
section above
! f) you use both the expressions "a processor MUST fault" and "a processor
MUST fail"; do they mean the same thing? In any case, I think you should
clarify what is meant by those (i.e. what consist failing/faulting in?),
***************
*** 150,154 ****
error handling for a WSDL processor would be benefitial
! * "a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
--- 150,154 ----
error handling for a WSDL processor would be benefitial
! g) "a conformant WSDL processor MUST either agree to fully abide": I
think this an abusive usage of MUST, since "agreeing" is not an
operation that a WSDL process does; I would suggest "a conformance WSDL
***************
*** 156,167 ****
to fully abide ...."
! * "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
! * the "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it
! * the section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
--- 156,167 ----
to fully abide ...."
! h) "that it does not choose to implement." -> "it chooses not to
implement", or maybe "it doesn't implement"
! i) the "Note:" under this defines conformance requirements for a provider
agent, which is out of scope for the given section; I suggest creating a
different section, even if that's the only requirement for it
! j) the section 6.1 on mandatory extensions adds requirements both for
requesting and providing processors; most are duplicated in the
conformance section, but I think a few are not (e.g. "the provider agent
***************
*** 171,175 ****
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
! *likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
--- 171,175 ----
http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
! k) likewise, section 4.1 makes a suggestion for processors:
"Processors are encouraged to keep track of the source of component
definitions, so that multiple, mutual, and circular includes do not
***************
*** 178,182 ****
Maybe this could be added as a SHOULD in the conformance section
! * section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
--- 178,182 ----
Maybe this could be added as a SHOULD in the conformance section
! l) section 1.1 reads "All parts of this specification are normative, with
the EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as "Non-Normative"."; some of the "Note:"s include
***************
*** 252,269 ****
If people thought it was worth having, I'd volunteer to compile such an
index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! - section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
! - section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
! - section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
! - I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
--- 252,269 ----
If people thought it was worth having, I'd volunteer to compile such an
index.)</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html">raised</a> on 3 Aug 2004 by Bijan Parsia (bparsia@isr.umd.edu)</dt><dd /></dl></div><div class="issue"><h3><a name="LC7" id="LC7">LC7</a>: QA Review on WSDL 2.0 Part 1, Editorial comments [<a href="issues.html#LC7">link to this issue</a>]</h3><pre>Editorial issues:
! a) section 1.3 (WSDL terminology) has only one item; I would find
surprising that this specification only defines one new concept; e.g. a
'Web Service Component' would probably deserve to be defined here;
also, linking to the WS Glossary may be a good idea
! b) section 2's title is "Component Model" and uses these phrases a few
times, but doesn't define it
! c) section 2 has most of the meaty stuff (the component model), but it is
somewhat diluted by the XML serialization formalism; I wonder if moving
the XML serialization in a different section (or in an appendix) would
enhance the readability of the spec;
! d) I suggest marking up and styling appropriately (or maybe
capitalizing?) words that are used in a very specific way in the
specification; e.g. in 2.1.1 "At the abstract level, the Definitions
***************
*** 274,285 ****
(I used capitalization in this case, but italicizing may work better).
! - the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
! - the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
! - in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
--- 274,285 ----
(I used capitalization in this case, but italicizing may work better).
! e) the document introduction still calls Part 2 "Message Exchange
Patterns", although it's now called Predefined extensions
! f) the document refers to the language as "WSDL"; since WSDL has been
available in several versions, I suggest using "WSDL 2.0" instead - if
not everywhere, at least in the introduction
! g) in 2.1.1 "Note that it is RECOMMENDED that the value of the
targetNamespace attribute information item SHOULD be a dereferencible
URI and that it resolve to a WSDL document which provides service
***************
*** 287,294 ****
since the sentence is preceded by "RECOMMENDED"
! - I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
! - there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
--- 287,294 ----
since the sentence is preceded by "RECOMMENDED"
! h) I suggest linking the XPointer scheme definition for WSDL (appendix C)
from section 2.1.1., where dereferenceability of components is mentioned
! i) there are only 2 examples of complete WSDL definitions in the whole
spec (one in an appendix); adding a few simple examples in the course of
the spec may help the reader a bit more; more generally, having a bit
***************
*** 302,310 ****
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
! - section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
! - section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
--- 302,310 ----
"http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
! j) section 2.2.2.3 introduces the notion of style, which is only
explained later in 2.4.1.1; would be good to make a link from the former
to the latter
! k) section 2.4.2 reads "If the Interface Operation component uses a
{message exchange pattern} for which there is no output element, such as
'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
***************
*** 315,319 ****
but "i.e."; or did I miss something?
! - 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
--- 315,319 ----
but "i.e."; or did I miss something?
! l) 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
what is AII? "be" is repeated twice
thereafter, it uses the notion of a function signature, without much
***************
*** 321,350 ****
Call", it looks a bit awkward
! - in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
! - section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
! - 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
! - in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
! - section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
! - the document references XML 1.0 Second Edition, while the third has
been published earlier this year
! - it also references outdated versions of XML Infoset and WebArch (see
[1])
! - the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
! - a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
--- 321,350 ----
Call", it looks a bit awkward
! m) in section 2.5.1 "by the global element declaration reference by the
{element} property.", "reference" should read "referenced"
! n) section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
the model described in 2.8.1 where {required} is REQUIRED
! o) 2.17, "the combination of these two properties need not be unique" ,
"need" should read "needs"
! p) in section 3, "W3C XML Schema Description Language" isn't a proper way
to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
language'
! q) section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
IT'S NOT
! r) the document references XML 1.0 Second Edition, while the third has
been published earlier this year
! s) it also references outdated versions of XML Infoset and WebArch (see
[1])
! t) the table of contents should use real markup, rather than &nsbp;; I've
provided a patch to xmlspec for this purpose [2]
! u) a few typos: "compomnent", "dereferencible" (should be dereferenceable
AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
spell checker [3]
***************
*** 375,379 ****
prose and the model.</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0319.html">raised</a> on 26 Jul 2004 by Glen Daniels (gdaniels@sonicsoftware.com)</dt><dd /><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0056.html">agreed</a> on 4 Aug 2004</dt><dd><p>RESOLUTION: to remove the required flag on
property element and make appropriate changes
! to the component model.</p><h5>Acknowledgment cycle</h5><dl><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0000.html">announced by group on 1 Sep 2004</a></dt></dl></dd></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>- the {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
--- 375,379 ----
prose and the model.</pre><h4>Transition history</h4><dl class="transitions"><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0319.html">raised</a> on 26 Jul 2004 by Glen Daniels (gdaniels@sonicsoftware.com)</dt><dd /><dt><a href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0056.html">agreed</a> on 4 Aug 2004</dt><dd><p>RESOLUTION: to remove the required flag on
property element and make appropriate changes
! to the component model.</p><h5>Acknowledgment cycle</h5><dl><dt><a href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Sep/0000.html">announced by group on 1 Sep 2004</a></dt></dl></dd></dl></div><div class="issue"><h3><a name="LC6" id="LC6">LC6</a>: QA Review on WSDL 2.0 Part 1, Technical comments [<a href="issues.html#LC6">link to this issue</a>]</h3><pre>a) the {name} property of the feature and property component uses URIs,
while all the other {name} properties use QNames; I guess my preference
would be to have all the {name} properties be URIs, but at the very
***************
*** 382,395 ****
you should use {identifier}?
! - is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)
! - purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
! - C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
--- 382,395 ----
you should use {identifier}?
! b) is there any reason why the {value constraint} in properties
components (2.8) is represented in XML as an element rather than an
attribute? given its content model (xs:QName), an attribute would look
more "natural" (and more in-line with the other representations in WSDL)
! c) purely cosmetic: why 'wsdlLocation' as attribute name, rather than
simply 'Location', since the attribute is namespace qualified (in wsdli:
) ?
! d) C.2 defines fragment identifiers compatible with the XPointer
Framework; I suspect this means you're defining a new scheme for
XPointer, in which case this should be said explicitly; also, it would
Index: issues.xml
===================================================================
RCS file: /sources/public/2002/ws/desc/issues/last-call/issues.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** issues.xml 1 Sep 2004 17:40:16 -0000 1.2
--- issues.xml 1 Sep 2004 18:50:30 -0000 1.3
***************
*** 22,28 ****
<p>List and dispositions of issues recorded against:</p>
<ulist>
! <li><loc xlink:href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/">Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</loc>.</li>
! <li><loc xlink:href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions</loc>.</li>
! <li><loc xlink:href="http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings</loc>.</li>
</ulist>
<p>Issues list for other deliverables of the WG can be found on the
--- 22,28 ----
<p>List and dispositions of issues recorded against:</p>
<ulist>
! <item><p><loc xlink:href="http://www.w3.org/TR/2004/WD-wsdl20-20040803/">Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</loc>.</p></item>
! <item><p><loc xlink:href="http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions</loc>.</p></item>
! <item><p><loc xlink:href="http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803/"> Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings</loc>.</p></item>
</ulist>
<p>Issues list for other deliverables of the WG can be found on the
***************
*** 35,39 ****
</header>
<body>
! <issue id="LC1" type="proposal">
<title>Property Requiredness</title>
<transitions>
--- 35,39 ----
</header>
<body>
! <issue id="LC1" type="error">
<title>Property Requiredness</title>
<transitions>
***************
*** 79,82 ****
--- 79,479 ----
</transitions>
</issue>
+ <issue id="LC2" type="clarification" xmlns="http://www.w3.org/2003/10/issues">
+ <title>Editorial: Issue 177 Implementation</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0006.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-02</date>
+ <description>
+ <eg>ref: issue 177 [1]
+
+ On July 8th, we adopted [2] Jonathan's proposal [3]. I have one editorial
+ issue with 177 implementation.
+
+ The types of the following properties in Part 3, SOAP Binding, are defined
+ using prose instead of wsdls:* types. I request the following property-type
+ associations,
+
+ {soap underlying protocol} => wsdls:anyURI
+ SOAP Module.{uri} => wsdls:anyURI
+ SOAP Module.{required} => wsdls:boolean
+ {soap fault code} => wsdls:QName
+ {soap fault subcodes} => list of wsdls:QName
+ {soap mep} => wsdls:anyURI
+ {soap action} => wsdls:anyURI
+
+ Rationale
+
+ (a) Consistent with Part 1 and HTTP Binding
+ (b) Otherwise, we will be using two similar types (xs:QName vs. wsdls:QName)
+ in the component model
+ (c) Equivalence in Part 1 is defined using wsdl simple types
+ (d) Part 3 is refuting Part 1 claim, "The component model uses a small set
+ of predefined simple types, such as boolean, string, token. In order to
+ avoid introducing a dependency on any particular serialization of the
+ component model, this specification provides its own definition of those
+ types" [5]
+
+ [1]
+ http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x177
+ [2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0109.html
+ [3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0258.html
+ [4]
+ http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
+ type=text/html;%20charset=utf-8#string_type
+ [5]
+ http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
+ type=text/html;%20charset=utf-8#simpletypes</eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="asirv@webmethods.com">Asir Vedamuthu (asirv@webmethods.com)</originator>
+ </raised>
+ </transitions>
+ </issue>
+ <issue id="LC3" type="editorial" xmlns="http://www.w3.org/2003/10/issues">
+ <title>{namespace name} property</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0011.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-03</date>
+ <description>
+ <eg>"2.18 QName resolution
+
+ In its serialized form WSDL makes significant use of references between
+ components. Such references are made using the Qualified Name, or
+ QName, of the component being referred to. QNames are a tuple,
+ consisting of two parts; a namespace name and a local name. For
+ example, in the case of an Interface component, the namespace name is
+ represented by the {namespace name} property and the local name is
+ represented by the {name} property."
+
+ I can't find any {namespace name} *property* (component). Perhaps it is
+ the {targetNamespace}?
+
+ I see lots of references to [namespace name] Infoset properties.
+
+ Ah, I see in 2.17:
+
+ "Within a symbol space, all qualified names (that is, the combination
+ of {name} and {target namespace} properties) are unique. Between symbol
+ spaces, the combination of these two properties need not be unique.
+ Thus it is perfectly coherent to have, for example, a binding and an
+ interface that have the same name."
+
+ This suggests that it is {targetNamespace}.</eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="bparsia@isr.umd.edu">Bijan Parsia (bparsia@isr.umd.edu)</originator>
+ </raised>
+ </transitions>
+ </issue>
+ <issue id="LC4" type="editorial" xmlns="http://www.w3.org/2003/10/issues">
+ <title>Table of components/properties</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0013.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-03</date>
+ <description>
+ <eg>I would find a table/index of components and
+ component properties very handy (perhaps in the Primer).
+
+ (E.g., something like:
+ http://www.w3.org/TR/owl-ref/#appA)
+
+ Whoa, they liked it so much that the did it twice:
+ http://www.w3.org/TR/2004/REC-owl-guide-20040210/#TermIndex
+
+ If people thought it was worth having, I'd volunteer to compile such an
+ index.)</eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="bparsia@isr.umd.edu">Bijan Parsia (bparsia@isr.umd.edu)</originator>
+ </raised>
+ </transitions>
+ </issue>
+ <issue id="LC5" type="clarification" xmlns="http://www.w3.org/2003/10/issues">
+ <title>QA Review on WSDL 2.0 Part 1, intro and conformance issues</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0000.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-06</date>
+ <description>
+ <eg>Conformance issues (these comments have been mostly inspired from specGL
+ [4]):
+
+ a) Document conformance
+ http://www.w3.org/TR/2004/WD-wsdl20-20040803/#markup
+ "Note that the WSDL language is defined in terms of the component model
+ defined by this specification. As such, it is explicitly NOT a
+ conformance requirement to be able to process documents encoded in a
+ particular version of XML, in particular XML 1.1 [XML 1.1]." is both
+ very hard to read, and probably in contradiction with the header
+ "document conformance"; I guess this needs clarification
+ It is particularly unclear to me that defining conformance for an
+ "element information item" has any sense at all.
+
+ b) Also, section 1.2 ("Notational conventions") adds the definition of
+ "valid/not valid WSDL document", with important conformance
+ requirements. I suggest it should be moved to the conformance section,
+ and the normative schema should be referenced from there. Additionally,
+ while using the content-negotiated URI as a namespace URI is a good
+ idea, I suggest referring explicitly the schema URI (with the .xsd
+ extension) would be better when talking about the schema itself.
+
+ c) it would be interesting to list (maybe in an appendix) what
+ constraints are not translated in the provided XML Schema
+
+ c) Processor conformance
+ http://www.w3.org/TR/2004/WD-wsdl20-20040803/#processor
+ """This section defines a class of conformant WSDL processors that are
+ intended to act on behalf of a party that wishes to make use of a Web
+ service"""
+ I suggest that you give a specific label to this class of WSLD
+ processors, � la "WSDL 2.0 requesting processor" - you'll probably find
+ something better.
+
+ e) "a conformant WSDL processor MUST accept any legal WSDL document":
+ what is a legal WSDL document? I suggest saying "conformant WSDL
+ document" - but I'm still unclear whether you define that at all in the
+ section above
+
+ f) you use both the expressions "a processor MUST fault" and "a processor
+ MUST fail"; do they mean the same thing? In any case, I think you should
+ clarify what is meant by those (i.e. what consist failing/faulting in?),
+ and if they mean the same thing, only use one of the expressions; also,
+ since the name 'fault' is used in a very well defined context in the
+ spec, I think you should avoid using the verb 'fault' unless it relates
+ to the said context; more generally, I think developing the notion of
+ error handling for a WSDL processor would be benefitial
+
+ g) "a conformant WSDL processor MUST either agree to fully abide": I
+ think this an abusive usage of MUST, since "agreeing" is not an
+ operation that a WSDL process does; I would suggest "a conformance WSDL
+ processor MUST immediately cease processing (fault) if it doesn't agree
+ to fully abide ...."
+
+ h) "that it does not choose to implement." -> "it chooses not to
+ implement", or maybe "it doesn't implement"
+
+ i) the "Note:" under this defines conformance requirements for a provider
+ agent, which is out of scope for the given section; I suggest creating a
+ different section, even if that's the only requirement for it
+
+ j) the section 6.1 on mandatory extensions adds requirements both for
+ requesting and providing processors; most are duplicated in the
+ conformance section, but I think a few are not (e.g. "the provider agent
+ MUST support every extension, Feature or Property that is declared as
+ optional in the WSDL document"); I suggest they should be added to the
+ conformance section
+ http://www.w3.org/TR/2004/WD-wsdl20-20040803/#mandatoryext
+
+ k) likewise, section 4.1 makes a suggestion for processors:
+ "Processors are encouraged to keep track of the source of component
+ definitions, so that multiple, mutual, and circular includes do not
+ require establishing identity on a component-by-component basis."
+ http://www.w3.org/TR/2004/WD-wsdl20-20040803/#includes
+ Maybe this could be added as a SHOULD in the conformance section
+
+ l) section 1.1 reads "All parts of this specification are normative, with
+ the EXCEPTION of notes, pseudo-schemas, examples, and sections
+ explicitly marked as "Non-Normative"."; some of the "Note:"s include
+ normative-like language, e.g.
+ "Support for the W3C XML Schema Description Language [XML Schema:
+ Structures],[XML Schema: Datatypes] is required of all processors."
+ or
+ "If a WSDL document declares an extension or feature as optional, then
+ if that extension or feature could apply to messages sent by the
+ provider agent as well, then the provider agent MUST NOT send any
+ messages that requires the requester agent to support that extension or
+ feature."
+ Please fix.
+
+ 4. http://www.w3.org/TR/qaframe-spec/
+ </eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="mailto:dom@w3.org">Dominique Haza�l-Massieux (dom@w3.org)</originator>
+ </raised>
+ </transitions>
+ </issue>
+ <issue id="LC6" type="error" xmlns="http://www.w3.org/2003/10/issues">
+ <title>QA Review on WSDL 2.0 Part 1, Technical comments</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0001.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-06</date>
+ <description>
+ <eg>a) the {name} property of the feature and property component uses URIs,
+ while all the other {name} properties use QNames; I guess my preference
+ would be to have all the {name} properties be URIs, but at the very
+ least, I find it confusing to have this inconsistency in the model:
+ what's the reasoning behind it? maybe instead of using {name} for those,
+ you should use {identifier}?
+
+ b) is there any reason why the {value constraint} in properties
+ components (2.8) is represented in XML as an element rather than an
+ attribute? given its content model (xs:QName), an attribute would look
+ more "natural" (and more in-line with the other representations in WSDL)
+
+ c) purely cosmetic: why 'wsdlLocation' as attribute name, rather than
+ simply 'Location', since the attribute is namespace qualified (in wsdli:
+ ) ?
+
+ d) C.2 defines fragment identifiers compatible with the XPointer
+ Framework; I suspect this means you're defining a new scheme for
+ XPointer, in which case this should be said explicitly; also, it would
+ probably be wise to mention that at the time of this document, only the
+ application/wsdl+xml MIME-type references this scheme as a possible
+ xpointer scheme - i.e., I don't think a WSDL resource served as
+ application/xml can ben resolved using this XPointer scheme
+ </eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="mailto:dom@w3.org">Dominique Haza�l-Massieux (dom@w3.org)</originator>
+ </raised>
+ </transitions>
+ </issue>
+ <issue id="LC7" type="editorial" xmlns="http://www.w3.org/2003/10/issues">
+ <title>QA Review on WSDL 2.0 Part 1, Editorial comments</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0002.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-06</date>
+ <description>
+ <eg>Editorial issues:
+ a) section 1.3 (WSDL terminology) has only one item; I would find
+ surprising that this specification only defines one new concept; e.g. a
+ 'Web Service Component' would probably deserve to be defined here;
+ also, linking to the WS Glossary may be a good idea
+
+ b) section 2's title is "Component Model" and uses these phrases a few
+ times, but doesn't define it
+
+ c) section 2 has most of the meaty stuff (the component model), but it is
+ somewhat diluted by the XML serialization formalism; I wonder if moving
+ the XML serialization in a different section (or in an appendix) would
+ enhance the readability of the spec;
+
+ d) I suggest marking up and styling appropriately (or maybe
+ capitalizing?) words that are used in a very specific way in the
+ specification; e.g. in 2.1.1 "At the abstract level, the Definitions
+ component is just a container for two categories of components; WSDL
+ components and type system components." would better read IMHO as "At
+ the abstract level, the Definitions Component is just a container for
+ two categories of component: WSDL Components and Type System Components"
+ (I used capitalization in this case, but italicizing may work better).
+
+ e) the document introduction still calls Part 2 "Message Exchange
+ Patterns", although it's now called Predefined extensions
+
+ f) the document refers to the language as "WSDL"; since WSDL has been
+ available in several versions, I suggest using "WSDL 2.0" instead - if
+ not everywhere, at least in the introduction
+
+ g) in 2.1.1 "Note that it is RECOMMENDED that the value of the
+ targetNamespace attribute information item SHOULD be a dereferencible
+ URI and that it resolve to a WSDL document which provides service
+ description information for that namespace"; the "SHOULD" is not needed
+ since the sentence is preceded by "RECOMMENDED"
+
+ h) I suggest linking the XPointer scheme definition for WSDL (appendix C)
+ from section 2.1.1., where dereferenceability of components is mentioned
+
+ i) there are only 2 examples of complete WSDL definitions in the whole
+ spec (one in an appendix); adding a few simple examples in the course of
+ the spec may help the reader a bit more; more generally, having a bit
+ more illustrations of what WSDL is about would help [I see that a primer
+ is in preparation; still, I don't think a few included examples would
+ hurt]
+ Also, the first example (in 2.7.1.1.1) should declare that <definitions>
+ (and its children) are in the WSDL namespace
+ The second example (in C.4) uses a relative URI as its
+ xsi:schemaLocation; any reason to use "wsdl20.xsd" instead of
+ "http://www.w3.org/2004/08/wsdl/wsdl20.xsd"?
+
+ j) section 2.2.2.3 introduces the notion of style, which is only
+ explained later in 2.4.1.1; would be good to make a link from the former
+ to the latter
+
+ k) section 2.4.2 reads "If the Interface Operation component uses a
+ {message exchange pattern} for which there is no output element, such as
+ 'http://www.w3.org/2004/08/wsdl/in-only'"; but according to the
+ paragraph above "The RPC style MUST NOT be used for Interface Operation
+ components whose {message exchange pattern} property has a value other
+ than 'http://www.w3.org/2004/08/wsdl/in-only' or
+ 'http://www.w3.org/2004/08/wsdl/in-out'.", this should not be "such as",
+ but "i.e."; or did I miss something?
+
+ l) 2.4.2.1 starts with "The wrpc:signature extension AII MAY be be used":
+ what is AII? "be" is repeated twice
+ thereafter, it uses the notion of a function signature, without much
+ introduction; since "RPC" is never translated into "Remote Procedure
+ Call", it looks a bit awkward
+
+ m) in section 2.5.1 "by the global element declaration reference by the
+ {element} property.", "reference" should read "referenced"
+
+ n) section 2.8.2 reads "An OPTIONAL required attribute" which contradicts
+ the model described in 2.8.1 where {required} is REQUIRED
+
+ o) 2.17, "the combination of these two properties need not be unique" ,
+ "need" should read "needs"
+
+ p) in section 3, "W3C XML Schema Description Language" isn't a proper way
+ to refer to XML Schema; use "W3C XML Schema" or 'W3C XML Schema
+ language'
+
+ q) section 4.2 uses "DOES NOT" (upper case), as if it was an RFC Keyword;
+ IT'S NOT
+
+ r) the document references XML 1.0 Second Edition, while the third has
+ been published earlier this year
+
+ s) it also references outdated versions of XML Infoset and WebArch (see
+ [1])
+
+ t) the table of contents should use real markup, rather than &nsbp;; I've
+ provided a patch to xmlspec for this purpose [2]
+
+ u) a few typos: "compomnent", "dereferencible" (should be dereferenceable
+ AFAIK), "implicitely" (implicitly), "requestor" (requester) based on the
+ spell checker [3]
+
+ 1. TR references checker:
+ http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2004%2F07%2Freferences-checker&xmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin%2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252F2004%252FWD-wsdl20-20040803%252F&
+ 2. http://lists.w3.org/Archives/Public/spec-prod/2004AprJun/0000.html
+ 3.
+ http://www.w3.org/2002/01/spellchecker?uri=http://www.w3.org/TR/2004/WD-wsdl20-20040803/</eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="mailto:dom@w3.org">Dominique Haza�l-Massieux (dom@w3.org)</originator>
+ </raised>
+ </transitions>
+ </issue>
+ <issue id="LC8" type="clarification" xmlns="http://www.w3.org/2003/10/issues">
+ <title>Permit URI References instead of URIs</title>
+ <transitions>
+ <raised xlink:type="simple" xlink:href="http://lists.w3.org/Archives/Public/public-ws-desc-comments/2004Aug/0021.html" xmlns:xlink="http://www.w3.org/1999/xlink">
+ <date>2004-08-27</date>
+ <description>
+ <eg>In sections 2.7 and 2.8, we use URIs to identify Features and
+ Properties. For example, section 2.7.1 says:
+ [[
+ {name} REQUIRED. A wsdls:anyURI as defined in 2.15.4 anyURI Type.
+ ]]
+ and anyURI is defined as:
+ [[
+ 2.15.4 anyURI Type
+ The value space of the wsdls:anyURI type consists of all Uniform
+ Resource Identifiers (URI) as defined by [IETF RFC 2396] and amended by
+ [IETF RFC 2732].
+ ]]
+
+ I think we should allow these to be URI References instead restricting
+ them to be only URIs. (I.e., allow them to contain fragment
+ identifiers.) That would permit multiple, related Features or
+ Properties to be described in the same document, using different
+ fragment identifiers to distinguish them, such as:
+
+ http://example.org/my_related_features_and_properties#a
+ http://example.org/my_related_features_and_properties#b
+ http://example.org/my_related_features_and_properties#c
+
+ This would also allow conformance to the practice that some recommend
+ for the Semantic Web, of using fragment identifiers when identifying
+ things that are not documents, such as abstract concepts.</eg>
+ </description>
+ <originator xlink:type="simple" xlink:href="dbooth@w3.org">David Booth (dbooth@w3.org)</originator>
+ </raised>
+ </transitions>
+ </issue>
</body>
</issues>
Received on Wednesday, 1 September 2004 18:50:33 UTC