[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-msg] Outstanding Issues
(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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]