RE: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]

[David Burdett <david.burdett@commerceone.com>]

See comments marked with <db>

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Wednesday, April 12, 2000 4:02 PM
To: David Burdett
Cc: ebXML Transport (E-mail)
Subject: Re: [Fwd: Re[2]: Concern with basic ebXML TRP Syntax/Semantics]


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>
<DB> I think we need to specify the structure of the header initially as a
DTD and the validation rules for the content of the DTD in the Data
Dictionary part of the header. When Schema becomes available we then
implement many of the validation rules in the schema language. Implementers
then have a choice of either a) letting the schema language do the
validation where this is possible, or b) using the DTD equivalent and
writing application logice to check the content is valid. </DB>

> 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>
<DB> This is a very good point. There is currently no standard for
encrypting parts of XML documents although an initiative is just starting in
the W3C. This means, unless we invent one which is not a good idea, we have
little option I think but to use S/MIME if we want to encrypt documents.
This means we will have one way of doing wrapping if the conent is encrypted
and another way if it is not.</DB>

> 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>
<DB> Even if they are separated, the "fixed" header part can still have
errors. You are then left with a choice of action to take:
1. Do nothing - i.e. don't report the error
2. Report the error using the Transport Protocol to determine where to send
the error message to. ie the From email address for SMTP and the HTTP
response for synchronous messages. However this doesn't work if you are
using HTTP asynchronously.
3. Scan the header serially, even though it not valid XML, to identify
likely candidates for return address and use those.
I prefer option 3. </DB>

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