Re: ACTION REQ: SOAP 1.2 part 1, "features" list.

 Hi all, 8-)
 below are my comments on the proposed new implementation 
features.
 Most of them should be rephrased to be "implementation 
features", not excerpts from the spec; for example "node MAY do 
something" should be "implementation supports doing something".
 This is just a quick pass, I'll send my comments on the original 
list in a following message.
 Best regards,

                   Jacek Kopecky

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



 > 1.  Section 1.2
 > 
 > Specifications for the processing of application-defined data
 > carried in a SOAP message but not defined by this
 > specification MAY call for additional validation of the SOAP
 > message in conjunction with application-level processing.

OK

 > 2.  Section 1.2
 > 
 > The media type "application/soap+xml" [13] SHOULD be used for
 > XML 1.0 serializations of the SOAP message infoset.

OK

 > 3.  Section 2.2
 > 
 > In addition to those described above, other roles MAY be
 > defined as necessary to meet the needs of SOAP applications.

NO: already there

 > 4.  Section 2.6
 > 
 > SOAP nodes MAY make reference to any information in the SOAP
 > envelope when processing a SOAP body or SOAP header block.

OK

 > 5.  Section 2.6
 > 
 > The processing of one or more SOAP header blocks MAY control
 > or determine the order of processing for other SOAP header
 > blocks and/or the SOAP body.

OK

 > 6.  Section 2.6
 > 
 > Header blocks MAY be processed in arbitrary order. Header
 > block processing MAY precede, MAY be interleaved with, or MAY
 > follow processing of the body.

OK

 > 7.  Section 2.7.1
 > 
 > The semantics of one or more SOAP header blocks in a SOAP
 > message, or the SOAP MEP used MAY require that the SOAP
 > message be forwarded to another SOAP node on behalf of the
 > initiator of the inbound SOAP message.

OK

 > 8.  Section 2.7.1
 > 
 > Such rules MAY describe placement of inserted or reinserted
 > SOAP header blocks.  Inserted SOAP header blocks might be
 > indistinguishable from one or more of the header blocks
 > removed above. Re-inserting processed SOAP header blocks in
 > this manner effectively leaves them in place, but emphasizes
 > the need to process them at each SOAP node along the SOAP
 > message path.

MAYBE: this is a strange feature, does it mean if the
implementation supports such reinserts?

 > 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

 > 10.  Section 2.7.2
 > 
 > One mechanism by which an active intermediary can describe the
 > modifications performed on a message is by inserting header
 > blocks into the outbound SOAP message. These header blocks can
 > inform downstream SOAP nodes acting in roles whose correct
 > operation depends on receiving such notification. In this
 > case, the semantics of such inserted header blocks should also
 > call for either the same or other header blocks to be
 > (re)inserted at subsequent intermediaries as necessary to
 > ensure that the message can be safely processed by nodes yet
 > further downstream.

NO: depends on a module spec, not on an implementation

 > 11.  Section 3.3
 > 
 > A MEP MAY be supported by one or more underlying protocol
 > binding instances.

NO: doesn't affect implementations, affects binding 
specifications

 > 12.  Section 4.2
 > 
 > A binding, if using XML 1.0 serialization of the infoset, MAY
 > mandate that a particular character encoding or set of
 > encodings be used.

NO: again, only for bindings

 > 13.  Section 4.2
 > 
 > Bindings MAY depend on state that is modeled as being outside
 > of the SOAP XML Infoset (e.g. retry counts), and MAY transmit
 > such information to adjacent nodes.

NO: same as above

 > 14.  Section 5
 > 
 > A SOAP intermediary MAY ignore such insignificant character
 > information items when forwarding (see 2.7 Relaying SOAP
 > Messages) a message.

OK

 > 15.  Section 5.2.2
 > 
 > If relaying a SOAP message, a SOAP intermediary MAY discard
 > the SOAP role attribute information item for SOAP header
 > blocks when the value of the role attribute information item
 > is
 > "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver"
 > (see 2.7 Relaying SOAP Messages).

OK

 > 16.  Section 5.2.3
 > 
 > If relaying the message, a SOAP intermediary MAY substitute
 > "true" for the value "1", or "false" for "0". The SOAP
 > mustUnderstand attribute information item MAY be omitted if
 > its value would have been "false" or "0".

OK

 > 17.  Section 5.4
 > 
 > A SOAP Fault element information item MAY appear within a SOAP
 > header block, or as a descendant of a child element
 > information item of the SOAP Body ; in such cases, the element
 > has no SOAP-defined semantics.

MAYBE: not sure how this affects SOAP implementations

 > 18.  Section 5.4.3 An ultimate SOAP receiver MAY include this
 > element information item to indicate explicitly that it
 > generated the fault.

NO: dupe, support for Detail

 > 19.  Section 5.4.3
 > 
 > (should be in assertion doc - I will send an email to
 > xmlp-comments)
 > 
 > The type of the Node element information item is anyURI in the
 > "http://www.w3.org/2001/XMLSchema" namespace.

NO: dupe, already there

 > 20.  Section 5.4.5.1
 > 
 > Each detail entry:
 >         MAY be namespace qualified.
 >         MAY have any number of element information item children
 >         MAY have any number of character information item children.
 > Child
 >             character information items whose character code is amongst
 > the
 >             whitespace characters as defined by [8] are considered
 > significant.
 >         MAY have an encodingStyle attribute information item.
 >         MAY have any number of other attribute information items from
 > any
 >             namespace

MAYBE: what is this for SOAP implementations?

 > 21.  Section 6
 > 
 > URIs used as values in information items identified by the
 > "http://www.w3.org/2002/06/soap-envelope" and
 > "http://www.w3.org/2002/06/soap-encoding" XML namespaces can
 > be either relative or absolute.

NO: not an implementation feature

 > 22.  Section 6
 > 
 > The underlying protocol binding MAY define a base URI which
 > can act as the base URI for the SOAP envelope (see 4. SOAP
 > Protocol Binding Framework and Part 2 [1] section HTTP
 > binding).

NO: unless rephrased to a concrete binding that does define a 
base URI

Received on Wednesday, 17 July 2002 15:22:49 UTC