RE: [ebxml-msg] Outstanding Issues

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

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