|
--Ken, your comments on "self-describability" are right on...Any suggestion of a name that describes the ability to retrieve the node names without recourse to external data, *and* is understood immediately by most, would be much welcome.--
Hi Robin. First, if it's all the same to you, my name is "Kendall". Thanks. I think "self-documenting" is pretty good, though that's still not great; maybe "self-naming"? Ick. I personally just let this entire line of "XML advantage" drop, since I don't think it's worth that much, no matter what you call it. I mean, surely, that's not *the* major XML benefit?
--How many mobile units shipping with support for such technologies as SVG, XHTML, or SOAP does it take to make you consider it large enough for consideration?--
I don't have a number in mind; but these small devices keep getting more and more powerful. They do all sorts of processing tasks which seem to me way more intensive than processing XML. And they will continue to get more and more powerful, or so it seems safe to conclude.
A binary variant of XML strikes me as a bad thing to have, all other things being equal.
--And what's that "Web per se" business? Is it only the Web if I'm browsing porn from a beefy desktop box? Do other devices not count?--
That's a rather tendentious way of making a point (what point are you making, actually?).
--Should each of those technologies be inventing its own solution?--
Yes, perhaps they should, actually. I mean, I keep being told by "people who know" that they need domain-specific compression schemes.
--Don't you think they've tried gzip?--
I don't know what they've tried. My point about gzip was that if we want one, general standard for compressing XML content -- given the profile of deployed XML in the world and other considerations -- gzip makes the most sense to me. One, general standard for compression obviously can't optimize for every domain specific data pattern.
--If they all go their own routes, how will I create content that works for multiple platforms? What are the chances that it'll be royalty-free? How does it deal with language updates?--
These are some of the concerns I have for *any* binary variant of XML, so I certainly share these concerns. My answer to all of them is "don't do that".
--And you don't mention things like dynamic update or random access, which solve important problems not addressed by gzip.--
Yes, the number of things I didn't mention in this column expands about as quickly as the universe itself -- doesn't that make you wonder, not about the quality (or lack thereof) of the column, but rather about the Pandora's Box which you're begging to have opened? At the very least, gimme a break! It's a 1000 word column, and I clearly couldn't have mentioned *everything*.
--Oh, and since you're the first one to ask for proofs,--
Bzzzt! Wrong. You can't be said to be doing science or research w/out empirical data to back up your claims. I'm so NOT the first person to come up with that idea.
--could you please point me to data that sustains the claims made by ERH that you repeat here? The fact that there is no technical advantage needs benchmarks to be sustained, just as does the opposite claim. "The only motive for pushing a binary variant is proprietary vendor lock-in"?--
I should supply proof of claims that ERH makes, because I repeat them? Is this the *first* XML-Deviant column you've ever read? Do you realize that what you're asking would make writing a column like XML-Deviant impossible?
And his claim about motivations is probably a different kind of claim, not one which is amenable to empirical warrant anyway, so let's not mix apples and oranges.
I'm less certain about vendor lock-in than ERH, but no less worried about it.
--Coming from a heavy Java advocate, I do find that statement somewhat ironic to be honest.--
Fair enough; why not take it up with him? If I had to defend every person's claim who I quote in an XMl-Deviant column, there wouldn't be any XML-Deviant column.
|
Previous Message
Up
