[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Internal entities removed from XML?


musicbrainz xml
> On Wed, 18 Dec 2002 16:33:11 -0800, Doug Ransom <Doug.Ransom@p...> 
> wrote:
> 
> >
> >
> >> From: Uche Ogbuji [mailto:uche.ogbuji@f...]
> >
> >
> >> 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. 

Frankly, I find this idea so cracked that I won't even bother spending much 
time beating it down.

I'll just make this one point before I close.  You say you think that external 
entities aren't worth supporting, so it's OK if Microsoft or any vendor does 
not support them in *XML* tools (not SOAP tools).

Some people think that mixed content is not worth supporting.  Is it OK for 
some vendors to then leave that out?

Some people think that Unicode is not worth supporting.  Is it OK for some 
vendors to leave that out?

Some people think that attributes are not worth supporting.   Is it OK for 
some vendors to leave them out?

Some people think that DTDs aren't worth supporting.

Some people thain that non-ASCII tag names aren't worth supporting.

Some people think that significant white space isn't worth supporting.

Is it OK for some vendors to leave these things out out?

And so when all the various vendors have indulged these preferences in their 
tools, and there is pretty much no chance that XML from one source can be used 
in another toolkit, will your ideal of standardization have been reached?

As for the particular issue at hand, is someone from Microsoft going to point 
out to us that this is a bug that is going to be mended, or an oversight that 
is to be remedied?  Or that the original poster is just plain wrong?  I think 
Microsoft is very badly discredited (at least in this forum) by Mike 
Champion's "defense" right now, and I do suggest they publically disavow such 
justification.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
A Python & XML Companion - http://www.xml.com/pub/a/2002/12/11/py-xml.html
XML class warfare - http://www.adtmag.com/article.asp?id=6965
MusicBrainz  metadata - http://www-106.ibm.com/developerworks/xml/library/x-think14.html



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.