Re: FW: Latest Specification document

[srh@us.ibm.com]

One other consideration is to hold back on the use of <ebXML> and
think toward something like <ebXMLHeaderEnvelope> since our
current direction is in multiple parts and not one document . We should
consider that at some future point <ebXML> may make sense as a top tag for
a
pure XML approach, which would then include <ebXMLHeaderEnvelope>.

(and do we have a position on imposing any top element on the
upper level business content?, if so we should consider
<ebXMLPayload>.......).

Scott R. Hinkelman
Senior Software Engineer
XML/Java Solutions/Standards
Architecture and Development
IBM Austin
Office: 512-823-8097 TieLine: 793-8097
Home: 512-930-5675, Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074



Christopher Ferris <chris.ferris@east.sun.com> on 05/03/2000 08:19:21 AM

To:   Murray Maloney <murray@muzmo.com>
cc:   "Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>,
      ebXML-transport@lists.oasis-open.org,
      ebXML-Architecture@lists.oasis-open.org
Subject:  Re: FW: Latest Specification document




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
> >