Re: [ebxml-msg] Outstanding Issues

[Pete Wenzel <pete.wenzel@Sun.COM>]

(Notes from 5/3 meeting discussion of these issues inline.)

Thus spoke Jacques Durand (JDurand@us.fujitsu.com) on Tue, May 02, 2006 at 12:01:59PM -0700:
> Great editing job so far...
> More inline <JD>.
> 
> -Jacques
> 
> -----Original Message-----
> From: Pete Wenzel [mailto:pete.wenzel@Sun.COM] 
> Sent: Tuesday, May 02, 2006 9:44 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] Outstanding Issues
> 
> The following list of issues is culled from the mailing list, and
> contains items raised against WD 12 & CD 02 that may not have been
> resolved yet.  Probably none are critical enough to delay public
> review of the spec, but I wanted to collect them in one location, so
> they don't get lost.  I believe all other recently proposed and agreed
> edits appear in WD 13.
> 
> --Pete
> 
> 
> Hamid 4/12:
> (f)    Figure 5 on page 18 need more details. First if we could find
> another drawing representation for the mpf (other than the pipe tube),
> that would be better. Second, the last use case where MSH J and MSH K
> are pulling messages from MSH G using the same mpf, this use-case is a
> little special and needs more explanation (it is not possible unless
> both MSH J and MSH K are serving the same action, service, and To
> parties).
> 
> <JD> 
> The pipe could still be a good analogy for [partitioned] message
> flows... and I thought lines 700-710 were explicit enough about the
> rationale for use case for MSH J & K ?

Addressed in Adjuncts.
Closed.

> (g)    Section 3.1 (page 21), I renamed P-Mode.protocol to
> P-Mode.channel on draft 9 that I wrote myself, but now it is renamed
> back to P-Mode.protocol. The reason I prefer the name P-Mode.channel
> is because I had included the MEP parameter in it. We all know now
> that the MEP is part of a P-Mode. However section 3.1 does not talk
> about it in the P-Mode parameters. I suggest to add MEP within the
> P-Mode.protocol and rename back P-Mode.protocol to P-Mode.channel.
> 
> <JD> Right now, the MEP is under P-Mode.businessCollaboration (rationale
> was: it may depend more on service/action than on protocol
> considerations, while the PMode.protocol is something more stable,
> common to several PModes) I think several approaches are possible: the
> whole P-Mode is illustrative and non-normative.
> 
> [Pete: On a related note, also raised by Ric below, is
> P-Mode.messageExchangePattern missing from 3.1?]

MEPs & MPFs are included under the businessCollaboration P-Mode;
remove P-Mode.messagePartitionFlows.

> (i)    Lines from 954 to 976 should all be removed (they say nothing
> special).
> 
> <JD> no objection.

Ian: Was necessary because, as of several years ago, MIME specs had
ambiguities w/r/t encoding declarations.  Leave until/unless someone
goes through due diligence to ensure current RFCs address this.
Also see Dale's reference to recent W3C TAG finding.

> Ric 4/18:
> namespace prefixes in examples:
> soap - http://schemas.xmlsoap.org.soap/envelope
> Or alternately we should modify the security samples in 6.9 to use the
> S11 namespace instead.
> D)
> The examples in section 4 and section 5 use the "SOAP" namespace
> prefix. The examples should be modified to use the S11 or S12
> namespace prefix.

Agreed to change all SOAP prefixes to "S11" throughout.

> B)
> 643 "P-Mode.businessCollaboration" It also indicates which MEPs and
> which MPFs are to be used by these parties.  The next line (644)
> dicusses P-Mode.messagePartitionFlows. Should the discussion about
> MPFs be removed from line 643?
> 
> <JD> or maybe P-Mode.messagePartitionFlows could just be removed and
> stay a parameter under businessCollaboration.

See discussion above.

> E)
> Figure 7 and Figure 8 refer to the wss namespace prefix. The figures
> should be updated to refer to the wsse namespace prefix.

To do.

> F)
> 7.3 ebMS Error Message
> I do not think the text is very clear in regards to when
> eb:MessageInfo/eb:RefToMessageId should be relied upon to link errors
> to messages. Vs. when eb:Error/@refToMessageInError should be used.
> The sentence at line 2205 throws me off a bit.  If the element
> eb:SignalMessage/eb:MessageInfo does not contain eb:RefToMessageId,
> then the eb:Error element MUST NOT be related to a particular ebMS
> Message.
> 
> <JD> (line 1683 on your 13 draft I think, last sentence of 6.3) agree
> this statement seems unnecessarily restrictive.

Delete mid-1680 "If this is the case..." through 1684.  Fix example:
remove reftomessageid; insert different reftomsginerror in each error
clause.

> Dale:
> Does info here on conformance profiles align with key word explanation
> of MAY in 1.4? That is, should we say:
>   When there are alternatives (indicated by MAY of section 1.4) the
>   precise impact on implementations is given by a conformance profile.
> 
> Do we want namespace value to resolve to schema? to rddl?

Maybe RDDL, but how do tools find schemas when this is done?  Requires
research.  Check how WS-RX TC is doing it:
http://docs.oasis-open.org/ws-rx/wsrm/200602/wsrm-1.1-rddl-cd-03.html

> (4/18 Comments on Section 2.1, Terminology.)

[Long discussion re MEP construction & connection with BP.  Continue at
F2F meeting next week.]

> (4/18 Comments on Section 9, schemas.)

An authoritative SOAP 1.1 schema can now be found at
http://schemas.xmlsoap.org/soap/envelope/

Unknown whether a similarly trusted source xlink schema exists.
Do we need xlink? Maybe just xptr or xpath instead?  TBD.

--Pete
Pete Wenzel <pete.wenzel@sun.com>
Sun Microsystems, SOA & Business Integration
Standards & Product Strategy
+1 (626)471-6311, Sun x61311, US-Pacific TZ