Internal entities removed from XML?

["Doug Ransom" <Doug.Ransom@pwrm.com>]

With the Microsoft .net (dotnet) platform, it seems one really has to go out of ones way to develop code which can read an XML file with entity references, even internal entity references.  I ran into this when I tried some XSLT programs that worked successfully with saxon (java based xslt processor) and msxsl (COM based xslt processor) with a .net based XSLT processor.  

The default mechanismsms (XMLReader and XMLDocument) to load and read XML documents or XSLT programs simply fail when presented with a valid XSLT program which is serialized in valid XML.  

I wonder if a whole bunch of existing XML files that work fine with existing applications are going to break new applications designed to work with the same XML documents (i.e. a .net XSLT processor to replace msxsl).  I suspect there are a fair number of valid XML documents out there that simply won't parse under .net.

I think Microsoft has essentially removed entity references from XML, because now document authors won't dare produce XML documents that the majority of programs built on the .net platform will barf on.  Users will be pretty upset at an author if they receive an XML document from them which won't load with their .net program.  

The WS-Interoperability profile also suggests entities not be used in SOAP messages.  It seems like there are two versions of XML now;  one that works with .net and WS-I, and an  XML 1.0 document with a DOCTYPE section that cannot be parsed by what will replace the most commonly used XML Platform (as .net replaces COM on windows).

Any comments? Maybe removing entity references is a good thing (I know implementators of embedded system platforms think so), and mabe Microsoft is doing the right thing by making entity expansion a thing developers have to go out of their way to make their software  perform.


Doug Ransom