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, was: Re: SV: [xml-dev] XML=WAP? And DOA?

[ Lists Home | Date Index | Thread Index ]
  • To: "Jonathan Borden" <jborden@mediaone.net>,"Mike Champion" <mc@xegesis.org>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] XML is easy, was: Re: SV: [xml-dev] XML=WAP? And DOA?
  • From: "Derek Denny-Brown" <derekdb@microsoft.com>
  • Date: Fri, 18 Jan 2002 11:00:11 -0800
  • Thread-index: AcGf117OCBk8KKh9R/iI0Q8koLufKgAeEWMg
  • Thread-topic: [xml-dev] XML is easy, was: Re: SV: [xml-dev] XML=WAP? And DOA?

> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net]

> :-))) right, and hence your bias, but thanks for admiting it. My bias
> that we should get people using only what is needed, rather than the
> fanciest latest greatest and most complex way of solving the problem.

Ahh... but is .Net services implemented an XML subset, which did not
properly detect invalid xml characters, etc... Microsoft would get
lambasted for attempting to 'corrupt' XML.  Simplified/optimized
solutions are fine in a closed world environment, but suffer serious
long-term interop issues in an open (Internet) environment.

I am not trying to push the latest and greatest technology on people.
I'd love to let them roll-their-own solution, to avoid the inevitable
complaints about how much CPU time it takes to parse XML.  I just don't
feel safe doing that.  Part of the problem is the 'Microsoft is Evil'
paranoia that so many people have.  When so many people are out to prove
that your company is evil, every design choice which deviates (in any
way) from the standard, needs to be very carefully evaluated.  I
honestly believe that the only way to protect Microsoft, when it exposes
XML based services on the Internet, is to ensure that _all_ such
services are using fully conformant XML parsers.  This is despite the
fact that I have had people show me that they can improve
load/scalability/etc by using some custom parser which only handles some
subset of XML.  If XML were simple enough that I could honestly believe
that their solution was a proper subset of the standard, I might be
tempted, but XML just looks simple on the outside.  Break through to
worrying about the nitty-gritty details, and XML is an ugly beast.  Have
you every tried to implement the Name production efficiently, including
surrogate support?  How about CharData?  I have yet to see a single
custom parser which does these correctly.  In order to make sure that
people do the right thing, I just push all of them to use our
fully-conformant parser.  Yes it is more than they need, but I don't
have time to customize it just for them, nor do I have time to test
their parser and make sure that it isn't allowing non-well-formed XML in
some obscure case.  Believe me, if there is such a case, a customer will
find it, and develop and app which depends on it.

The simplification of Name and CharData productions in the initial draft
of XML 1.1 goes a _long_ way to better enabling customized solutions.
<rant>I just wish that the end-of-line rules made any sense, at least
from the perspective of a Win32 app (where EOL == \r\n).  Oh yea... and
if there was some way to not require buffering/scanning all of an
element's attributes, just to know which namespace it's prefix maps to,
then I'd be a really happy camper.</rant>


The views expressed above are my own and are not necessarily those of my


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

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