[
Lists Home |
Date Index |
Thread Index
]
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>
|
