Re: FW: Latest Specification document

[Christopher Ferris <chris.ferris@east.sun.com>]

This would be a much better approach (IMO) than
use of PIs or a single, required root element
tag such as <ebXML> especially given that 
there will be separate documents (header
and payload at least, possibly others). See
John I's message.

Cheers,

Chris

Murray Maloney wrote:
> 
> 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
> >