RE: implementation features comments

 Lynne,
 I'm cc'ing dist-app because I think my reply may be of interest 
to others, too.
 I commented on Anish's list before I got to comment on the whole 
list. It is true that this particular example (see Lynn's email 
below) introduces a duplicate again. In commenting on Anish's 
list, I was trying to filter out those features that really 
didn't belong there; I wasn't trying to consolidate the list with 
the "big list" which I hadn't had reviewed at that time.
 Perhaps I'll make another pass when the lists are merged by the 
maintainers.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Thu, 18 Jul 2002, Thompson, Lynne R wrote:

 > Jacek,
 > 
 > I am helping Asir with Part 2 (section 5,6, Appendix a and B)per yesterday's
 > telecon:
 > 
 > >>[ACTION Item] Asir volunteered to identify any implementation features in
 > >>Part 2 that are not already captured in the test collection - 4/3/2002.
 > 
 > Before I dwelt on this exercise, I decided to go through your comments on
 > Table 2 in [1]. That way, I am in synced with your definition
 > of a feature and the desired level of granularity.
 > 
 > Your comment:
 > >>7) rephrase: "supports active intermediaries" to remove 
 > >>commonality with 1.3
 > 
 > I agree with you in rephrasing (7).
 > 
 > This is a general feature.  One may go another level to be more specific.
 > 
 > One of your comments in Anish's list is:
 > 
 >  > 9.  Section 2.7.2
 >  > 
 >  > In addition to the processing performed by forwarding
 >  > intermediaries, active intermediaries undertake additional
 >  > processing that can modify the outbound message in ways not
 >  > described in the inbound message. That is, they can undertake
 >  > processing not described by SOAP header blocks in the incoming
 >  > message.
 > 
 > > OK
 > 
 > I agree that this should be included in Table 2.  This seems related to
 > (7) "supports active intermediaries". However, it is more specific. Should
 > this really be included?  Is this the level of fetaure granularity we want?
 > 
 > Can you enlighten me on this?
 > 
 > Thanks,
 > Lynne
 > 
 > 
 > -----Original Message-----
 > From: Jacek Kopecky [mailto:jacek@systinet.com]
 > Sent: Thursday, July 18, 2002 3:55 AM
 > To: xml-dist-app@w3.org
 > Subject: implementation features comments
 > 
 > 
 > 
 >  Hi all, 8-)
 >  I have comments here on the implementation features listed in 
 > table 2 in [1].
 >  I refer to the features by their ordinal position in the table
 > (at the moment the table contains 60 features) and I presume that
 > the features will be numbered from 1 to 60 in the next update to
 > the document.
 >  My comments are from the position of a SOAP implementor - what I 
 > envision I could say I implement or not. From this POV arise some 
 > properties of implementation features:
 >  1) a feature should be atomic - it can be implemented or not, 
 > nothing in between. This is an ideal state; usually there is some 
 > fuzziness and the following is my personal approach to drawing 
 > the line.
 >  2) a feature must affect implementation - for example 
 > requirements on transport bindings affect binding specs, not 
 > implementations.
 >  3) a feature must be specified by SOAP 1.2 specification, part 1 
 > or 2.
 >  My comments are at the end of this message. They are in the form
 > of "feature_number) my comments". Features I don't comment on are
 > OK with me.
 >  Proposed features are in the form of "feature_number) feature 
 > text"; the feature text presumes a context of "an implementation 
 > supports ...".
 >  If I suggest splitting a feature, this suggestion also implies 
 > removing the original feature.
 > 
 >                    Jacek Kopecky
 > 
 >                    Senior Architect, Systinet Corporation
 >                    http://www.systinet.com/
 > 
 > 
 > [1] http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html
 > 
 > 
 > 
 >  1) split into three features:
 >  1.1) generating and transmiting SOAP messages - initial sender,
 > intermediary
 >  1.2) receiving and processing SOAP messages - intermediary,
 > ultimate receiver
 >  1.3) relaying SOAP messages - intermediary
 > 
 >  2) add the text "supports env:role attribute II" obsoleting 
 > feature 18
 > 
 >  3) remove, routing is not in SOAP 1.2 spec and relaying is in 
 > 1.3
 > 
 >  4) dupe of 2
 > 
 >  5) rephrase: "supports SOAP-specified role names"
 > 
 >  7) rephrase: "supports active intermediaries" to remove 
 > commonality with 1.3
 > 
 >  8) does this mean at one endpoint URI? Just a clarification 
 > question, otherwise the feature is OK.
 > 
 >  9) rephrase to include all soap-envelope elements (envelope,
 > fault, header, body) because I don't see why an implementation
 > should validate Envelope and not the others
 > 
 >  10) don't see what it means: "does it support XML with some 
 > content?" Suggestion: remove
 > 
 >  11) rephrase: "allows insignificant whitespace in SOAP Envelope, 
 > between headers etc."
 > 
 >  12) obsoleted by 9
 > 
 >  13) and 14) I suggest merging these two
 > 
 >  15) obsoleted by 9
 > 
 >  16) obsoleted by 9
 > 
 >  17) duplicating 9 and 2
 > 
 >  18) obsoleted by 2
 > 
 >  20) obsoleted by 9
 > 
 >  21) obsoleted by 9
 > 
 >  22) split into
 >  22.1) Supports multiple application data models and their
 > serializations into XML
 >  22.2) Supports SOAP Data Model
 > 
 >  23) obsoleted by 22.1
 > 
 >  24) rephrase: "supports SOAP Encoding"
 > 
 >  26) rephrase: "supports globally and locally scoped names"
 > 
 >  27) split into:
 >  27.1) supports simple data types
 >  27.2) supports structs
 >  27.3) supports arrays
 >  27.4) supports generics
 > 
 >  28) obsoleted by 27.3
 > 
 >  29) dupe of 22.1
 > 
 >  30) remove
 > 
 >  34) rephrase to: "supports application/soap+xml content type 
 > with XML 1.0 serialization", 
 > 
 >  35) dupe of 31 and 32
 > 
 >  36) dupe of 33
 > 
 >  37) not specified by SOAP, remove
 > 
 >  38) and 39) implementation supports state description? merge 
 > into "supports all specified HTTP status codes"
 > 
 >  40) merged into 34
 > 
 >  41) through 46) merge into "supports SOAP Faults"
 > 
 >  50) remove, covered by others
 > 
 >  53) split into
 >  53.1) supports RPC as structs
 >  53.2) supports RPC as arrays
 > 
 >  55) dupe of 53
 > 
 >  57) SOAP doesn't specify other encoding styles, remove
 > 
 >  58) covered by 53
 > 
 >  59) remove or rephrase to "supports SOAP headers with RPC"
 > 
 >  60) rephrase to "supports RPC faults"
 >

Received on Friday, 19 July 2002 04:13:18 UTC