Lists Home |
Date Index |
On 8/25/05, Uche Ogbuji <Uche.Ogbuji@fourthought.com> wrote:
> In the end, as a long-certified XML doc head I think XML is just not
> suited to the bit jewelry of highly structured data. It's more suited
> to the sloppy exigencies of prose. I think all these rumblings are but
> the sign of the poor fit that first became unmistakable when the first
> WXS drafts were released, and I'll be amazed if there's any magic
> nostrum to be brewed for this by Microsoft or anyone else.
This is the only part of your response that I would even think about
quibbling with. (I *really* liked "In many ways I think a vicious
backlash from programming languages
against XML is just what XML needs right now.").
I don't disagree that XML is a bit of a stretch at best for pure data
applications, as the recent W3C workshop on XSD and the movement
toward creating a binary XML WG shows clearly. But as someone noted
earlier, XML is itself not as good as SGML for pure dochead
applications. XML is not really the best solution for anything, but
it's a good enough solution for a lot of stuff. Or maybe it really
is the best solution only in those ugly but common cases were
information must be human-readable and machine processable,
document-like but with lots of embedded structured data. At least I
don't see RELAX NG, JSON, etc. as strong alternatives for those in the
messy middle even though they definitely are reasonable alternatives
for pure dochead and pure data cases respectively.
I think the bottom line here is much the same as in a lot of the
permathreads: Don't use XML(or XSD, or SOAP, or whatever) because
you think it's what you're supposed to do, use it iff it does what you
need done more effectively than the alternatives do. For asynchronous
structured data with a tightly-coupled server side component, and
that's fine with me. What might worry me is if the JSON folks try to
promote it as a better XML than XML *overall*, but from the responses
I've seen that's not happening.