OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XML is easy

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> From: Derek Denny-Brown [mailto:derekdb@microsoft.com]
> >Given the amount of time I spend explaining 'simple' Namespace,
> >XSD, DTD, etc.. issues to people, I would fall heavily on the 'not
> >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

XML is easy, so long as using XML means picking your XML tools/libraries
off the shelf and using them.  The problem I run into is that so many
people (here) have the NIH syndrome, and would rather write their own
XML library than use an existing one.

> >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...).

You come from the Mil/Gov Contract world, where everything is tightly
spec'd and conformance to spec is often more important than
performance/ship-date.  In the consumer product world, the norm is the
exact reverse.  When I switched worlds it was quite a shock to see how
common practice really is incredibly different.

Talking/Working with developers and their leads is the only level of
contact I have.  (Next time Bill Gates asks me over for lunch I'll talk
to him about it... <g>)  My angle is to work the grass-roots side of
things, since I can get a fellow developer to listen to my arguments
much more easily than I can his manager's manager.

Lock-in is inevitable, no matter what you do.  If you want to use the
latest technology, or squeeze the best performance out of an
application, you _need_ to use tailored integration.  In the real world
does not provide any other solution.  Look at databases.  Databases
standardized on SQL.  Does that mean I can move my payroll app from
Oracle to DB2 in a weekend?  Not even close.  The key to XML is not it's
ability to avoid lock-in.  It is it's ability to facilitate interop, and
loosely coupled systems.  Once these systems are all put together, you
still need tailored pieces to swap in and out of the puzzle, but you
_can_ swap them in an out. 



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS