[
Lists Home |
Date Index |
Thread Index
]
The following is from my blog entry:
http://donxml.com/allthingstechie/archive/2004/10/13/1421.aspx
Microsoft has been taking in on the chin recently for the delays in
releasing Longhorn (including from yours truly), but I'd like to point
out another 800lb gorilla that should be taken to task for taking too
long to release a product, the W3C. Some people love to bash
Microsoft, and typically the same folks look the other way when the
W3C does something similar. In case you haven't heard, Dare announced
that XQuery will not be a part of the .Net 2.0 beta 2 release (and the
final release). The reason, the estimated time that the XQuery spec
will become a recommendation isn't until late 2005, which is after
.Net 2.0 will be released. Microsoft got burned badly when they
released code based on working drafts of XSL back in IE 5.0, and they
can't let that happen again. In case you don't remember, XSL looked
like it was ready to go, and very late in the game the W3C members
decided to rewrite the spec and split it into two (XSLT and XSL-FO).
I spent years on the VBXML XSLT discussion group trying to explain to
developers that there were 2 versions of XSL out there, and it was
very confusing for the majority of developers.
So, Microsoft has decided to be cautious and limit their exposure on
XQuery and have limited support within SQL Server 2005. I don't blame
them on this. The XQuery spec has been an official W3C Working Draft
since February 2001 and is still a Working Draft (over 3 years later).
It still has to go thru the complete process (Working Draft to
Candidate Recommendation to Proposed Recommendation and finally W3C
Recommendation). I don't think it would be beyond some of the
business on the committee to purposely slow down the recommendation
process in order to give their companies time to catch up to level of
support Microsoft has for XQuery. So which one do you think will be
released first Longhorn or the W3C's XQuery spec?
One of my major complaints with the W3C (and other standards
organizations) is that they just produce standards, not
implementations of the standards. I understand that software
companies have a vested interest in releasing products according to a
specification, but without having a publicly accessible implementation
of the spec to work with during the draft process it makes it very
difficult to create test cases. The writers of the spec have to
resort to thought exercises to test their ideas. My idea is to marry
a standards organization with an open source community (think of
merging the W3C and SourceForge), but put a hard division between the
two groups. In order to prevent intellectual property leakage from
the businesses on the standards org side to the open source side,
individuals from one side can not work on the other (for a given
spec). This way there is a living example for the standards group to
work the bugs out of (before it becomes a recommendation), and should
streamline the specification process. I know licensing can become a
hairy issue here, so that is why I keep the 2 sides divided. A
company on the standards committee does not risk exposing its IP to
the open source implementation, and the reverse should be true too.
To make this work, the open source project leaders would need to have
very good access to the working draft committee. In a perfect world,
there would be at least 2 open source implementations (.Net and Java),
and even the code based on rejected implementations would be available
for all (which is something some of the MS MVPs in XML have been
asking of MS for libraries that were abandoned).
Don Demsak
|
