[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: DTD, XSD and sample XML header docs
Chris
See comments below marked with <db></db>
David
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Tuesday, June 20, 2000 7:45 PM
To: David Burdett
Cc: Ebxml Transport
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.
<db>I agree that this should just be Header and use a namespace to qualify
it. On this point, I've just been looking at the XMLdsig spec and they use
the namespace for versioning (see
http://www.w3.org/TR/2000/WD-xmldsig-core-20000601/). This is also the
approach used by SOAP (see http://www.w3.org/TR/2000/NOTE-SOAP-20000508. We
should consider using a similar versioning approach ourselves.
</db>
>
> 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.
<db>Sounds good to me</db>
> 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.
<db>Except that if you want to be sure that your URI is unique I think you
either need a domain name or register your URN if you want to be sure you
are unique. I don't think we should force people to do this before they use
ebXML messaging.</db>
>
> 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,
<db>... except that they aren't in the v 0.5 spec</db>
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.<db>Perhaps but only if WE define exactly what the
semantics mean ...</db>
> 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;-)
<db>Yes, but not everyone will have a URN they can use.</db>
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
<db>I think there's a misunderstanding.
1. DocumentId should be a href. As it points to the document. However if you
have four DocumentIds in the manifest and you want to find, say, the
document that is say a picture of a product, you can't find out which one it
is without retrieving each document and guessing !!.
2. The idea of DocumentLabel is that it give the *reason* or *purpose* that
the document is there so that you can then search the DocumentLabels, eg.
for "ProductPicture" and then retrieve the correct document immediately.
</db>
(actually, I would much
prefer if we consistently used all CAPS for ID e.g. DocumentID ;-)
<db>I think a simple vote on this would solve the issue</db>
> 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