August 2004 Archives
Like most of us, Dijkstra always believed it a scientist's duty to maintain a lively correspondence with his scientific colleagues. To a greater extent than most of us, he put that conviction into practice. For over four decades, he mailed copies of his consecutively numbered technical notes, trip reports, insightful observations, and pungent commentaries, known collectively as "EWDs", to several dozen recipients in academia and industry. Thanks to the ubiquity of the photocopier and the wide interest in Dijkstra's writings, the informal circulation of many of the EWDs eventually reached into the thousands.
Although most of Dijkstra's publications began life as EWD manuscripts, the great majority of his manuscripts remain unpublished. They have been inaccessible to many potential readers, and those who have received copies have been unable to cite them in their own work. To alleviate both of these problems, the department has collected over a thousand of the manuscripts in this permanent web site, in the form of PDF bitmap documents (to read them, you'll need a copy of Acrobat Reader). We hope you will find it convenient, useful, inspiring, and enjoyable.
The manuscripts of Edsger W. Dijkstra. Really fascinating collection.
[Found in Michael Brundage's XQuery book].
By the way, Chapter 3 "Navigation" of the "XQuery: The XML query language" book by Michael Brundage is available online on Michael's site (PDF version). Take a look at http://www.qbrundage.com/xquery/toc.html.
Kurt Cagle is blogging. Unfortunately it's Atom only blog (via Google's Blogger) and my RSS Bandit 1.2.0.114 (SP1 RC1) doesn't seem to understand it. Grrrrrr, how does thay say it - "Don't be evil" and "Google's mission: Organize the world's information and make it universally accessible and useful."? Rubbish! When it comes to blogging, Google Is Evil.
[Via DonXML]
I had a foreboding of it. Dare Obasanjo:
For this reason we've reverted the XPathDocument to what it was in v1.1 while new functionality and perf improvements will be made to the XmlDocument. Similarly we will keep the new and improved XPathEditableNavigator XPathNavigator class which will be the API for programming against XML data sources where one wants to abstract away what the underlying store actually is.
That's a sharp turn! Strikeovered XPathEditableNavigator apparently means XPathDocument won't be editable and that's a main loss. Read-only XPathDocument has no chances to be any alternative to XmlDocument despite it's more effective, faster, more lightweight, XQuery-friendly etc.
They say developers love DOM. Hmmm, Java developers definitely don't, just look at numerous Java-and-developer-friendly DOM alternatives like JDOM, Dom4J, XOM etc. I remember my experience of processing XML using DOM in Java as a nightmare, I never had to write so dirty java code before and after that. Microsoft part of XML world is different - brilliant MSXML implementation is the only tree-based XML API for native Windows programming and ... it's brilliant. You see - the only and brilliant, that's a killer combination and that won't be so bad to have such one in .NET. Btw many don't realize MSXML actually extended DOM to make it at least usable, e.g. with "xml" property (InnerXml/OuterXml in XmlDocument) etc properties, which aren't actually W3C DOM). So the truth is developers love MSXML, not DOM. And they obviously love XmlDocument, because it's habitual and because it's is easier to use XmlDocument than XPathDocument even in areas where they compete. Try to select a value from namespaced XML to understand what I'm talking about. So XPathDocument is read-only and has clumsy API... No chances, be it even 10x faster.
The mismatch between the DOM data model and that of XPath meant that XPath queries or XSLT transformations over the XmlDocument would never be as fast as XPathDocument. Another reason we were doing this was that since the XmlDocument is not an interface
based design there isn't a way for people who implement their own XML document-like classes to plug-in to our world.
So... Now we gonna be forced to work with slow unextendable XmlDocument once again just because of legacy and laziness of devs??? Too bad. I wish we had at an alternative. C# has unsafe, .NET has not only VB.NET, but Managed C++, see what I mean? There should always be some more effective alternative for those who aren't lazy to learn something new and up to rewriting some code to gain performance boost.
And there is another side - one size doesn't fit all. I doubt XmlDocument can be made radically faster and it's interesting to see how it will survive in XQuery era, whose data model differs from DOM even more than XPath 1.0's. So instead of focusing fully on reanimating XmlDocument I wish System.Xml devs to focus on developing several tools best optimized for different scenarios. I wish we had editable XPathDocument in .NET 2.0. Do you?
In the related news: next generation of legendary books by Michael Kay are in print already and waiting for you in your favorite books shop.
 
