[
Lists Home |
Date Index |
Thread Index
]
On Wed, 18 Dec 2002 16:33:11 -0800, Doug Ransom <Doug.Ransom@pwrm.com>
wrote:
>
>
>> From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]
>
>
>> So what is the merest point of standards, if any party can just ignore a
>> standard as it pleases?
I don't claim any knowledge of the MS XMLReader thingie ... if it is
*violating* the standard (e.g. allowing nulls) I would not accept that. My
dim recollection from previous flamefests is that that was an acknowledged
bug. I thought we were discussing its default behavior that assumes that a
SOAP-like subset of XML is being used, and one must set some flags to have
it properly parse the full set of XML 1.0 constructs.
I'm making the point I've been making for about 3 years now -- "Common XML
core" aka "the subset of XML supported by SOAP" is a more reliable
foundation for comprehensibility and interoperability than the whole spec.
The Web services people learned that on their own (the sml-dev and xml-
protocols people had a bit of a meeting of the minds at the X-Tech 2000
show, as I recall). Obviously that is not even remotely close to best
practice, or even a useful starting point, in heavy-duty document-oriented
XML ... but that is a relatively small percentage of the actual XML out
there. The Borg may be evil, but they listen to their developer
customers, and this is clearly the kind of thing that an ordinary mortal,
non-XML geek would want the default behavior to be with the kind of XML
that they are being asked to work with.
> This is really interesting -- you can write standard-compliant code with
> .net if you really go out of your way, so MS hasn't really busted any
> standards --
Yeah, I pretty much agree. So break my sword, tear off my buttons, and drum
me out of the XML corps :-)
> I think the best thing is to change the XML spec to match the default
> .net behavior -- add a version number to XML if we need to. It will be
> easier in the long run.
Again, I have been arguing for a very long time (well, in Internet years
anyway) that XML needs some sort of mechanism to allow producers of XML
"documents" to specify that something less than the full XML syntax is in
use. Rick Jelliffe pointed me to SGML Annex K a couple of years ago, and
that is one way to do it. I remember that Sean McGrath had a good proposal
for how XML might be extended to specify something like this (the details
escape me at the moment). The TAG and the XML Core WG are (reluctantly)
thinking about the whole issue of subsets/profiles because the idea just
won't go away.
.NET's default behavior does something like this with APIs rather than
data. Unless I'm not aware of some evil non-compliance beyond what has come
up in this thread, I just see this as simply a pragmatic accomodation to
the reality that real-world developers face when confronted with XML's
complexity and sheer gnarliness. It may also -- I have NO idea about this -
- trigger some optimization code. I hear repeatedly (again, see the TAG
thread on SOAP and the internal subset) that if you know you won't have to
expand entities (beyond the built-in ones, which "expand" into fewer
characters than their serialization) then you can dramatically simplify
buffer management.
>> Also, I'm sure it is no coincidence
> > that .NET's XML tools appear to be focused on the subset of XML that
> SOAP > employs.
> These are not "SOAP parsers" but "XML parsers". That should end this
> paltry justification.
Whatever ... it's not ME you have to convince ... it's all those millions
of VisualBasic programmers out there and the people that make tools for
them. For some odd reason, MS seems to be catering to their opinions
rather than those of the hardcore XML developers. I guess my bottom line
here is that I wish the keepers of XML had listened to the whining of the
sml-dev'ers a couple of years ago and provided a standards-based solution
to a real problem, rather than leaving vendors such a strong incentive to
address the problem in a proprietary way.
|
