Re: FW: Latest Specification document

[srh@us.ibm.com]

Sounds good to me at this point.

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@Sun.COM> on 05/04/2000 10:27:38 AM

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:   Christopher Ferris <chris.ferris@east.sun.com>, Murray Maloney
      <murray@muzmo.com>, "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




It would seem to me that imposition of a requirement
for a root element for the payload would be unwise. This is
especially true when one considers that it should be possible
to exchange messages from any vocabulary which may itself
impose some requirement for a predetermined root element.

We also have the case where it should be possible to send
multiple documents as the message payload. A single root element
could not be easily applied in this case either. Finally,
we are also intending to support the exchange of non-XML
payload content which precludes the ability to support
a root element (or any other XML construct for that matter!)
without imposing some additional encoding scheme (Base64, etc.).

It would propose that the MesssageHeader element should be
called MessageHeader with a namespace attribute which declares
the ebxml namespace and a version attribute which identifies
the version of the ebXML TR&P Message Header specification.

eg.

<MessageHeader
     xmlns="http://www.ebxml.org/<...>/MessageHeader"
     version="1.0">
     <!-- ebXML header elements -->
</MessageHeader>

Cheers,

Chris

srh@us.ibm.com wrote:
>
> 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
> > >