June 2005 Archives

Daily joke

| No Comments | No TrackBacks |

This is from a very well known software company's site:

This site provides you with unique Technical Resources and Relationship Services available to XXXX! Check this page weekly for updates on a wide variety of XXXX-related issues!
Check a page weekly? I found myself treating it as a bad joke. It just sounds unnatural already to check a page on a regular basis to see if there is anything new. Alas syndication isn't everywhere yet...

Scott Hanselman:

I'm working (again) on the XML Chapter to our upcoming book. The book is all about ASP.NET 2.0, but XML is such an important part of ASP.NET that this chapter gets bigger and bigger. I've been updating it from the original Beta 1 version this last few months and noticed that the namespace qualification for the XmlDataSource is still broken/incomplete as it was last year in September. I talked to a bunch of people at TechEd including a number of very helpful devs and PMs who were very much interested in resolving this issue. However, unfortunately it looks like this'll be one of those features that won't make it into the final, which means one of us will have to write our own.
That's a bummer. I feel a smell of degradation here. When a brand new XML-specific ASP.NET control doesn't support XML namespaces, uses obsoleted XslTransform class and they can't get it fixed during a year - that's really lame. I'm really sorry seeing such stuff coming from Microsoft. Definitely we need to provide a fixed version.

Just look here.

AJAXSLT is an implementation of XSL-T in JavaScript, intended for use in fat web pages, which are nowadays referred to as AJAX applications. Because XSL-T uses XPath, it is also an implementation of XPath that can be used independently of XSL-T.
That's weird. Wait, all modern browsers (ok, except Opera) support XSLT natvely, don't they? Well, here is how they explain the goals:
Both XPath and XSL-T are built into some of the modern browsers, however not in all. This library runs on many browsers, including those that don't support XSLT adaequately or at all, which is why the library was written in the first place. (See BROWSER COMPATIBILITY, below.)
And more:
Safari/2.0 has XSL-T built in, but it is not exposed to JavaScript, but is only applied to XML documents that have a stylesheet declaration when they are loaded.

Internet Explorer exposes XSLT via the transformNode() method on the XML DOM. However, this is not avaiable if ActiveX is disabled.

Firefox exploses XSLT via the XSLTProcessor() object, however XPath is not exposed in the DOM.
Hmmmm, still weird. But still cool. Any efforts to bring XSLT client side are always cool. I'm glad to see Google supporting the idea.

15seconds.com published a series of articles by Alex Homer on reading and writing XML in .NET Version 2.0:

  1. Reading and Writing XML in .NET Version 2.0 - Part 1
  2. Reading and Writing XML in .NET Version 2.0 - Part 2
Excellent articles. Part 3 is expected too according to Alex's site. Yeah, I just found out Alex Homer has a site and even very interesting blog (with no RSS feed and not so frequently updated though). It's http://www.daveandal.net/alshed.asp. Alex, you really need RSS feed on your site!

It's official now - we (XML MVPs) agreed and Dare (as EXSLT.NET project owner) has approved an integration of the EXSLT.NET project into the Mvp.Xml library. All EXSLT.NET project contributors may ask to be added as developers to the Mvp.Xml project. I will be moving code soon, as well as doing some EXSLT.NET development. Current plans are: .NET 2.0 version and support for XSLT 2.0 stylesheet functions. Stay tuned.

Microsoft's XML Team is asking you:

XSLT 2.0 -
1. Do we need to support XSLT 2.0 ?
2. What are the most useful features of XSLT 2.0 that you would like to see implemented? (like grouping , support for datetime etc)
3. Do you believe support for the entire 2.0 spec is useful? If yes , why?
Don't miss a chance to speak up. Go post a comment.

Good news for those who missed the opportunity to retake a Microsoft Certificaion exam for free - the Second Shot Offer has been extended through August 2005.

Microsoft XML Team has posted a response "Comparing XML Performance" to the Sun XML Mark 1.0 benchmark and accompanying whitepaper from Sun XML Performance Team asserted that Java significantly outperforms .NET in XML processing performance.

kzu says he has broken the mark of 100 bugs filed to the MSDN Feedback Center. That's impressive. My numbers are humble - only 15 bugs and suggestions. Gotta be more active here. I spent a day working on an adapter to my homegrown XSLT test suite for the XslCompiledTransform class and the very first run brought a bunch of issues. Now I have to analyze the log and file bugs. I'm happy I found already a quite significant one - XslCompiledTransform thinks NaN equals to NaN. To put it another way - "number('foo')=number('bar')" evaluates to true! That's really bad, because that property of NaN (non equality to anything) is the base for a quite widespread technique in XSLT 1.0 on determining whether a value is a number - "number($val) = number($val)" is true if and only if $val is a number.

Future developer

| No Comments | 3 TrackBacks | ,

Future developer? No doubts!

So you like XML in Office?

| 1 Comment | No TrackBacks | ,

The big news today is of course announced next Office's full deep XML-ization. I've read a dozen of enthusiastic postings already and decided not to bother my readers with another whoohoo-like post from another XML nerd. But what amazed me more than the announce itself (which was predictable) is the overall excitement about the news. Ranging from Scoble to Tim Bray - everybody seems to value ultimate XMLization of the next Office as "big cool news". Not a single critical post - what's the matter with you people? And even more:

I think another version or two after the upcoming Office, binary files will become completely obsolete and forgotten and won't be able to round-trip the latest features.
says Wesner Moise (former Excel developer at Microsoft and overall smart guy).

Now that's amazing...

Another improvement System.Xml 2.0 brings, from the how-come-I-didn't-make-it--before department is that XPathNavigator class now implements IXPathNavigable. Sounds obvious, huh? In both common and OOP sense of course XPathNavigator should be IXPathNavigable, but somehow in .NET 1.0 and 1.1 it is not. (And by the way I still wonder how come XmlNodeReader doesn't implement IHasXmlNode interface. Too bad I made this suggestion too late and now we must wait another year or two for this). Anyway, these 2 lines of code:

public virtual XPathNavigator CreateNavigator()
      return this.Clone();
made a magic to the XslCompiledTransform API. 4 redundant Transform() overloads down! Now input to XSLT is either string (URL), XmlReader or IXPathNavigable.

And if you aren't familiar with IXPathNavigable - don't bother. Just remember that you can pass XmlDocument, XPathDocument, XmlDataDocument or XPathNavigator objects as is to the Transform() method as all these classes implement IXPathNavigable. API simplicity is invaluable and I'm glad version 2.0 of the System.Xml looks simpler than previous ones.