[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Why would MS want to make XML break on UNIX, Perl, Python
From: Rick Jelliffe [mailto:ricko@a...] > From: "Michael Rys" <mrys@m...> > > > They would all mean nothing in the context of the markup (ie they are > > exposed as a character information item with their Unicode code point) > > and display is left to the output device. > > Sure, lets make XML unsuitable for use in UNIX pipes by allowing ^D. > And for Perl and Python text-processing programs that use standard in and > expect EOF (^D or ^Z). I was a Unix hack for at least 11 years of my life (before joining the evil empire and after leaving the mainframe and early PCs and Macs :-)), and I can assure you that unix pipes do not care about control characters. > That really is pathetic. I sat next to the excellent J. Paoli at lunch at > a conference last week, to thank him for the terrific MS help with some > MSXML 4 issues, and he stressed that MS was keen on following standards > for XML: they were competing at the higher levels. I was at the same conference and I know Jean very well and we agree on how MS should handle XML standards. I don't want to know what kind of innuendo you want to imply on my motives with your reply (I thanks Dare for his mail, although I am not feeling as attacked as he interpreted the mail). But supporting the standard also means that we need to work on evolving the standard if we see issues that are not currently addressed in some of the main scenarios of current XML usage. > But it is clear that the other agenda is at work too, at least in certain > people at MS: let us adjust XML regardless that it wil break on the > opposition's operating system or tools. Let us justify this by saying > that there are (supposedly) more people using DBMS than using standard > input for processing. Let us embrace and extend. Now your wording is getting more insulting. My presence on this list is purely out of my own will and interest as is the participation in this discussion. I contribute if I think I have something valuable to say. If you do not want to listen, fine. Starting to slander however will just make me put you into my kill file which would be a pity since you also can bring actual arguments and make good contributions. Embrace and extend would be to simply generate and consume arbitrary code points in XML 1.0 without proper warnings and errors. Or use things like PI encodings that only our tools know how to handle. Granted, some of our earlier tools do this (the parsers however got corrected), but since we (and others) still have the original needs, having XML 1.1 solve it in an interoperable will be beneficial to more than just Microsoft. > I have been rather surprised at people's comments that "text" is somehow > an abstract idea which we are free to fiddle with, rather than being a > mode hardcoded into operating systems in which certain control characters > are used for certain control functions (e.g. EOF in particular) and is > utterly distinct in practical and operation terms from binary processing. > XML is text. XML is based on Unicode code points. XML 1.0 is based on the "textual" subset due to its SGML legacy and authoring focus. Over the last three years, the usage of XML has evolved into areas where some people claim it is not as well suited. I honor that opinion, although I disagree. By evolving from 1.0 to 1.1, we will be adopting XML for these areas in an interoperable way. If you do not want to write or parse 1.1, stick with 1.0. Also note that some systems such as programming languages and databases that make the distinction between text and binary are much more lenient than XML 1.0 in the text scope. So being able to provide a type based serialization without data loss is an important aspect in supporting some of these areas. Yes, there are some technical problems with C based APIs such as libxml. Maybe libxml needs to evolve as well (to libxml2?) for 1.1 applications and libxml for 1.0 will not be able to support some 1.1 documents and raise an error if NULL comes through. Or we find an interoperable way to transport/encode the control characters (agree on entities or char references or PIs). However, sticking the head in the sand and ruling the problems out of bound because they did not fit the original profile will quickly lead to one of the following: - XML will become as obscure as SGML itself was and ASN.1 takes over (yeah, right...) - XML will fracture and the fracture lines will not be along an interoperable line but IBM will support NEL anyway, database vendors will map their textual types into XML text without having an interoperable way (or it will be confined to their industry group such as the ISO SQL standard) etc.. Is that what you want? I hope not... Regards Michael On XML-Dev I speak for myself but try to use my influence in my product area to do what I think will bring us all forward. > Cheers > Rick Jelliffe > (Not speaking on behalf of employer) > > > > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl>
|
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
|