paul wrote: > > XML-RPC's relationship to Unicode is ill-defined. The spec that Dave Winer > > wrote requires all data to be US-ASCII, so XML-RPC isn't really > > XML-compliant. (You'll have to take up issues of standards compliance with > > Dave.) > > Most XML-RPC implementations support Unicode, Dave Winer > notwithstanding. Plus, the XML-RPC spec says nothing to indicate that > XML-RPC documents may not be encoded in either of XML's two built-in > encodings (even if the data is restricted to ASCII values). the specification says that XML-RPC uses XML and HTTP. it doesn't say anything about a Dave-specific subset of XML or HTTP... (like so many other parts of the specification, the "string" type isn't exactly well-specified. the specification first says that strings contains ASCII characters, and later that "any characters are allowed in a string" and that "a string can be used to encode binary data") > Yes, an incomplete XML parser could be faster if it ignores Unicode, > ignores character references, and does not do all of the error checking > required by the spec. I'm not sure if this would really improve > performance anyhow. well, sgmlop is a bit faster than expat (up to 50%, in some tests). expat does a bit more error checking. > xmlrpclib on the other hand, is entirely written in Python. Is there a > Python XML-RPC implementation that uses no Python code but does > use a true XML parser? the _xmlrpclib accelerator (see the xmlrpclib.py source) uses expat, with a really fast C layer. judging from Skip's benchmarks, expat is a bit slower than the py-xmlrpc parser (which is why I asked). </F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4