RE: Part 2 Adjuncts Comments (1 -5)

Thanks for your comment, and apologizes for reporting our resolution so
belatedly.  Resolutions have not yet been incorporated into the
document.  

Unless you let us know otherwise by the end of September, we will assume
you agree with the resolution of each issue as detailed below. 

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Arthur Ryman
> Sent: Wednesday, May 03, 2006 11:34 PM
> To: www-ws-desc@w3.org
> Subject: Part 2 Adjuncts Comments (1 -5)
> 
> 
> I reviewed Part 2 carefully and have the following questions up to the
end
> of chapter 5:
> 
> 1. In 4.2 IRI Style, the content model of the initial is constrained
to
> have a sequence of child elements. What are the occurrence contraints?
Are
> there any?

The WS Description Working Group tracked this issue as a CR024 [1].

The Working Group agreed to clarify that there are no occurrence
constraints.
 
[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR024 

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

The WS Description Working Group tracked this issue as a CR025 [2].

The Working Group agreed to remove the "if" and rewrite accordingly.
 
[2] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR025 

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

The WS Description Working Group tracked this issue as a CR026 [3].

The Working Group agreed to clarify that mustUnderstand=true in WSDL
will be faithfully reflected in the SOAP message.
 
[3] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR026

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

The WS Description Working Group tracked this issue as a CR027 [4].

The Working Group agreed to add text along the lines of "The value of
this property identifies one or more subcodes for this SOAP fault. The
list of subcodes is the nested sequence of subcodes, an empty list
represents a fault code without subcodes."
 
[4] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR027

> 5. Global comment on organization: Part 1 is organized by component,
and
> then by properties within a component. In Part 2 this structure in not
> used. Components and properties are described together. I think it
would
> be clearer is we followed the Part 1 organization, i.e. have a section
for
> each Core and Extension component involved, then list and describe the
> properties that apply to each compoinent. e.g. 5.7.2 lists a set of
> properties, but some apply to Binding and some apply to Binding
Operation
> - sort of confusing I think.

The WS Description Working Group tracked this issue as a CR028 [5].

The Working Group declined to engage in this significant work the this
time, feeling that organization by feature has desirable aspects.
 
[5] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR028

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

The WS Description Working Group tracked this issue as a CR029 [6].

The Working Group agreed to add an anchor for 5.10.3 bullet point 2
(SOAP MEP Selection) and add a link ("see 5.10.3 SOAP 1.2 Binding Rules,
SOAP MEP Selection, for constraints on binding") to the end of the
problematic paragraph in 5.7.2.
 
[6] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR029

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

The WS Description Working Group tracked this issue as a CR030 [7].

The Working Group agreed to add a reference to 5.10.3, where the
"rollup" is specified.
 
[7] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR030

> 8. In 5.8.2 there should be a constraint on {soap modules} that each
soap
> module component is uniquely identified by its {ref} property, i.e
{ref}
> is a key. No two different soap modules in the {soap modules} property
may
> have the same {ref}.

The WS Description Working Group tracked this issue as a CR031 [8].

The Working Group agreed to a constraint to 5.8.2 that for a soap module
on a given binding, {ref} will be unique.
 
[8] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR031

> 9. Similarly, in 5.9.2 there should be a contraints on {soap headers}
that
> each soap header component is uniquely identified by is {element
> declaration} property (I assume).

The WS Description Working Group tracked this issue as a CR032 [9].

The Working Group agreed to require that {element declaration} be unique
(i.e., can describe at most one header with a given QName.)
 
[9] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR032

> 10. In 5.9.6, the design of the fragment identifier for wsoap.header
is
> inconsistent since it represents the element QName as namespace#name.
All
> other components use the QName and define the namespace using an xmlns
> pointer part. This should be changed to use QName too, c.f. the
element
> declaration component itself.

The WS Description Working Group tracked this issue as a CR033 [10].

The Working Group agreed to change "namespace#name" to "qname".
 
[10] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR033

> 
> 
> 
> Arthur Ryman,
> IBM Software Group, Rational Division
> 
> blog: http://ryman.eclipsedevelopersjournal.com/
> phone: +1-905-413-3077, TL 969-3077
> assistant: +1-905-413-2411, TL 969-2411
> fax: +1-905-413-4920, TL 969-4920
> mobile: +1-416-939-5063, text: 4169395063@fido.ca

Received on Wednesday, 30 August 2006 21:03:48 UTC