On 03/08/2012, at 5:59 PM, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com>
wrote:
Specifically, it's very common for people to try to use schema to inform
"binding" tools into specific languages. However, the underlying metamodel of
XML, the Infoset, is both complex and a poor fit for most languages, so
bindings take "shortcuts" and expose a profile of XML's range of expression,
encouraging some patterns of use, while discouraging (or disallowing) others.
Since the bindings often make different decisions (based upon the language of
use), interoperability is difficult (sometimes, impossible).
It very much depends on what you're doing and how you're doing it. If what
you want is for your data to manifest directly as a data structure, XML is
a lousy fit for that for a bunch of different reasons. Json is the clear
choice
in such cases. But there are other uses where the more complex Infoset of
XML can be an asset.
Very much; when it becomes a "document" (e.g., mixed markup), XML is a much
better choice.
Really, it's all about how you use the available tools.
Furthermore, designing a schema that is extensible is incredibly convoluted
in XML Schema 1.0. Schema 1.1 was designed to address this failure, but it
hasn't been broadly adopted; most people I know in the field consider it a
failure.
Yes, XML Schema makes this a lot harder to do than it should be, but in a lot
of designs I've seen it also has to do with how XML is actually used. A bad
design is a bad design, regardless of what schema language you use.
What surprises me and many others is that people are still using it and
promoting it, when it's well-understood by almost EVERYONE who was involved
in
using XML for protocols in the past ten years agrees that it's a mistake.
See above. I certainly wouldn't use XML Schema for anything new, but there's
a lot of legacy stuff out there.
That's the rub, isn't it?
--
Mark Nottingham
http://www.mnot.net/