Here is related discussion in xsl-list.
Things turn slowly nowadays. Michael Kay on XSLT 2.0 perspectives:
We're going to have to have a second Last Call because of the number of
comments received. You can't do a Last Call in much less than four months.
The CR phase these days for a complex spec is rarely less than 12 months,
because of the requirement to create a test suite and demonstrate
interoperable implementations. So I personally think that reaching full Rec
status in 2005 is looking unlikely. That's a personal view, not an official
W3C one.
The XSLT spec is probably more advanced than others in the family; but very
little work has been done yet on the testing side.
I'm reading "XQuery: The XML query language" book by Michael Brundage. Very well written and enjoyable to read book (well may be that's because my previous one was oh-boy-1000pages-of-math-and-pseudocode "Introduction to Algorithms" ? :). Anyway, here is what an interesting stuff I found in Michael's XQuery book. On page 29 Michael presents sample team.xml document, here is small excerpt from it:
<Employee id="E5" years="0.6">
<?Follow-up?>
<Name>Jason Abedora</Name>
<Title>Developer</Title>
<Expertise>Puzzles</Expertise>
</Employee>
Nothing special, huh? But look more thoroughly. Can you see an anagram here? There is additional hint on the page 136, where Michael illustrates one-to-one join of team.xml with another sample document projects.xml using FLWOR expression. Here is an excerpt from the join:
<Name>XQuery Bandit</Name>
<Name>Jason Abedora</Name>
Now it's easy to see it :)
Mikhail Arkhipov is trying to come up with any reasonable syntax for expressing generic controls in future versions of ASP.NET (he doesn't think it will be in Whidbey). So far all of them look plain ugly or unextendable (e.g. WRT to multiple types), needless to say malformed according to XML or even SGML:
<vc:SomeGenericControl<SomeObjectType> runat="server" />
<vc:SomeGenericControl:SomeObjectType runat="server" />
<vc:SomeGenericControl.SomeObjectType runat="server" />
<vc:SomeGenericControl(SomeObjectType1.SubType1, SomeObjectType2.SubType2)
runat="server" />
Any ideas?
My latest article "Building Practical Solutions with EXSLT.NET" has been published at the MSDN XML Developer Center. This is an overview of the EXSLT.NET library and its extension functions from the practical XPath/XSLT programming point of view. Basically I wanted to show how to use EXSLT.NET functionality in practice, so I went through all EXSLT modules and showed how these functions can solve frequent XSLT problems such as multistep transformations, date and time manipulations, doing math, parsing and matching using regexp, calculating sets difference, intersection or getting distinct nodes, padding, splitting, tokenizing, replacing and other advanced string manipulations etc etc etc.
Comments are welcome!
EXSLT.NET is sort of answer to "No XSLT 2.0 in .NET???" question and as such it unexpectedly becomes more and more important. In recent Online Chat with Microsoft XML Team, Arpan Desai, Microsoft PM on XPath, XSLT, and XQuery stack said: "Although EXSLT.NET is not officially supported by Microsoft, we will endeavor to make sure it works ;)". Another question was about moving EXSLT.NET into the core System.Xml to make it available out of box, more performant and what's more important - to eliminate full trust security requirement. They said they are considering it. Meanwhile there are some bugs and improvements on EXSLT.NET I wanted to work on. For reasons beyond my control I've got some free time this week, so...
Wesner Moise (.NET Undocumented blog) compares old good .NET 1.X System.Collections.Hashtable and brand new Whidbey Dictionary<K,V>. Interesting. In short:
- New collision elimination strategy - chaining instead of probing. Yeah, array based linked list for each bucket. Allegedly it doubles perf! Who said linked lists are just interviewers' toy?
- As a consequence - more thrifty memory usage, especially when storing value types.
- Dictionary preserves order of keys.
- Empty Dictionary occupies only 40 bytes.
- Struct-based enumerators hence fast enumeration.
- No probing hence no more load factor.
Stephan Kepser (University of Tubingen) has presented a talk called "A Simple Proof for the Turing-Completeness of XSLT and XQuery" on recent Extreme Markup Languages 2004 conference. You can find the paper at the link above and report by Elliotte Rusty Harold here. Here are my comments on that paper.
Cafe con Leche XML News:
Hot diggety dog! IBM and Novell are teaming up to add XForms support to Mozilla! If I were Microsoft, I'd be very, very worried right now.
Btw, MSDN Technical Chats now can be hosted by MVPs. Cool!
Recent Online Chat with Microsoft XML Team was tremendously interesting, but too short (45 min?). Being MVP I wonder what if we arrange some chats on actual XML topics, like XQuery, new stuff in System.Xml v2.0, new XML editor in VS 2005, XPath/XSLT for newbies/advanced, using EXSLT.NET, you name it (tell me what you'd like to discuss online). What about the idea?
Ok, this is a simple one, if
XML + XSLT = 5
XPATH + XPOINTER = 10
RSS + ATOM = 7
XINCLUDE + RELAXNG = 11
Then what is
XHTML + MATHML = ?
TheServerSide.NET and Developmentor offer free download of the "Essential XML Quick Reference: A Programmer's Reference to XML, XPath, XSLT, XML Schema, SOAP, and More" book by Aaron Skonnard and Martin Gudgin (PDF version).
432 page book covers XML 1.0 and Namespaces, DTD, XPath 1.0, XPointer, XInclude, XML Base, XSLT 1.0, SAX 2.0, DOM level 2, XML Schema 1.0 and SOAP 1.1. Very valuable reference.
[Via Mike Gunderloy]
|
|
Recent Comments