RE: LC ISSUE: Editorial points

Oops, that should be LC344 at

-----Original Message-----
From: Jonathan Marsh 
Sent: Monday, November 14, 2005 2:34 PM
To: 'David Hull'
Subject: RE: LC ISSUE: Editorial points

Thanks for your comment.  The WS Description Working Group tracked this
as a Last Call comment LC304 [1].  We resolved these issues as briefly
summarized below.  For additional information, the issue text [1] has
links to the minutes of the meetings where these items were discussed.

As we plan to go to CR shortly, if we don't hear from you within 10
days, we will assume this satisfies your concern.


> -----Original Message-----
> From: [mailto:public-ws-desc-
>] On Behalf Of David Hull
> Sent: Tuesday, September 20, 2005 10:51 PM
> To:
> Subject: LC ISSUE: Editorial points
> This email collects several minor editorial points regarding the WSDL
> specification, some more minor than others.  I apologize for the
> late submission, which was due to several extraneous circumstances too
> tedious to mention.
> *	In the paragraph at the beginning of section 1.3 ending "... the
> functionality implied by that extension is only optional to the
> But it needs to be supported by the Web Service." the last sentence
> better read "It must be supported by the Web Service."

[Jonathan Marsh: ] Proposal accepted.

> *	In section 2.3.1, the paragraph beginning "Note that faults
> than the ones described in the Interface ..." seems like more than a
> note.

[Jonathan Marsh: ] Accept proposal to reword "Note that".

> *	In the same section, the rather long note beginning "Despite
> a {name} property, Interface Fault components cannot be identified
> seems to say, basically, that separately included interfaces must be
> consistent with each other to the extent they overlap.  If this is so,
> something to the effect of "In other words, interfaces must be
> where they overlap." might make the situation clearer.  Also, my first
> reaction to this was "Ah, the diamond inheritance problem."  But
> inheritance is not a problem, since the shared ancestor is
> consistent with itself (see the note on idempotency below).  If I've
> this right, it might be worth noting.

[Jonathan Marsh: ] Close with no action (this paragraph has already been
revised somewhat).

> *	The above note appears in very similar form in other sections.
> sure that factoring this out has been suggested, but for what it's
> I'd like to weigh in in favor of having at least the bulk of it appear
> only once, possibly with a short reference where the mostly-repeated
> presently appears

[Jonathan Marsh: ] Close with no action (too disruptive at this time).

