Re: Versioning, "version" and namespaces

[christopher ferris <chris.ferris@east.sun.com>]

Rich,

Please see below.

Cheers,

Chris

Rich Salz wrote:
> 
> This is Technical discussion; I'm not sure if it's major or minor. :)
> 
> As I understand it, the MIME headers in the ebXML Message Envelope are
> there so that the carrying protocol (HTTP, SMTP, etc), can detect that
> the messages is an ebXML message and deliver it to the ebXML processor.
> That is, it's really nothing other than the same type of
> plug-in/dispatch that causes my browser to startup Acrobat when I click
> on a link to a PDF file.  Do they serve any other purpose?

No.

> 
> Therefore, it makes sense that this header have an identifying

which header is *this* header?

<snip/>


> content-type mean both the container and the header. Perhaps
> vnd.ebheader+xml?  I believe the version attribute (line 210ff) is a
> mistake, as is the charset attribute (line 218ff).  Both of these
> duplicate information that can be contained within the ebXML Header
> Document, in a completely self-contained XML-way.
> 
> It is already clear -- if only from internal editorial notes in the
> specification -- that duplicating information (especially in two
> different formats) will be problematic.
> 
> XML has a way to declare the character set of an XML document.  I
> believe the specification is made simpler if it omits the charset
> attribute and instead says
>         If the ebXML Header Document is not in UTF-8, then it MUST be
>         transmitted using base64, and so indicate with a C-T-E header.
> This could replace section 7.3.2.2 (lines 218ff) and section 8.1.2
> (lines 330ff)

This issue has been discussed at length. Most feel that the latest 
wording is adequate to indicate that the charset parameter is
NOT required, but if present, SHALL ...

I don't believe any change is warranted.

> 
> XML also has a way to do versioning -- the namespace.   Just as the DTD on
> line 357 has a date encoded in it, the namespace at line 373 should
> also:
>         http://www.ebxml.org/namespaces/2001/messageheader
> Later revisions of the specification will change the date, achieving
> versioning.

Now you've got me started;-) namespaces are NOT a versioning mechanism.
Use of a date is even less of a versioning mechanism unless there's only
one version per year (as in the example above).

The issue of namespaces and versioning has been discussed ad-nauseum on this
list (as well as on xml-dev, nearly to death!). Here are a couple of 
URLs that provide input for this issue:

	http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0385.html
	http://www.rpbourret.com/xml/NamespacesFAQ.htm

<snip/>
> 
> Section 8.2.1.1 (lines 372) require the default namespace for the
> ebXMLHeader document to have a particular value.  I don't think you can
> do that. :) And if you can, you shouldn't, as it needlessly prohibits a
> document like this:
>   <eb:ebXMLHeader
> xmlns:eb="http://www.ebxml/namespaces/2001/messageheader">
>     <eb:Manifest>
>       ...
> I believe most namespace-aware XML tools (except for XML
> canonicalization) generally make it hard for you to even tell the
> difference between an QNAME and a simple name in the current default
> namespace.

This point is well taken. Possibly, what needs to be said in the spec
is that the ebXMLHeader document SHALL have a qualified or unqualified
namespace psuedo-attribute that has a value of:
	http://www.ebxml/namespaces/2001/messageheader

> 
> Look forward to any comments.
>         /r$

-- 
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development 
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard