Re: DTD, XSD and sample XML header docs

[srh@us.ibm.com]

>>David,
>Quite possible, I have so many versions and I was pretty tired;-)
>Thanks for taking the time to review.
>More comments below.
>Cheers,
>Chris
>David Burdett wrote:
>> 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>
>It isn't clear that we need to label the header element 'ebXMLHeader'
>if it is qualified by a namespace and then have a separate MessageHeader
>element contained within. I certainly have no problem with this, just
>asking the tough questions;-) If others agree, then I'll make the
>change.

Scott: I agree on the top ebXMLHeader tag and MessageManifest outside the
MessageHeader.
I might suggest <Manifest> and <Header> but I'm not picky on this.
Top tage would eventually facilitate a top control point for versioning
(once we figure out the
approach on this!), etc. I think we should end up with all sanctioned
ebXML tags being namespaced.

>>
>> 2. REF MESSAGE ID
>> a) This should be RefToMessageId
>> b) It isn't optional since if there is no earlier message it contains
>> "NotApplicable"
>>
>Okay, I'll add that constraint and usage comment.
>
>> 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")
>
>I would prefer 'default'. See 20 character rule below.
>
>> 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.
>
>I don't see what the issue is. A 'code' *is* a URI if properly scoped. I
am
>actually quite uncomfortable in leaving too much to the imagination. I
would
>much prefer that we adhere to use of URIs as that was their intent. Bottom
>line is that it is just a string even if it IS a URI and that can be
>handled just like a 'code' in the implementation details of resolving the
>URI, IMHO.

Scott: Why not handle this by adding context,
just like it is done with Address below.....(no end tags shown, skipping
element/attribute religion, etc)

<TransportSLA>
 <TransportSLAIdContext>
  JoesAuthority
 <TransportSLAId>
  36755

or

 <TransportSLA>
 <TransportSLAIdContext>
  URI
 <TransportSLAId>
  http://-----whatever


Scott Hinkelman
Senior Software Engineer, SWG IBM Austin
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



=======================================================================
= 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                 =
=======================================================================