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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: Re: DTD, XSD and sample XML header docs

>Quite possible, I have so many versions and I was pretty tired;-)
>Thanks for taking the time to review.
>More comments below.
>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
>> of the header.
>> David
>> =====================
>> 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

Scott: I agree on the top ebXMLHeader tag and MessageManifest outside the
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.

>> 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.
>> 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
>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
>> 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
>> the only way, of achieving this.
>I don't see what the issue is. A 'code' *is* a URI if properly scoped. I
>actually quite uncomfortable in leaving too much to the imagination. I
>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

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)




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                 =

[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