[
Lists Home |
Date Index |
Thread Index
]
From: Derek Denny-Brown [mailto:derekdb@microsoft.com]
>Given the amount of time I spend explaining 'simple' Namespace, XPath,
>XSD, DTD, etc.. issues to people, I would fall heavily on the 'not easy'
>side of the issue.
XML is easy. XML + the dozens of application languages that make up
an XML system are hard. If one does simple things with XML, one still
has to either learn those systems or build one. Starting with the
original mythical DePH writing a parser in a weekend, one could
say it wasn't too bad, but that isn't enough to do much, so yes,
it becomes hard very quickly regardless of the path one takes.
>The problem is not so much that things are
>complicated, but that things are not what is expected by a large
>percentage of people trying to _use_ it.
That's a fact. OOPMen see look for oopies, TableHeads for rows
and columns, CSVers for empty space and commas, and so on. One
almost has to be a docHerder to like a hierarchy and even then,
WinHelp poisoned the shepherds here. Only HTML has managed
to dent their heads and that only after it was made to look like
WinHelp (HTMLHelp). Really, all they needed was an easy way
to do full-text indexing because of WinHelp making everyone
use Find over a TOC.
>Part of my job ends up being to convince people that XML really is
>complex enough to mandate using existing tools, rather than
>rolling-your-own.
Flat pack or bulk? :-)
>XML is simple enough to fool people into thinking
>that they can get away with customized code, but in the open world of
>the internet, this is dangerous.
I am told that skydiving is easy; the ground is hard.
There are at least two dimensions here:
1. What is the cost of security and reliability, the general
notion of Quality Of Service?
2. What means can be used to contract for high QOS such that
the procured services will meet those requirements?
>A public webservice should only accept
>_well_formed_ XML, not just something which looks like XML, otherwise
>you end up with customers depending on the ability to accept
>non-well-formed XML.
That is one requirement. It creates a self-reinforcing therefore
sustaining and recurring cost.
>Convincing your average developer that standards
>conformance is like pulling teeth.
Too low a level. You are herding cats. The sensitive spot
in the system is the chain from RFP to Contract. This is where
systems are cited. The weakness in that chain as evidenced by
the RDDL and Negotiation threads is there is no credible source
that can be cited for reliable systems meeting criteria such
as you begin to describe (well-formed). That is why firms
such as Microsoft DO achieve lock-in and why I say that some
of the W3C and other XML leaders cannot fathom this, but in
fact, use tactics that make that lock-in inevitable. Unless
the RFP and contracts personnel can cite by formal identifier,
solid standards (not specifications for systems development),
fairly mindlessly, the result is that they cite vendor-specific
systems which they are certain meets these requirements. It is
an issue of who does what kind of work and what level of understanding
is needed to efficiently do that work. Proposal writers and
contracts specialists, as you say, aren't XML-Devers. (that
is why I have a job...).
Other than NIST, where does one go to get a list of Internet systems
or standards meeting requirements clear enough and proven
that stand up to the rigors of contract-based procurements?
The W3C? No. Those pages are mash of competing, let a
thousand flowers bloom but don't weed, dodgy documents.
ISO? That used to be the answer and if we are astute business
persons, it may be again sooner than later.
Microsoft? In combination with Oracle, Sun and IBM, that is
what we ARE doing. It works actually but is that the
way it is supposed to work, or inevitably, must?
It is the system integrators, the companies that sell to
the companies, not the general public, that make these
decisions because it is their job to do exactly that.
len
|
