Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Internal entities removed from 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. 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
