April 2003 Archives

Web Services rock! As I found out BizTalk Server is actually dead and is going to be transformed to Jupiter suite this year. Not surprisingly, Jupiter is Web Services-based product. It will use Business Process Execution Language for Web Services and integrated with Office and Visual Studio.NET.

Chances are I'll be involved in a project, which uses first Jupiter beta soon, so I'm happy I shouldn't learn all that boring BizTalk stuff, but BPEL4WS instead.

Finally. Gudge has posted his C# implementation of XInclude CR. It's XmlReader-based, with XPointer support, fairly elegant, simple and very interesting. Especially to compare with GotDotNet XInlcude.NET impl.

After a quick look I can say of course it's much more elegant than my implementation. More structured and well-designed, while probably less caring about details. Unfortunately to me it seems like Gudge has omitted xml:base attribute generation problem, I was hoping he'll solve in a usual magic way. That's the only problem left in XInlcude.NET project before we can ship first alpha version.

What's the problem? When an element is included from another document with different base URI, the xml:base attribute should be added/substituted to this element to preserve its (and its descendants) base URI. Sounds simple. When top-level included element item is read through XIcludingReader, xml:base attribute should be exposed if it doesn't exist else its value should be modified. It requires probably some state fiddling in MoveToNextAttribute() and other attributes-related methods. My first idea is to check when MoveToNextAttribute() returns false and then switch the reader to some new EXPOSING_XML_BASE state to emulate xml:base attribute. Anyway I'll try to implement it tomorrow.

Well, it seems like XInclude 1.0 is going to get final W3C Recommendation status very soon. According to recent Jonathan Marsh's reply in www-xml-xinclude-comments@w3.org mail list on small typo in the Candidate Recommendation:

Thanks, we'll track that as an erratum if it's too late to change prior to achieving Recommendation status.

According to GotDotNet download statistics my MultiXmlTextWriter class has been downloaded 398 times, while last version of nxslt utility, which includes it to support multioutput XSLT - only 91. Hmm, looks like people prefer a component to build own solutions rather than old-fashioned versatile command line tool (not really prominent observation, huh?).

My article about getting multple outputs in XSLT under .NET I was talking about probably will be published in June. That's my first authoring experience. Day-to-daily I write code documentation and specifications , but never an article, so I'm kinda worrying about it.

It's Passover holiday week in Israel now so I have the whole week free to be devoted to interesting things (well, almost free, I have also to study BizTalk until the end of the month) . So let's get back to Xinclude.NET project.

<?foreteller-mode on?>
This is new Apache FOP logo:

<?foreteller-mode off?>
Will see if I can predict anything, voting is still on ;)

Ivelin Ivanov has published first installment of a new regular column on XML.com, "Practical XQuery" - XML.com: Processing RSS [Apr. 09, 2003].

The article's example looks quite provocative - generating of HTML from two XML sources (RSS feeds). I bet the first thought of many devs would be "Come on, that's XSLT's job for ages!". Indeed, even 3-years old XSLT 1.0 can easily perform such transformation at a very newbie level, so it's fairly enough to ask - "Why do we need one more language?".

Actually, this example just illustrates XML Query Requirements', first Usage Scenario:

Perform queries on structured documents and collections of documents, such as technical manuals, to retrieve individual documents, to generate tables of contents, to search for information in structures found within a document, or to generate new documents as the result of a query.

So this is really a gray area, where XSLT and XQuery do overlap. The task of generating new document based on a source document may be thought either as source2result transformation or as building new document basing on a source querying. And I don't see what's wrong with that, both languages (XSLT2.0 and XQuery1.0 to be technically correct) may greatly complement each other. Many people don't like XSLT just because its XML-based syntax, many others don't take its rule-based nature and of course there is an horde hunger to return to their habitual procedural programming style. Many of them should be happy with XQuery. Not bad?

Keeping provocative line I would ask - isn't XQuery strongly typed subset of XSLT2?

Kirk Allen Evans has posted a recursive XSLT template to transform CSV into XML. Being low-level substring functions based it's obviously quite verbose and convolute, what was fairly enough pointed out by Dare. He has provided 10-lines C# version also.

What I wanted to add to this subject is that such example perfectly illustrates how radically EXSLT extensions may improve XSLT 1.0 coding. (btw, Dare is working on the implementation of EXSLT functions for .NET and I believe it would be great addition to .NET XSLT programming practice). Look yourself: here is EXSLT version, which makes use of str:tokenize extension function (note, even smaller than Dare's C# one):

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
xmlns:str="http://exslt.org/strings" exclude-result-prefixes="str">
    <xsl:include href="d:/xsl/str.tokenize.msxsl.xsl"/>
    <xsl:template match="root">
        <root>
            <xsl:for-each select="str:tokenize(.,'&#xA;')">
                <row>
                    <xsl:for-each select="str:tokenize(.,',')">
                        <elem><xsl:value-of select="."/></elem>
                    </xsl:for-each>
                </row>
            </xsl:for-each>
        </root>
    </xsl:template>
</xsl:stylesheet>

So, XSLT perfectly able to handle this, it just needs tokenizing facility, like C# has and what for producing XML - IMO XSLT is the best hammer on the market. I agree though that for pure CSV2XML conversion XSLT may be not a right tool, if it was my project, I'd make use of SAX filter or something like Chris Lovett's XmlCsvReader.

Oracle XDK v10 Beta Release supports XSLT 2.0, XPath 2.0 and XPath 2.0 Data Model (all working drafts dated 11th November 2002). It's not clear to which extent all that jazz is supported, but anyway, that's good news.

And AFAIK Apache guys at Xalan team are working on Xalan 3.0, so more to come.

I'm moving to a new house these days, so practical life's questions totally occupy me, I just have no time to blog unfortunately. Hope I'll pop back in a week or so. Main question bothering me is how to get DSL before Passover holiday week in Israel has started, two days countdown.

Don Box's Spoutlet:

In the interest of generality, Simon asks if there is an XmlReader implementation that traverses an XPathNavigator.

I'll elaborate it further on XInclude.NET Message Board.

Kirk Allen Evans's asking hard questions:

Should there be an XIncludeNodeList implementation that is the product of the merged Infosets? Or is this irrelevant since it would only apply to a fully-loaded DOM instance, which should already have been loaded?

Should loading an XIncludeDocument be in any part asynchronous?

Should the first version of XIncludeReader support XPointer? If so, to what degree? Should we only support the XPointer elements() scheme?

I guess this all boils down to answering "How complete should revision 1 be?"

What a mail I got today from Taiwan, really nice one:

"Mozilla thinks this message is junk mail". Well, probably ;)

Rambling in the blog space, found Alexis Smirnov's blog and there a link to quite interesting article named "Xslt Transformations and Xslt Intellesense within the .NET IDE" by Doug Doedens. It's about how to make XSLT authoring easier and more convenient in Visual Studio.NET.

That sounds similar to what I've been thinking about last few days - to implement for VS.NET all that XSLT-related authoring features I used to in XML Spy. Apart from adding XSLT schema to allow IntelleSense drop down hints, which is trivial as described in this article, I plan (but when?) to build VS.NET addin to allow one-click/one-key transformations with support for xml-stylesheet processing instruction. I've got some prototype already, hope it'll grow to something useful.