MHonArc v2.5.0b2 -->
ebxml-msg message
[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]