RE: TRP spec 0.9a comments/feedback

["Burdett, David" <david.burdett@commerceone.com>]

Saikat

Thanks for your helpful comments. See responses below.

David

-----Original Message-----
From: Saha, Saikat 
Sent: Wednesday, January 03, 2001 4:16 PM
To: 'ebxml-transport@lists.ebxml.org'
Subject: TRP spec 0.9a comments/feedback


David,

These are my comments/feedback on TRP 0.9a spec.
Most of them are in the inconsistency between the different element
definition and the actual schema in Appendix A.1.

1. ebXMLHeader XML schema(Appendix A.1), Header element is missing
SynchronousMessagingInfo element 
which is defined in Synchronous Messaging(sent yesterday by Prasad).
<DB>Prasad worked independently and in parallel on his paper on Synchronous
messaging. Prasad, Dick Brooks and I discussed his paper last Friday on the
phone. I took several of Prasad's ideas into account in developing the
version 0.91 spec. However I did not think that we needed a complete
separate Synchronous Messaging Info element in the header. Obviously this
needs to be discussed.</DB>

2. Should we have both DTD and XSDL based schema in the appendix of the
specification, some of 
the examples refer to DTD whereas appendices show XML schema? There is a
placeholder(appendix A-2) for  DTD.
<DB>There is an intention to do a DTD as well as an XSD. However Chris
Ferris and I think that we should make the XSD normative with the DTD as an
alternative. It will be produced once the Schema definition has been
reviewed and agreed.</DB>

3. Synchronous Messaging spec,. DeliveryReceipt and IntermediateAck. Why
both are required? Last intermediary
cannot produce IntermediateAck before it receives the DeliveryReceipt from
receiving MSH or intermediary nodes can create
IntermediateAck before they receive any response from next node?
<DB>The whole idea of an intermediate ack is so that the intermediate node
can return a response **before** they receive a reply from the next
destination. This is useful particularly if end-to-end transmission times
are long. This way, the sender of the initial message can turn off their
timeout and rely on the intermediate node notifying them if they could not
deliver the message. To draw an analogy with the real world, if you go to
FedEX or UPS, they give you a receipt immediately. You don't hang around
until your package has reached its final destination. You also don't keep on
pestering FedEx to ask them if the package has got through.</DB>
<DB>I could not follow these until I realised you are talking about 0.91 and
not 0.9a !!</DB>

4. Line 334 should be "compliant".
<DB>Correct</DB>

5. Line 337 example shows dtd whereas appendices has xml schema.
<DB>Good point we need to be prescriptive about what goes in the Prolog
depending on whether we have a DTD or XSD.</DB>

6. Line 427 says  Manifest element MAY have ID whereas line 2071 says
"required".
<DB>Line 427 should be MUST</DB>

7. Line 2078,  Can the minOccurs of schema element be "0" for a particular
Reference element? I suppose this is for non
xml based parts of payload.
<DB>Correct</DB>

8. Line 443,444, attribute xml:type takes fixed value "simple", Line 2083
should be fixed.
<DB>The schema definition needs to be fixed.</DB>

9. Line 383, RoutingHeaderList element must be present for both reliable
messaging and also if messages
are exchanged over multiple hops.
<DB>Agreed</DB>

10. Line 388 and 392, Why ApplicationHeader element and StatusData element
cannot co-exist? Sending MSH can
send a message requesting status alongwith some other information for the
application layer at the receiving end.
<DB>On second thoughts, I agree with you. Application headers should be
allowed.</DB>

11. Line 443 says xlink:type attribute is required whereas Manifest sample
in section 8.3.2 does not have this.
<DB>If a value is "fixed" then, I don't think needs to be present since the
value to apply can be deduced from the DTD/Schema definition.</DB>

12. From element is missing in schema for ebXML Header.
13. Line 497 says From/To comprises of PartyId, Line 2121 To element doies
not contain PartyId element
<DB>I think the spec is probably wrong. We have in earlier email threads
discussed removing Party Id and changing To and From so that the To or From
ID is in the content as in <To type="foo">id-value</To></DB>

14. Line 531 says Service element has type attribute whereas 2135 does not
contain.  
<DB>The schema needs correction.</DB>

15. Section 8.4 does not say about Description element whereas this is
present in 2114
<DB>The list on lines 483-491 is wrong. It should include Description.
Description is actually defined in section 8.4.8.</DB>

16. Line 623 8.4.7.3 section syncReplyMode attribute is missing in the
schema 
<DB>The schema needs to be corrected.</DB>

I have been able to cover upto Header element. I will send rest of my
comments tomorrow.

Regards,
Saikat