[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [Fwd: Re: Concern with basic ebXML TRP Syntax/Semantics]
See comments marked with <db> -----Original Message----- From: Prasad Yendluri [mailto:firstname.lastname@example.org] Sent: Wednesday, April 12, 2000 4:02 PM To: David Burdett Cc: ebXML Transport (E-mail) Subject: Re: [Fwd: Re: 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:email@example.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:firstname.lastname@example.org] > > Sent: Tuesday, April 11, 2000 7:24 AM > > To: Ravi Manikundalam > > Cc: ebXML Transport (E-mail); 'Prasad Yendluri'; James McCarthy > > Subject: RE: [Fwd: Re: 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:email@example.com] > > Sent: Tuesday, April 11, 2000 12:32 AM > > To: 'Prasad Yendluri' > > Cc: James McCarthy; ebXML Transport (E-mail) > > Subject: RE: [Fwd: Re: 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.
Powered by eList eXpress LLC