[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Outstanding Issues
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 ? (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?] (i) Lines from 954 to 976 should all be removed (they say nothing special). <JD> no objection. 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. 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. E) Figure 7 and Figure 8 refer to the wss namespace prefix. The figures should be updated to refer to the wsse namespace prefix. 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. 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? (4/18 Comments on Section 2.1, Terminology.) (4/18 Comments on Section 9, schemas.) -- Pete Wenzel <pete.wenzel@sun.com> Sun Microsystems, SOA & Business Integration Standards & Product Strategy +1 (626)471-6311, Sun x61311, US-Pacific TZ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]