OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: Microsoft's Role in the XML Community (WAS RE: Important: The SAXC+

[ Lists Home | Date Index | Thread Index ]
  • From: Wendell Piez <wapiez@mulberrytech.com>
  • To: XML Developers List <xml-dev@xml.org>
  • Date: Sat, 17 Jun 2000 14:31:11 +0100

One remembers that the MSIE5 implementation of the December 1998 draft of
XSL not only failed to implement the entire spec as of that time (no crime
in that, it was billed as a developers' release) ... but what was more
troublesome, it provided extra features without documenting that they
weren't XSL. This was *after* the XSL draft had outlined the use of
namespaces for extensions -- all MS's extensions were in the
http://www.w3.org/TR/WD-xsl namespace. It would have been so easy, and
arguably such good marketing, for them to have provided, for example,
<msxml:eval> instead of the putative <xsl:eval>.

(Actually even their current, closer-to-spec implementation offers such
features, notably an implicit casting of result-tree-fragment to node-set
that is explicitly against the recommendation. All others have put this
useful functionality into an extension namespace.)

But this is old news to many readers of this list, since the XSL community
has had to bear the burden of educating new users ever since: it's an
ongoing problem. The particular fine points involved are deep water for
most newbies, who only want to get XSL working quickly as advertised. It
ends up reflecting badly on the whole technology. "Er, 'namespace'?"

>From the outside it's impossible to know how or why things happen this way,
and I'm willing to give MS developers credit -- they are at least moving in
the right direction with XSL. Yet this case, like others, tends to justify
our wariness. "Eternal vigilance," etc. And while attitude says a lot, it
does seem we need to make a distinction between the constructive engagement
of engineers from MS, and the conduct of the company as a whole.

Nor would it be a good thing for Microsoft if Dave Megginson proves to be
wrong about their plans (or eventually, actions) with respect to SAX. He's
one wolf it couldn't be good for *anyone* to burn....

Wendell Piez (still a standards hawk)

At 10:21 AM 6/17/00 -0500, Len wrote:
>Ahh.. I understand now.  They broke the spirit of the
>agreement to provide full interoperability....
>And as with the Java cup, if they aren't fully 
>interoperable, it is Microsoft's responsibility 
>to show its customers precisely where, and obligating 
>them to that responsibility is part of the purchase 
>of the product.  An average shrink wrap buyer can't 
>do that, but large institutions can, do, and must. 
>Making language available to those institutions for 
>that purpose is something MIT can do for its community 
>of users.

Wendell Piez                            mailto:wapiez@mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS