OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: POC more nuts and bolts clarity


In preparation for freezing POC proposal tomorrow (as Nick suggested), I am listing below the items that we could use as a reference list for discussion tomorrow. If anyone sees anything else, please add to the list.

1. The Start header is removed from "Packaging" section but, still present in the "Transport" section. This needs to be removed from there (HTTP headers) also (page 10 of the latest draft).

2. In both "Packaging"  and "Transport" sections, the (top-level) multipart/related parts are shown with,
    Content-Length: int-length [units based on content-transfer-encoding]
The "units based on...." part in brackets above is not applicable since, multipart/related type does not have content-transfer-encoding (Multipart content-types cannot have encodings). I suggest we remove it for clarity.

3. What exactly the companies playing different roles need to be able to send and receive may not be clearly defined (as Jacques pointed). Here is my interpretation:

Any Issues with above interpretation?

4. TPAInfo.Action I suggest we use the RosettaNet *specified* names consistently for all. I think we need to change only the one for "3A4 PO Response". It should be "Purchase Order Acceptance Action". This impacts the 3A4 PO Response xml instance (pp6,7) but,  in order to avoid any confusion I suggest we use the term "Purchase Order Acceptance" where ever we used "PO Response".

5. The TPAInfo.TPAId URI, is set by the "initiator" of the PIP (i.e. sender of the "PO Request" message) and stays at the "same value" for all messages (the PO Acceptance and the two Acks) in the PIP instance. That is, "/initiator-DUNS/responder-DUNS/PIP3A4/1.1" (e.g. /111111111/222222222/PIP3A4/1.1) stays fixed for the entire PIP instance (all four messages). Agreed?

6. Content-Id values: Are we *requiring* them to be in the form <uid@domain> form?, where uid is some number unique within the "domain" and domain is, message sender / receiver domain as the case may be (e.g. vitria.com). An example instance 1111@vitria.com, 1112@vitria.com so forth.

7. The "TPAInfo.ConversationId" (UUID in the form uid@domain) must also stay at a fixed value for all four messages in the PIP. This value again is set by the "initiator" of the PIP, just like the TPAInfo.TPAId.

8. This is probably obvious but, the MessageId.RefToMessageId *must* have the value for the message that this is in response to. That is, in figure 2, messages 2 & 3 must have the value for 1 and 4 must have the value for 3. 1 of course has the value "Not Applicable" as shown.

9. In the new TPA section, some of the element's purpose is sort of straightforward but, others are not so obvious. Since we are requiring people to supply this, we need some details on the purpose of and semantics of the many of the elements. For example,  the "DeliveryChannels" and the ids used in there etc., what is the purpose of these and do they have any relevance outside the TPA itself? That is, do they go in any field in ebXMLHeader for example (I guess not but).. This seems too complex to use at such a short notice. Can we simplify this? A completely filled out example that we could use is needed. I mean, a number of fields are left blank in there. For example <Participants>.<Member>.MemberId is supposed to give the DUNS number but, in the example instance it is " ".

10. The ebXMLHeader specification does not have a "version" attribute for TPAInfo.Action element.  The example ebXMLHeaders all have it. Actually we need it (I think Chris was also planing to add), but it is not there in the spec yet. So, should we go ahead and modify the DTD to add the version attribute?

Thanks, Prasad

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC