December 2004 Archives

Btw, talking with .NET developers recently (XML geeks and non-geeks) about XQuery and XSLT support in .NET 2.0 I realized that shocking fact - about 80% of devs I was talking to still have no idea XQuery support in .NET 2.0 was cut. They were listening all the road to XQuery hype, they had that idea about how XQuery is better than XSLT in mind, they are working with XQuery implementation in .NET 2.0 Beta1, they are reading "What's New in System.Xml for Visual Studio 2005 and the .NET Framework 2.0 Release" and "XQuery and SQL Server XML Support in the .NET Framework" documentation at MSDN. Oh, apparently they don't read blogs!

Here is a nice one from today's xsl-list:

I'm working with the 2.0 beta of .NET and it has XQuery 1.0 support - you are saying that it will not be supported? That sounds rather strange to me - please explain.
Pieter Reint Siegers Kort

So we better be prepared for a wave of disappointed developers once Beta 2 is out. Blogging on that isn't enough, some official MSDN article is needed. People should be warned ASAP not to waste their time/money on that.

Another good news - Dave Remy, a Lead Program Manager on Core XML Technologies at Microsoft is blogging. Subscribed.

Hey, what a surprise from the W3C! XInclude 1.0 has been published as W3C Recommendation today. That was fast! Less than 3 months in Proposed Rec status - and here it is, XInclude 1.0 - another standard XML Core technology.

As usually very long post (an article actually) by Kurt Cagle on "The Business Case for XSLT 2.0". Explains why XSLT 2.0 is good and why Microsoft should implement it. With Michael Champion's comments, worth reading.

Hey, I've got another idea. XQuery and XSLT2 are surely huge undertakings (we can truly thank W3C for that), but still there is plenty of plain poor .NET devs struggling with limitations of XSLT 1.0 and XPath 1.0. What if Microsoft implements XSLT 1.1 + EXSLT in .NET 2.0, would you like to see it?

Some XML news in no any order:

• Irwin Dolobowsky says we should expect very interesting articles at MSDN XML Dev Center, especially I'm looking forward to this one - "Helena Kupkova will show us how to create bookmarks in XML Streams with the ResetableXmlReader." Hmmm, sweet. AFAIR we've been discussing it with my fellows XML MVPs, but concluded we need to rewrite XmlTextReader substantially to achieve it.
• Microsoft XML Team has a team blog now - subscribe here.
• Mike Champion nicely wraps up a discussion on the recent changes in thinking on the the next generation of Microsoft XML-related products. Convincing enough. What I still dislike is the lack of a consistency. A subset of XQuery (which is considered as stable enough) is still going to be supported in SQL Server 2005, but not in .NET. Weird, but you know, admit it - SQL Server team just can afford it.

Oh that big news - Michael Champion is now Program Manager for XML Standards in the Microsoft's XML WebData team. Wow, wow, wow - that's the only words I can say. Here is his intro on his new blog (hey, he is a Microsoft employee, so it's http://blogs.msdn.com/mikechampion, not http://weblogs.asp.net/mikechampion, but actually both URLs work). Subscribed.

The focus of my job at MS (as I understand it -- I'm still new!) is to help the WebData team track XML technologies and specifications as they emerge, mature, and are standardized, and to be a source for information needed to decide which specs to support in what timeframes.

W3C at last published the "Architecture of the World Wide Web, Volume One" as W3C Recommendation. It was cooked in long hot discussions by Web heavyweights and geeks. Here is what's that about:

This document describes the properties we desire of the Web and the design choices that have been made to achieve them. It promotes the reuse of existing standards when suitable, and gives guidance on how to innovate in a manner consistent with Web architecture.

I wonder if is there is something inherently wrong with XslTransform's class API? I was stunned again today reading this post in microsoft.public.dotnet.xml newsgroup:

I still don't see any way to create a XslTransform from a XmlDocument?

I'd like to ask - do YOU think XslTransform class provide intuitive enough API (I mean these 5 overloads of Load() and 9 Transform() methods, not including obsolete ones)?

Kenny Kerr has posted another instalment in his amazing "Introduction to MSIL" blog series. It's about brilliant for-each construct, which was introduced by Visual Basic and now adopted by VB.NET, C#, C++ and even Java. Worth reading.

Besides I very like that idea of learning from blogs - you know, you just skim feeds, read what caught your attention - and learn new things. Oh, and what are these new things you learn - that depends on your interests of course!

That guy Loren Halvorson has relased XmlPreprocess tool for preprocessing XML files, e.g. config files in .NET. It allows to perform the following tricks:

<configuration> 
  <system.web>
    <!-- ifdef ${production} --> 
    <!-- <compilation defaultLanguage="c#" debug="false"/> --> 
    <!-- else --> 
    <compilation defaultLanguage="c#" debug="true"/> 
    <!-- endif --> 
  </system.web>
</configuration>

Now back to our mundane world. Unfortunately in .NET one cannot embed elements in a proprietary namespace or even plain XML processing instructions into standard sections of config files! So using such poor hacks as embedding data into comments is the only workaround. Too bad. That's just another example of how violating a basic principle called "Allow All XML Syntax" makes your customers to invent poor hacks when they only want to extend your product.

I was doing some catch up reading feeds I'm subscribed and I found this one item that made me feeling some sort of bitter nostalgia. It's right on MSDN TV site, a new episode where Mark Fussel explains new XML features in upcoming .NET 2.0. The episode is dated December 02, but apparently it was filmed long time before. Why? Because more than a half new features Mark is talking about are officially cut and Mark himself has left XML team already.

Some goodies from Daniela Florescu and the Database Group at the University of Heidelberg:

• "The BEA Streaming XQuery Processor" (full version?), D. Florescu, C. Hillery, D. Kossmann, P. Lucas, F. Riccardi, T. Westmann, M.J. Carey, A. Sundararajan. VLDB Journal.
• "Implementing Memoization in a Streaming XQuery Processor", Y. Diao, D. Florescu, D. Kossmann, M.J. Carey, M.J. Franklin. Proceedings of the XML Symposium, Toronto, August 2004.

This is amazing. Adam Kinney (Xamlon guy) runs his new blogsite on XSLT 2.0 (using Saxon.NET as XSLT engine):

Adam Kinney.com has been redesigned, restructured and refactored. The new site has been inspired by my hate fo comment spam, interest in XSLT 2.0, desire to lose SQL and move to XML, wanting to build more than just a blog (i.e. articles, art galleries, events) and my continually desire to build all my own tools over and over again.

[Via <XSLT:Blog/>]

Here is a really nice wrap up by Mike Kay on what benefits XSLT gets from using XML syntax:

I think the benefits are:

(a) many stylesheets consist of two-thirds data to be copied into the result tree, and one-third instructions to extract data from the source document. An XML-based syntax is beneficial for the two thirds that is data, because it means the code in the stylesheet is a template for the final result. This also facilitates a development approach that starts with graphical designers producing a mock-up of the target HTML or XSL-FO page, and then handing it over to a programmer to add the control logic. (XQuery has recognized this by using an XML-like syntax for element constructors, but there's a lot of difference between being XML-like and being XML.)

(b) XSLT inherits all the lexical apparatus of XML: entities, character references, Unicode encoding, normalization of line endings and whitespace, namespaces, base URI, and whatever the core WG dream up next. That means there's only one set of rules for users to learn; it means there's a lot less detail for the WG to reinvent and possibly get wrong; it means users can take advantage of XML editing tools; and it gives implementors a head start.

(c) It's surprisingly common, especially in large applications, to see stylesheets being used as the input and/or output of a transformation. My favourite example is an online banking system that had 400 screens each generated by its own stylesheet, but all 400 stylesheets used a common look-and-feel which was achieved by generating them from a master database containing rules for all the different kinds of content that could be encountered. It's not obvious how one would do that in XQuery: one could go some way with a function library, but not nearly as far (especially without polymorphic functions). (And since queries aren't XML, I can't even search for all the queries that invoke a particular function, without a meta query language!)

(d) One of the original arguments was that for client-side applications, especially in small-footprint devices, only one parser would be needed rather than two. However, I've no idea whether this argument stands the test of time.

(e) XML vocabularies can be nested. We had no difficulty recently adding the capability to have an inline schema within a stylesheet for describing its working data, because XSLT and XML Schema are both defined in XML. Similarly stylesheets can be embedded in other XML documents, for example in the source document to which they apply, or in a pipeline processing language.

(f) One unpredicted benefit, I think, is that the XSLT syntax ends up being more systematic, extensible, and robust. It's much easier to add another attribute to an XSLT instruction than to extend the XQuery grammar, and it's much easier for a compiler to catch all the syntax errors in one run.

Historically, a lot of the motivation for XSLT being in XML was the experience of DSSSL, where the unfamiliar LISP-like syntax was widely regarded in retrospect as the reason for the lack of take-up. It was intended that XSLT should be writable by non-programmers, and I believe that often happens. In fact I have heard it said that non-programmers have far fewer conceptual problems with the language than JavaScript or SQL programmers do.

Cool new image from the NASA Earth Observatory - satellite view of the Jerualem city and area.

m.david starts his new project on Monday - sort of community XSLT learning using wonderful "Beginning XSLT" book by Jeni Tennison

Anyone and everyone is welcome to join in this effort to become better XSLT programmers. While I intend to do all I can to keep things moving forward throughout the course of this "adventure" there is no set schedule. I plan to submit two to three posts a day to act as food and fodder but by no means will these be the required focus. By utilizing the blog format it allows those who are not ready to move on the ability to stay where they're at, asking questions via comments and relying on answers from the community to help in better understanding that particular area of XSLT. This format also allows those who are ready to move ahead the ability to do so without feeling the need to wait for others to catch up. In many ways this will allow a relaxed, self-paced environment for you to jump in at any point and begin to better your XSLT programming skills. This also allows for those only interested to better their skills in certain aspects of the language the ability to jump in and out as they please. In the end we will hopefully have created a nice reference for others to come along and utilize as well as ourselves to reference as needs be.

It's worth to mention also that SyncRO Soft Ltd, the maker of the <oXygen/> XML Editor offers 15% discount on their products for UnderstandingXSLT community members. More details here.

I arrived at work and found 200+ new posts in xml-dev list. Lovely. XML is still extra hot topic. Here are some nice quotes:

For my money, XQuery is a heroic effort by a bunch of incredibly smart people which is crippled - we don't know how seriously - by its insistence on cohabiting with XSD.

XSLT has an <xsl:copy> construct that does a shallow copy of an element node together with all its namespaces (yes, you're right, I wouldn't expect anyone to guess its specification by looking at the element name, any more than I would expect anyone to guess what a left outer join operator does). XQuery has no equivalent. My XQuery example used a computed element constructor, which is the equivalent of <xsl:element> in XSLT: this isn't copying any namespaces from the source document.

As another parallel thread notes, namespaces are responsible for a ridiculous amount of the complexity in both these languages and the people who invented them should be .... Any suggestions for a suitable punishment?

As another non-obvious outcome of the recent browser war wave and the raise of Firefox browser is growing appreciation of XSLT as a useful client-side Web technology. That "An Introduction to Client-Side XSLT: It's Not Just for Server Geeks Anymore" article at digital-web.com is making me believe XSLT is finally coming to the client-side.

Another good news is that Mac's Safari browser is going to support XSLT via libxslt in the next release. Kudos!

C# Chat: The C# IDE
Have some questions about expansions, intellisense, or type colorization? Have some suggestions for or comments about refactoring support? Join the C# IDE team to discuss the past, present and future of the C# IDE.

They say Microsoft is about to unveil MSN Spaces blogging service, may be even this week:

Microsoft's MSN division is expected to take the wraps off its MSN Spaces blogging service this week, according to sources close to the company.
MSN is expected to tout MSN Spaces as a direct competitor to blog-creation and hosting tools, such as Blogger, Blog*Spot, LiveJournal and TypePad. Microsoft also will position MSN Spaces as a way to allow users to more easily share photo albums and music lists, too, insiders said.

Sounds like all other MSN services like Hotmail and MyMSN are going to support RSS and blogging as well. At least that's how I get Dare's hints. I believe there will be no support for Atom as Microsoft traditionally uses RSS for its feeds.

Wow, I've heard about some hardware XML routers, but today I saw an ad banner about hardware XSLT accelerator. Holy cow! Here is some marketing blah-bkah-blah:

Standards based XSLT processing is computationally intensive - it overburdens the server infrastructure resulting in poor user experience, high server infrastructure costs and scalability limitations. By delivering order of magnitude or better acceleration for XSLT processing - the XML Speedway significantly reduces the infrastructure costs, improves scalability and availability of the total solution. The XML Speedway provides this world-class performance through Sarvega's acclaimed highly optimized XESOS™ technology. Further, through XML Compression, end-to-end response time is improved regardless of location or network connection.

XML Speedway can be deployed in a reverse-proxy in-line and server-assist modes with JaxP and C++ API. Flexibility extends to the variety of means available to de-reference XSL stylesheets, enable pipelined transformations, provides built-in support for various XSLT engines, XSLT and XML Schema caching and the ability to concurrently offload disparate backend applications with their own sets of transformations.

Wire Speed XSLT Processing:
• XSLT transformation, XML Schema validation, XML/SOAP Routing
• XSLT 1.0, XML Schema 1.0, XPath 1.0, SOAP 1.1, SOAP 1.2
• Compression, XSLT/XML/Schema caching, MIME support, URL rewriting
• Support for non-XML content

Not bad. They say FOXSports.com is already using it. I wonder where is the price list.

PS. Hey, that's Sarvega company - once they wanted to hire me, now I see why :)