[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: RE: Regarding the Thursday ebXML Conf Call
Nikola: <SNIP> > With most parser implementations a pure XML encapsulation would only allow > the use of SAX parsing to avoid processing the entire message. </SNIP> Whoa!! This is bogus. In the context of valid XML, both SAX and DOM must parse the entire docoment to compare it with the schema/DTD to ascertain whether or not it is valid. A SAX parser can stop parsing if it encounters syntax error in well formed /valid XML. You are talking about parsing, not handlers for encountered instances. <Nikola> I am not sure that this would be possible, but just thinking loudly. Would this work? For large files: 1) Compose a XML msg where payload is XML as well.</NIKOLA> This would constitute an XML message. It is redundant to mention an XML message and XML payload. <NIKOLA> Payload is user specific so it might be that some of them would need to transfer 30MB image file. That file could be embedded (CDATA) or it could be referenced (URI) or whatever else.</NIKOLA> First of all, you cannot declare binary data as CDATA. Any handlers will puke on the input. "Embed" is a member function of the XLink:show namespace which issues a direction to include the referenced data into the document. If the XLink:actuate is selected to "onLoad", your handler will try to interpret pure binary data. The MIME type for XML is Text. Third - I cannot think of any rational how a 30mb image file can possibly be considered part of an XML e-business transaction. It could be the "subject" of the transaction, but XML is a text language. <NIKOLA> 2) Send it via ANY reliable protocol. Who cares about packets; requirement is that the whole XML msg is going to be delivered to the receiving end.</NIKOLA> I believe that TCP/IP - HTTP is the basis for which this will be built. The protocol MUST be O/S and Platform independant. We cannot accept anything less. HTTP has many of the built in error handling routines we need for ebXML and is also easily integrated with security protocols. <NIKOLA> 3) Use XML parser on receiving side. If SAX, go to manifest and find that there is a big file in the payload. Save it somewhere. If DOM good luck?</NIKOLA> Which XML Parser? If you are referring to the Perl parser (XML::Parser), the parser is built on top of James Clark's XPat parser in C. The parser does not actually embed the link. It just reads the text. It is the handlers that act upon the parsed XML that perform this functionality. Therefore, a link to a 30 mb file will parse just as quickly as a link to a 1 mb file. If you are building the message blocks for transporting, the construction of the messaging can be a very important aspect for efficiency. I do not think you should force people to use either DOM or SAX as part of a design rule.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC