RE: [xml-dev] Why would MS want to make XML break on UNIX, Perl, Python, etc ?

["Michael Rys" <mrys@microsoft.com>]

From: Rick Jelliffe [mailto:ricko@allette.com.au]
> From: "Michael Rys" <mrys@microsoft.com>
> 
> > 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>