Lists Home |
Date Index |
Jonathan Borden wrote:
> On the contrary, I'd say that only those folks who are concerned with
> binary goo are concerned with encodings. Folks that deal with text, i.e.
> XML, don't generally have to be concerned (to a significant extent) with
> encodings, which is the *big win* of XML.
Hmm? XML is just an encoding.
> Right, so you could care less whether a number is encoded either:
> 1) big endian floating point
> 2) little endian double
> 3) big endian 64 bit integer
> XML could really care less about these binary details. XML could just as
> easily deal with 203bit integers as 23 bit integers. These binary
> details just don't matter.
Ah! You're saying that there are several representations of a number in
binary but only one in text, right? Wrong. Some textual number parsers
will accept 2.3E5 as a number, some won't. There are different encodings
for numbers like infinity.
And consider how one encodes dates in XML. And how do you encode a
person's address book entry? With <person><name>... <email>...</person>
or with <addressBookEntry name="..." email="..." />?
It's wrong wrong wrong to say that in XML there is never any *choice* of
how you 'encode' some abstract information. XML mandates a single way of
encoding tree structure, but that's it. How you represent integers and
dates are constrained a bit by schema languages, sure, but so do binary
encodings like BER.
And don't forget than in XML you have to care how your characters are
encoded - big endian or little endian UTF-16? :-)
> Right, so just deal with text and be done with all these trivial
> concerns about byte order etc.
Sorry, the XML spec mandates that parsers be able to read UTF-16 encoded
XML, which means you *do* need to be concerned with trivial concerns
about byte order.
And if you want to use an off-the-shelf XML parser to prevent you from
having to worry about those details - then use an off-the-shelf BER
parser so you don't need to care about endianness in binary, either.
> The crux of the issue is whether you are more concerned with being:
> a) abstract "high level"
> b) bitwise efficient
> The only reason to be concerned with binary goo is if you have an
> overriding concern regarding "efficiency"
Well, no, most people develop binary formats because they're simpler
than XML, and they'd rather be getting on with writing their application
than bothering with DTDs and SAX and DOM and stuff, in my experience.
The only reason to be convered with XML goo is if you have an overriding
concern regarding 'being able to view and edit the files in a text editor'!
[you write apps in XSLT]
> What does this have to do
> with binary encodings etc? What does "encoding syntax" have to do with
> any of this?
Nothing - because XSLT is actually hiding the implementation of that XML
data from you; you just access the tree with it. The XSLT engine you use
could quite easily operate on a binary encoding syntax or something and
you wouldn't need to rewrite the XSLT. This is what Bob is saying is a
Good Thing. Don't you agree with him? :-)