[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Pushing all the buttons


Re:  Pushing all the buttons
On Sun, 2003-09-21 at 05:33, Mike Champion wrote:
> [Quoting from Bray, St. Laurent, and de Hora ...]
> 
well, i've written parsers for languages, edi, my own (text) languages,
and having done a few projects now with xml and xslt (xsltproc) i can
only say that it is dramatically faster for me at least to use an xml
format and xsltproc to translate the xml to some sort of executable -
postscript, tcl, my own languages etc

i think it's the essentially nonprocedural nature of xslt that makes for
efficiency. but then i've been a nonprocedural programmer for 20 years
so i have a bit of practice at the changed mindset.

a lot of this streaming/binary stuff comes from the fact that
programmers like to procedurally control things and on the whole seem to
adapt very badly to giving up control. xml for web services and the like
is a big giving up of control so we'll continue to see lots of this
stuff.

rick

> "Oppers" == "operations staff trying to debug the
> bloody thing" ??? :-)
> 
> This (and Simon's point about tools) raises a very
> interesting question: is the more-or-less-indisputable
> fact that one can get an XML distributed app up and
> running much faster than a proprietary-format
> distributed app due to the standards-ness of XML or
> the text-ness of XML?  If you took away the text-ness
> but put an alternate standard (or two, or some very
> small number of standards) in its place, how much of
> this implementation efficiency would you lose?  How
> much time do "oppers" really spend debugging XML
> streams, and would their productivity suffer if they
> had to use some little tool rather than Notepad do so?
>  [Not a rhetorical question ... I really don't have an
> opinion on this].
> 
> > 
> > If there are plenty of customers who are deeply
> > concerned about 
> > performance then maybe this work has value, but I
> > still think 
> > optimizing the parsers is a better strategy,
> 
> There are an awful lot of people out there working on
> closed source optimized SOAP-XML parsers, again AFAIK.
>  I have enough faith that Sun hires sensible people to
> be fairly sure they tried this before -- probably
> reluctantly -- concluding that ASN.1 has a lot of
> advantages IN THE SPECIAL CASE where all parties know
> the schema of the data on the wire.  In the case of
> SOAP, the middleware doesn't have to know the schema
> of the SOAP body, just that of the headers that it
> understands (e.g. WS-Security, for firewalls). 
> 
> > even if you proved 
> > it wasn't,  I think I'd look for a briefer text
> > format first 
> > (xml2rnc for example), before I'd get into binary
> > codecs.
> 
> Yup.  It would definitely be interesting to see if
> something akin to RNC might be both more
> human-readable and more machine-efficient as an
> Infoset serialization format, at least for certain
> niches. 
> 
> As best I know, the big win for truly binary XML
> serializations is in avoiding the overhead of the
> Unicode-encoded text to UCS-character translation. 
> Does anyone take issue with the assertion that the
> external encoding-> Unicode text translation is
> generally a significant portion of XML parsing time?  
> 
> Of course, the big downside for all alternative
> serializations is that they seriously limit 
> interoperability.  But remember that the whole POINT
> of this "efficient alternate serialization of the
> Infoset" stuff is to buy performance at the cost of
> some interoperability, to be used in specifically in
> situations where the pain of worse performance is
> worse than the pain of lower interoperability. And the
> whole point of standardizing a small number of
> alternative serializations would be to get some of
> that interoperability back.
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.