[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DTD, XSD and sample XML header docs
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.
>
> 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.
>
> 4. RELIABLE MESSAGING INFO
> a) the enumerated list should just have "AtMostOnce" and "Unspecified" in it
I thik we should discuss this. I don't see any reason why we wouldn't want
to include them all at this stage, even if we aren't going to specify these
levels in the original round of the RMS. Implementations should be free to
use these semantics, IMHO.
> 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.
Agreed that we need to discuss further. I started thinking this just after
I finished the DTD, etc last night and I'm probably getting closer to where you
are on this issue;-) Let's plan on a discussion during the con-call if there's
time. I'm pretty busy 'til then I'm afraid.
>
> 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>
I prefer the former, but still think that a URN would
be more than adequate;-) In that event, it isn't clear
what value add there is of the nested elements when
<From>urn:duns:12345</From>
or
<From address="urn:duns:12345"/>
would do. Oops, I hear the attribute vs element war heating up!
Hold onto your hats!
>
> ... 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
I abbreviated TransportServiceLevelAgreementId !!!!! Actually, I started
from the work that John I started with, so I was probably lazy and didn't
change those elements which were essentially the same from the original
level4.dtd. I have no issue with expanding the naming. I do think that
we should have an ebXML style guide as someone suggested. Maybe a limit
of 20 chars on an element or attribute name and then it is okay to
abbreviate as long as the DTD/XSD is well documented with the explicit
meaning of the element name, etc.
> b) "DocType" should be "DocumentLabel"
Actually, DocumentLabel can be expressed as an href (and it may well be
an href) and therefore I would prefer DocumentId (actually, I would much
prefer if we consistently used all CAPS for ID e.g. DocumentID ;-)
> c) We will, in the spec, need to provide much more precise semantics on how
> to identify documents within the same message.
Indeed!
>
> -----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 =
> =======================================================================
--
_/_/_/_/ _/ _/ _/ _/ 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 =
=======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC