Re: Comments on SOAP 1.2 part 2

I've amended the abstract, although it now reads a bit like the TOC so I'm
leaning towards your original suggestion to delete that entire sentence...

I'm not sure how to reword the sentence on generics. Your wording implies
that there must be at least one duplicate label whereas the current wording
implies that duplicate labels are a possibility but not a necessity. That
said, I do agree that the current sentence is hard to parse, I'm just not
having much luck coming up with one that is easier ( and still says the same
thing )

Gudge

----- Original Message -----
From: "John Ibbotson" <john_ibbotson@uk.ibm.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: <xml-dist-app@w3.org>
Sent: Tuesday, April 09, 2002 8:25 AM
Subject: Re: Comments on SOAP 1.2 part 2


>
>
> Comments inline:
>
> ----- Original Message -----
> From: "John Ibbotson" <john_ibbotson@uk.ibm.com>
> To: <xml-dist-app@w3.org>
> Sent: Monday, April 08, 2002 9:48 PM
> Subject: Comments on SOAP 1.2 part 2
>
>
> > Here are some comments related to part 2 of the specification. I have
> used
> > the Editor's copy dated Mar 23 2002.
> >
> > Abstract
> > There is no mention of features, transport binding framework or the HTTP
> > binding so for simplicity remove the final sentence.
>
> Or add text about features, transport binding framework and HTTP binding?
> Not done yet.
>
> <jbi>Either is OK by me</jbi>
>
> >
> > Introduction
> > In bullet 4 there is no mention of sections 5 and 6 for the binding
> > framework.
> > Suggest new bullet 4:
> > The SOAP Protocol Binding Framework (see 5 A Convention for Describing
> > Features and Bindings and 6 Message Exchange Patterns) defines a way of
> > describing SOAP bindings to underlying transport protocols.
> > New bullet 5:
> > The SOAP HTTP Binding defines a binding of SOAP to HTTP [2] following
the
> > rules of the SOAP Protocol Binding Framwork (see 7 SOAP HTTP Binding).
>
> Done
>
> >
> > Section 2 The SOAP Data Model
> > First sentence:
> > "The SOAP Data Model represents information ....."
> > No mention of what type of information the data model represents.
> Suggest:
> > "The SOAP Data Model represents instance information ....."
>
> Replaced 'information' with 'application-defined data' for consistency
with
> Section 1
>
> <jbi>Good choice !!</jbi>
>
> >
> > Section 2.1 Graph Edges
> > Problem here in mixing the use of the word node. This section uses it in
> > the graph theoretic sense, the last sentence of section 2 uses it as a
> SOAP
> > Node !! Is there another word the mathematicians use to identify a graph
> > "node" ? Not sure there is.
>
> Section modified to always use 'graph node' as opposed to 'node'
>
> >
> > Section 2.3 Values
> > Bullet 1:
> > Rewrite as "A non-terminal is known as "generic" if the labels of its
> > outbound edges are not unique ......."
>
> Not sure I agree. We currently say
>
>     'A non-terminal is known as a "generic" if the labels of its outbound
>     edges need not be unique (i.e. if duplication of edge labels is
>    allowed).'
>
> This allows people to treat things as generics ( and access by name or
> position ) even if all edge labels are unique. Your amendment would rule
> this out, I'm not sure we want to do that although I'm open to argument.
>
> <jbi>Comment is grammatical rather than content based.
> The sentence did not read clearly</jbi>
>
> > Bullet 2:
> > Rewrite as "A non-terminal whose outbound edges are distinguished solely
> by
> > their labels is known as a "struct"."
>
> Done
>
> >
> > Section 3.1.3 Encoding compund values
> > Typo space missing "..... an array node MAY have ....."
>
> Done
>
> >
> > Section 3.1.4.3 Constraints on id and ref attribute information items
> > We constrain the value of a ref attribute to be the value of exactly one
> id
> > attribute. Does the converse apply ? That we cannot have ids without a
> > matching ref ?
>
> Can't see any reason to enforce that.
>
> <jbi>OK, just checking to see if the converse codition should apply</jbi>
> >
> > Apologies for missing the Friday deadline,
>
> No worries, thanks for the feedback
>
> Gudge
>
> > John
> >
> > Emerging ebusiness Industry Architecture ,
> > XML Technology and Messaging,
> > IBM UK Ltd, Hursley Park,
> > Winchester, SO21 2JN
> >
> > Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
> > Fax: +44 (0)1962 816898
> > Notes Id: John Ibbotson/UK/IBM
> > email: john_ibbotson@uk.ibm.com
> >
> >
>
>
>
>

Received on Tuesday, 9 April 2002 05:03:06 UTC