RE: DTD, XSD and sample XML header docs

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

Chris

I'm not absolutely sure, but I think you might have based your DTDs on a
slightly out-of-date version of the spec. I've compared what you've done
with version 0.5 of the header spec and here are the differences ... and
also a couple of questions/comments. These are all based on the XSD version
of the header.

David
=====================
1. MESSAGE MANIFEST
This should not be in the header, the structure should be more like ...
<ebXMLHeader>
  <MessageManifest>
    ...
  </MessageManifest>
  <MessageHeader>
    ...
  </MessageHeader>
</ebXMLHeader>

2. REF MESSAGE ID
a) This should be RefToMessageId
b) It isn't optional since if there is no earlier message it contains
"NotApplicable"

3. TRANSPORT SLA ID
a) This should be optional as it defaults to a "standard SLA for the
Transport Protocol". (Although if we are to be consistent with
RefToMessageId, perhaps it should contain "StandardSLAForTransportProtocol")
b) I don't think we can mandate this be a URI, for the same reason that we
can't make "Address" a URI. It just needs to be a code that can be
recognized unambiguously by the parties involved. A URI is one way, but not
the only way, of achieving this.

4. RELIABLE MESSAGING INFO
a) the enumerated list should just have "AtMostOnce" and "Unspecified" in it
b) I think we need to cater for three situations eventually (... but perhaps
not in a level 1 header). Specifically:
  i) Where there is no reliable messaging implied (i.e.
DeliverySemantics="Unspecified")
  ii) Where there is reliable messaging (DeliverySemantics="AtMostOnce", but
there is no Transport SLA. In this case either:
      * use ebXML specified default values for the Transport protocol if
there is no TransportSLAId specified, or
      * include the required paramter information in the Reliable Messaging
Info, this will have to wait until after we've done the Reliable Messaging
Spec
  iii) When there is a pre-existing Transport SLA, in which case, perhaps we
should set DeliverySemantics="TransportSLA"
Either way I think we need to do more thinking about this as we work on the
reliable messaging spec.

5. ADDRESS and ADDRESS CONTEXT
I'd prefer the style ...

  <From>
    <PartyId AddressContext="duns">12345</PartyId>
  </From>

... or perhaps it would be better as ...
  <From>
    <PartyId
      <Address Context="duns">12345</Address>
    </PartyId>
  </From>

... if the address cannot be expressed as a URN, or ...

  <From>
    <PartyId >urn:duns.com#12345</PartyId>
  </From>

... or perhaps ...

  <From>
    <PartyId
      <Address>urn:duns.com#12345</Address>
    </PartyId>
  </From>

... if it can.

6. DOCTYPE and DOCID
a) Why do we abbreviate these ... I don't think we abbreviate anything else
b) "DocType" should be "DocumentLabel"
c) We will, in the spec, need to  provide much more precise semantics on how
to identify documents within the same message.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Monday, June 19, 2000 6:02 PM
To: Ebxml Transport; Christopher Ferris
Subject: DTD, XSD and sample XML header docs


All,

Okay, I've been meaning to get this done for a while now.

Here are the "level1" DTD, XSD and sample XML documents
based on the "published" header spec.

Your comments and feedback are welcomed. I have added a
few annotations to spice things up a bit and generate some
discussion.

Most notably:
	- do we need ReliableMessagingInfo if we have a TSLA
	- Should the PartyId be expressed as elements or as
	follows:
		<!ELEMENT PartyId (#PCDATA)>
		<!ATTLIST PartyId context CDATA "Undefined">
	or optionally:
		<!ELEMENT PartyId #EMPTY>
		<!ATTLIST PartyId 
			context CDATA "Undefined"
			uri CDATA #REQUIRED>
	of course, URI should have its own built-in context, so it
	isn't clear that the context attribute adds any value. 
		e.g. uri:duns:12345

Anyway, keep those cards and letters coming;-)

Chris


	
-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

=======================================================================
= This is ebxml-transport, the general mailing list for the ebXML     =
= Transport project team. The owner of this list is                   =
= owner-ebxml-transport@oasis-open.org                                =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-transport                                    =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-transport myname@company.com                 =
=======================================================================