I finally got some time (18 hours in a plane to Seattle :) to settle down my mind about XLinq. Erik Meijer's excellent article, which explains XLinq from functional programming point of view made me changing my mind on some issues I wrote earlier, some hands on experience and some comments from smart readers helped me to see a bigger picture.
September 2005 Archives
XLinq is at early stages, but what else would I like to see in XLinq? Here are my crazy wishes.
Nodes in XLinq overload ToString() method to provide pretty-printed outer XML representation. At the same time nodes contain (familiar for MSXML users and new for .NET users) readonly Xml property, which returns raw (not pretty-printed) outer XML representation. At also at the same time casting element to a string returns element's value (string value with no angle brackets). There are also WriteTo() methods and Save() methods to complete the picture. I believe that's unnecessary confusing. Not only cast to string and ToString() do completely different things, but also there are many different ways of serializing nodes.
In XLinq XML Tree is exposed in a heterogenos way, that is nodes in a tree don't belong to a common type. Traditionally XML tree models are homogeneous, e.g. in DOM every node belongs to a specific kind of XmlNode class. But in XLinq attributes and text nodes aren't actually nodes. Instead attributes are just name-value properties of element nodes and text nodes while being internally normal nodes, never get exposed as such, but only as values they contain, so in effect what you can get out of XLinq tree is XNode (XElement etc), XAttribute and String values (which you can cast to appropriate CLR types). Apparently the goal was to simplify API and data model comprehension for users.
XLinq: XML Programming Refactored (The Return Of The Monoids)That's really good one.
[Via Lambda the Ultimate]
I'll be at the Microsoft MVP Summit in Redmond next week. I'm Microsoft MVP for second year, but that's going to be my first MVP Summit. That should be fun.
XLinq is new and hot technology everybody seems to be happy with. I'm going to post a different review series - not what I like, but what I dislike and want to be fixed in XLinq. Sorry in advance for bitter words, but it's better when your friend says them.
XML functional construction
Being excited about XLinq I couldn't stop myself from grabbing XLinq.NET domain name. I'm going to try to build a community portal for the XLinq technology. The goal is basically to push XLinq by growing a community around it. There is definitely a need for Microsoft-independent easily accessible place where developers can find XLinq resources or share their experience.
Hmm, according to Stan Kitsis there is at least 6 ways to associate an XML Schema with an XML document in Visual Studio 2005:
1. Schemas Property on your XML documentIs it actually sane? Now I can easily imagine a situation when I cannot be sure against which XML Schema file I'm validating my documents. Lots of flexibility, too much or just right? What is your take?
Little xml:id spec finally got W3C Recommendation status. I believe XML programming would be better be xml:id done in 1998, not in 2005. Anyway. xml:id provides a mechanism for annotating elements with unique identifiers. You just set xml:id attribute for an element and you done, no need for DTD, XML Schema or anything else:
<catalog> <book xml:id="b101">...</book> <book xml:id="b102">...</book> <book xml:id="b102">...</book> </catalog>Having elements annotated with IDs you can query them (usually very fast and efficiently) by ID values using various XML API specific means - GetELementById() in DOM, id() function in XPath/XSLT/XQuery, XPathNavigator.MoveToId() etc.
This is a repetitive pattern: once in a 6 months I get tired of comment and trackback spam and go upgrade my blog engine or install some antispam plugins.This time is not different. I've been massively attacked by spam trackbacks so I had to upgrade to MovableType 3.2. Not without a troubles though. Somehow it just didn't work after upgrade, but happily I found a solution at the MT support forum. Now all comments/trackbacks I get are subject to junk filtering and manual approvement.
I chose this strategy: each comment/trackback goes into unapproved queue and never makes it into a live page (except for authenticated comments). I get mail notifications for each comment/trackback and if I see not a spam one I approve it in just one click, spam ones I don't touch. Once in a week or so I go to blog admin and junk/delete all unapproved stuff again in a couple of clicks. Not that I love it, but still I can live with it.
We've heard about XML penetration into C#, Java and SQL. Now it seems like 45-years old programming language, 75% of worlds's business apps is written in is ready to adopt XML. I'm talking about Cobol, yeah baby! In the "XML and the New COBOL" article at webservicessummit.com Barry Tauber explains proposed forthcoming standard that will add native XML support to the Cobol language. IBM, HP and MicroFocus are behind this move, so chances are good.
And btw I'm currently working with Fujitsu NetCobol, which is .NET based Cobol and as such has full access to the .NET XML processing facilities. Not bad approach too!
That's an interesting chat:
C# 3.0 Language Enhancements
Here are some amazing facts about Microsoft Visual Studio: