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] Internal entities removed from XML?

[ Lists Home | Date Index | Thread Index ]

On Wed, 18 Dec 2002 16:33:11 -0800, Doug Ransom <Doug.Ransom@pwrm.com> 

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


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

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