Re: [Fwd: Re[2]: Concern with basic ebXML TRPSyntax/Semantics] (I'm Away)

["Michael Shalev" <Michael@idap.co.il>]

Hi,

I'm currently abroad, but will return on Sunday, April 16th.

Thanks, and have a nice day,

Michael Shalev
Director of Development
iDap Ltd.

>>> ebXML-Transport 04/13/00 01:51 >>>

Prasad,

Basically, I agree. There are good reasons to separate the
header from the payload.

XDR shouldn't be considered, it isn't a W3C rec. XSD is in last call,
but will then enter the (lengthy) Candidate Recommendation phase. Regardless,
there aren't a whole lot of XSD capable parsers out there yet. This will
surely change, but there will be a need to handle DTDs for some
time to come IMO.

Cheers,

Chris

Prasad Yendluri wrote:

> David,
>
> Pls see below marked with <PY>
>
> David Burdett wrote:
>
> > Prasad
> >
> > See comments below marked with a ##
> >
> > David
> >
> > -----Original Message-----
> > From: Prasad Yendluri [mailto:pyendluri@vitria.com]
> > Sent: Tuesday, April 11, 2000 3:59 PM
> >
> > XSD is still in draft state (last draft dated April 7,2000). Not sure if
> > ebXML can base specifications on drafts. Can XDR be considered open for use by
> >
> > ebXML
> > ?
> > ##Using XSD, vs DTD vs XDR (or even C1' SOX) should not be an issue as in
> > the *instance* they are all the same apart from the doctype. This means that
> > we can process a document that was generated using a schema with a DTD
> > provided we can map from one definition to another.##
>
> <PY> True but ebXML needs to "specify" the document structure (i.e. the
> normative definition)  using one of the schemes namely DTD, XDR or XSD etc. Only
> XSD and XDR have a mechanism to specify message format with varied business
> content. Hence if we were to define a pure XML format, the schema language to be
> chosen (XDR/XSD etc.) becomes an issue. My point was XSD is still in draft state
> and XDR is a specification by MS.</PY>

>
>
> > Given that, we still don't have an XML solution. Even with the proposed
> > namespace route, the actual instances of the documents still would contain
> > the header(s) and payload in one XML document. Which does not lend itself to,
> >
> > 1. Routing by third parties (Hubs)  that need not and should not  look into
> > business content.
> > ##If you place the critical information, needed by routing near the start of
> > the message, then you can parse it to find the critical information you need
> > with a simple SAX parser or even treat the document as straigt text. This
> > means that errors, apart from the most fundamental, would not cause
> > problems.##
>
> <PY> Still the routing entity will have access to the business content. There is
> no way to prevent (say by encrypting), the routing party from looking into the
> business content. To contrast if the (routing) headers and payload are separated
> out into two different XML parts packaged together with MIME, then the payload
> part can be encrypted by itself if needed. </PY>
>
> > 2. Efficient routing (internal to an organization or otherwise) based on
> > just the fixed format header only.
> > 3. Error reporting back even if the business content can not be handled by
> > receiving side.
> > ##These can also be handled by initially doing a very simple (non-XML) parse
> > of the document.##
>
> <PY> Possible but I am not sure if we want to base our specifications on
> non-standard parsing of documents as a requirement for handling errors.
> Especially when there is a cleaner alternative. For example, if the two parts
> are really separated out so that the fixed (routing) header part can be handled
> by all implementations uniformly. </PY>
>
> > Additionally for attaching binary content we still need a MIME like solution.
> > ##I also agree with this.##
> > Above IMHO are important factors to consider into the mix  for the packaging
> > scheme.
> >
> > Prasad
> >
> > Ravi Manikundalam wrote:
> >
> > > Agreed - the namespace recommendation only  enables the construction of
> > > "modular XDR or XSD" schemas and not modular DTD's.
> > >
> > > -----Original Message-----
> > > From: Alan Blount [mailto:blount@metratech.com]
> > > Sent: Tuesday, April 11, 2000 7:24 AM
> > > To: Ravi Manikundalam
> > > Cc: ebXML Transport (E-mail); 'Prasad Yendluri'; James McCarthy
> > > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> > >
> > > Could you show us exactly how this is done?  I was under the (perhaps
> > > mistaken) impression that one cannot create valid (verifiable by DTD) XML
> > > documents that refrence more than one DTD.  My understanding is that the
> > > namespaces reccommendation does not allow for "modular DTDs."
> > >
> > > Best regards,
> > > Alan Blount
> > >
> > > http://www.jclark.com/xml/xmlns.htm
> > >
> > > -----Original Message-----
> > > From: Ravi Manikundalam [mailto:ravima@microsoft.com]
> > > Sent: Tuesday, April 11, 2000 12:32 AM
> > > To: 'Prasad Yendluri'
> > > Cc: James McCarthy; ebXML Transport (E-mail)
> > > Subject: RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]
> > >
> > > By using name spaces you can create a single XML Document instance whose
> > > content is defined by 1 or more element type or schema definitions from
> > one
> > > or more name spaces, which means even though you may have multiple schema
> > > files for the various XML parts in the "message" you can have a single XML
> > > Document Instance that packages them all into a single DOM.