Re: FW: Latest Specification document

[Murray Maloney <murray@muzmo.com>]

Actually, there is an even better solution...

The <ebXML> solution is a problem because it places
an unnecesary restriction on the root element of
ebXML documents. That is, there are various legitimate
reasons for wanting control over the root element name.

A simpler approach is to require the root element to be
of 'type="ebXML:document"' where 'ebXML' is a token
representing the ebXML namespace, and 'document' is a 
reserved name in the ebXML namespace.

Every ebXML document could identify its namespace:

	<My.ebXML.Document xmlns:ebXML="...">
	...
	</My.ebXML.Document>

In a closed system, we could assume that every document is an 
ebXML document. The root element needs no additional information 
because it can be safely implied.

In an open system, an ebXML document could fully identify itself 
with a 'type' attribute on the root element:

	<My.ebXML.Document type="ebXML:document" xmlns:ebXML="...">
	...
	</My.ebXML.Document>

Now, we need only define the characteristics of the ebXML document type.

Finally, we could also define the 'ebXML' element in the ebXML namespace
to be of type='ebXML:document', and then the following expressions are
equivalent for the purposes of identifying an ebXML document:

<ebXML         xmlns="http://www.ebXML.org/...">
<ebXML:ebXML   xmlns:ebXML="http://www.ebXML.org/...">
<My.ebXML.Root type="ebXML:document" xmlns:ebXML="http://www.ebXML.org/...">

-- The first example establishes the default namespace, from which
   one can discover the definition of the ebXML element, leading
   to the discovery that <ebXML> is type="document"
-- The second example is an inversion of the same discovery process,
   wich uses the namespace prefix instead of a default.
-- The third example establishes the ebXML namespace, and declares
   that <My.ebXML.Root> is type="ebXML:document"

The result is that one can use <ebXML> or any other element root.

This is how I would do it to take advantage of XML Schema and Namespaces.

BTW, processing instructions are widely deprecated by tools developers.
Attaching information to a node (element/attribute/type) makes it more
readily accessible by standard APIs and tools.

Regards,

Murray

At 02:09 PM 5/2/00 -0400, Miller, Robert (GXS) wrote:
>Hi All,
>
>The Architecture Document (Section 3.5.5 a)(TechArch group) currently
>proposes that an ebXML document be framed within an 'ebXML' element. 
>TR&P is referenced in an Editor's note to this rule. See below:
>
>  a)      The message will use a root tag of <ebXML> to identify it as an
>ebXML compliant transaction.
>
>  [EDITORS NOTE:  THE TRP GROUP MUST EITHER ADOPT THIS OR SPECIFY AN
>ALTERNATIVE IDENTIFICATION ELEMENT OR METHOD]
>
>I do not support this means of identification, and propose instead that an
>XML conformant document include a 'Processing Instruction' asserting ebXML
>compliance.  I suggest:
>
>	<?ebXML version='1.0' reference='someURI'>
>
>where 'version' provides the ebXML version to which compliance is claimed,
>and 
>      'reference' provides a URI for use in accessing a repository of
>metadata relating to this message. 
>
>I believe this approach is less intrusive upon XML syntax.  It eliminates
>the need, if a DTD (or other schema declaration)is used, to define an ebXML
>element and its allowed content.
>
>Cheers,
>        Bob
>