Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML / HTML Transport size
 Rick Jelliffe wrote: > From: "Robin Berjon" <robin.berjon@e...> >>However if you look at the broadcast industry, there are cases in which >>the application does a lot more than just throw some XML around and yet >>using textual XML would be a serious hog (in fact impossible). > > I kinda don't get it. XML is a web technology, and HTTP allows compression. > If people don't turn on compression on their webservers, that is their problem. > If people want more efficiency, they could write serializers that generate > compressed data directly, and the reverse at the parser end. Hmmm, well I don't know what you're not getting because what you're describing is exactly what we're doing :) When HTTP is used BiM can be used as a simple content coding. When the XML is not already in textual form (but instead in SAX, DOM, etc) we write serializers that generate binary infosets directly. I was simply pointing out the fact that XML's verbosity is an acknowledged problem in a number of spaces, that it is perceived to have sufficiently interesting features to look into using it nevertheless, and that solutions that address the vrebosity exist. > I still have never seen any numbers that suggest that the cost of parsing > XML is not trivial compared to the cost of object creation. On what platforms have you seen the numbers you did see? > Especially when it is quite possible to write light-weight parsers that omit > most WF checks. If you can trust that your data is WF, you don't *need* to > check for name-correctness, for example. You can just tokenize > using space separators: this is appropriate for tightly-coupled systems or > routing systems, for example. Yes, but unfortunately that's not always the case as some systems have a wide variety of content creators. > XML was designed for this: perhaps the emphasis on Draconian error-handling > for WF and validity has obscured that XML was designed also to be useful for > the Desparate Perl Hacker True, but for that to be generally admitted we need to wait for Perl to take over the world ;) -- Robin Berjon <robin.berjon@e...> Research Engineer, Expway 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