> *	In section, in "... the rules implied by that IRI (such
> rules that govern the schemas) MUST be followed or it is an error", it
> not clear to me what exactly should happen should this error occur.
> text appears to mean that the combination simply would not work, just
> in-scope properties with an empty intersection won't work.  The
> here is, what entity, if any, needs to report this error (and how,
> Also, the net effect of all this seems to be the conjunction of the
> (possibly empty) set of constraints specified by the IRIs, but the
> separation into cases obscures this somewhat.  If there is a general
> agreement that this paragraph could be made clearer, I would be
willing to
> attempt a clearer wording.

[Jonathan Marsh: ] Implement proposal at, plus
these amendments:
 - Proposed sentence: "This additional information in no way affects the
messages exchanged with the service and ..."
 - s/by the interface message reference components of the/in/
 - "If no Operation component can simultaneously satisfy all of the
styles, the document is invalid.
 - "Update URI to IRI.
 - Section needs to be amended to include Faults and to not just
be applied to the {element declarations} but to the actual components
since the style MAY be dependent on direction or possibly sequence.

> *	In section 2.7.1, second paragraph.  Consecutive sentences start
> with "Thus," and "Hence,"  This might flow better as "Thus, by
> every SOAP 1.2 abstract feature is also a WSDL 2.0 feature, and there
> no need to define a separate WSDL 2.0 feature ..."

[Jonathan Marsh: ] Refer to editors for cleanup. Arthur to edit 2.7.1
and capitalize feature appropriately and define "feature" somewhere.

> *	In section 2.8.1, first paragraph, the last sentence asserts
> "Properties, and hence property values, can be shared amongst
> features/bindings/modules, and are named with IRIs precisely to allow
> type of sharing."  This seems to emphasize that the names are not
> but it wasn't apparent to me why QNames wouldn't have worked equally
> I have the distinct feeling the answer is blindingly obvious and I'm
> missing it.

[Jonathan Marsh: ] 
Close with no action (because of precedence for IRIs)

> *	In, the paragraph beginning "Many of the component types
> the component model contain a {properties} property ..." produced
> errors on the first couple of readings.  The root problem is that
> "property" is badly overloaded, at least in this context.
> it's not clear how to avoid this painlessly, as both senses of
> are integral to the spec.  The upshot seems to be to distinguish
> properties (in the F&P sense) that are directly attached (declared
> properties) and all applicable properties, whether directly attached
> pulled in by composition (in-scope properties).  If this is the
> the wording could be clearer (and again, I could probably have a go at
> rewording it).

[Jonathan Marsh: ] Close with no action (although we agree the comment
makes sense, there is no will to address it at this stage).

> *	In 2.9.1, paragraph 6, the text "Thus, it is an error for a
> component not to define bindings ..." again leads me to wonder what
> reports the error and when.  Also, the "Thus," made me wonder if I'd
> missed a step (quite likely).

[Jonathan Marsh: ] Remove last sentence of paragraph 6 of section 2.9.1.

> *	In 2.9.2, in the XML representation of Binding components, the
> "whgse" was clearly inserted to test whether reviewers were awake.
> happy to report that I might well be.

[Jonathan Marsh: ] Accept proposal.

> *	Section seems like boilerplate in the same sense as the
> note on inheritance and overlap mentioned above.

[Jonathan Marsh: ] Close with no action.

> *	In the tables in sections 2.12.3 and 2.13.3, the descriptions of
> {interface message|fault reference}seem rather lengthy for a table
> And again, they seem to be near duplicates.  The general problem with
> duplication is of course that it's hard to tell without careful
> what's duplicated and what's not.

[Jonathan Marsh: ] Close with no action other than the improvements we
plan to make when adding test assertion markup.

> *	In section 2.15.1, the {address} is given as optional.  Is there
> guidance on when one might want to not include it?

 [Jonathan Marsh: ] Add a sentence saying {address} is optional because
it could be defined by other means, such as an WS-A endpoint reference
or maybe the scenario does not require an address.

> *	In section 2.17, the definition of equivalence is oddly
> Speaking as a math major, I'd be more comfortable if "and the second
> component has no additional properties" were simply "and vice versa."
> Similarly, "set-based values are considered equivalent if they contain
> corresponding equivalent values, without regard to order." feels a bit
> since on the one hand, sets are unordered by definition, and on the
> hand they are also duplicate-free by definition but this is not
> I might reword this as "Set-based values are considered equivalent if
> each value in the first, there is an equivalent value in the second,
> vice versa," parallel with the proposed rewording for components as a
> whole (and the usual set-theoretic definition that each is a subset of
> other).

[Jonathan Marsh: ] Accept suggested wording.

> *	In the same section, in the first bullet point (simple types),
> "contain the same value" mean "contain the same actual value" in the
> sense?  If not, what does it mean?

[Jonathan Marsh: ] Close without change: "actual value" is about XML,
the component model is in math space.

> *	In section 2.19, first paragraph, a "tuple, consisting of two
> is generally called an "ordered pair".

[Jonathan Marsh: ] Close with no action.

> *	In the following paragraph, "QName references are resolved by
> looking in the appropriate property," the appropriate property should
> spelled out, even if the result is a bit tedious.

[Jonathan Marsh: ] Close with no action. The majority of the WG felt it
was clear enough.

> *	In 4.1, the paragraph beginning "A mutual include is direct
> inclusion by one WSDL 2.0 document of another WSDL 2.0 document ..."
> upshot seems to be that inclusion is idempotent (because a component
> equivalent to itself and so multiple inclusion doesn't redefine
> It would be better either to mention idempotency explicitly, or,
> better, to rephrase this paragraph in terms of the transitive closure
> (which is mentioned earlier) to explain that everything in the
> closure of the inclusion relation is thrown into the same flat space.

[Jonathan Marsh: ] Close with no action.

> *	In section 4.1, the location attribute doesn't have to be
> dereferenceable, but this may lead to unresolvable QNames down the
> It would be nice to say that implementations SHOULD report broken
> links as a root cause of the QName failures they cause, assuming that
> is not burdensome to determine.

[Jonathan Marsh: ] Close with no action. Assumption that location does
not have to be dereferenceable is not accurate.

> *	A.3 (security considerations) is remarkably short.  This is just
> comment -- I don't think it needs to be lengthened.

[Jonathan Marsh: ] Thank you for the comment!

Received on Monday, 14 November 2005 23:03:04 UTC