[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Doug's Version proposal
David, > The version in the MIME envelope... I can see that utility and wouldn't want to tie these semantics to the version of the contained ebXML Header document. My current proposal handles this separation correctly. If you feel we need additional words about additional uses for this particular MIME version attribute, that should be considered separately (and later). > Also, errorList will now assume the version number of the complete schema and doesn't need one of its own. This is exactly why my comments on the old ebXMLError element are no longer relevant. thanx, doug -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: January 5, 2001 11:45 To: 'Doug Bunting'; ebXML Transport (E-mail) Subject: RE: Doug's Version proposal The version in the MIME envelope indicates, for example that it is multi-part related, the ebXML header MIME part comes first and the **single** payload MIME part comes next. I would have thought that this is useful information as in the future we might want to change it to allow, for example, ebXML headers inside an XP outer envelope. Thoughts? Also, errorList will now assume the version number of the complete schema and doesn't need one of its own. David -----Original Message----- From: Doug Bunting [mailto:Doug@ariba.com] Sent: Friday, January 05, 2001 11:05 AM To: Burdett, David; ebXML Transport (E-mail) Subject: RE: Doug's Version proposal David, A reasonable question. My take on this is reflected in the proposal. - The payload envelope doesn't have an ebXML version attribute because the semantics of that envelope are tied to its contents. - The version attribute of the header envelope MUST match that of the contained XML document. It was my understanding we added that particular attribute precisely to provide an early warning of the version used within. - The outermost MIME envelope shouldn't require a particular version. (Partially, this reflects my feeling that this particular attribute doesn't provide that much value.) I don't see a reason to prevent an ebXML TRP 2.0 ebXML Header envelope and document to be transferred within an ebXML TRP 1.0 ebXML envelope (or visa versa). While I'm thinking about it, note: My comments on the ebXMLError element are no longer relevant. If that element (which is no longer used as a top-level element) or its replacement ErrorList mentions a version attribute in the text or schema, the attribute should be removed. thanx, doug -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: January 5, 2001 09:49 To: ebXML Transport (E-mail) Subject: RE: Doug's Version proposal Doug Your suggestions make sense. The only question I would have is should you allow different version numbers on the MIME envelope the header envelope and/or the payload envelope? David -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@east.sun.com] Sent: Thursday, January 04, 2001 9:28 AM To: ebXML Transport (E-mail) Subject: Doug's Version proposal http://lists.ebxml.org/archives/ebxml-transport/200012/msg00181.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC