Let's bring on Don. Don Demsak, a.k.a. DonXML, is an independent consultant based out of New Jersey. He specializes in building enterprise applications with .NET. He's a Microsoft MVP for XML, of course, and has just been recently added to the INETA Speakers Bureau. Would you please welcome back to the show, Don Demsak. Hi Don.
Hey, how are you doing, Carl and Richard?
Carl Franklin: We're doing fine. We just finished a couple of great dnrTVs on LINQ to XML and we thought, "Let's talk about it on .NET Rocks."
Don Demsak: Let's rehash it one more time.
Carl Franklin: So LINQ to XML.
Don Demsak: LINQ to XML—a lot of hype out there about LINQ; a lot of hype out there about LINQ to SQL, about querying your databases and using a standard query syntax, and some nice simple mapping to query your tables and there was a lot of buzz about LINQ's entities but one of the things that I guess a lot of people are missing is the new XML Object Model that they're unveiling in .NET 3.5 called LINQ to XML. I wish they (Microsoft) would've come up with a better name than LINQ to XML, XLinq was cool but LINQ to XML is what we've got.
Carl Franklin: Well that's okay. Let's start at this Code Camp or something. I think it might have been the New Jersey Code Camp and it might have even been the time we went to the New Jersey Code Camp while we were on the road trip, do you remember that?
Don Demsak: Yeah, it was the road trip.
Carl Franklin: Yeah, it was. That's exactly what it was because Miguel was there and you were there and, of course, it was New Jersey. So you were talking about this out in the lounge and sitting with a bunch of geeks and you had the idea that, "Oh my God, this is horrible," because the basic idea between LINQ to XML is XML literals right in your VB code and it was only VB that was getting this feature and it still is.
Don Demsak: It still is. It's only VB that's getting the XML literal feature which is different than the LINQ to XML which is
Carl Franklin: Yeah, it's a feature of LINQ to XML, right.
Don Demsak: Yeah.
Carl Franklin: You were horrified because you thought that this was going to encourage spaghetti code, ala ASP and you know the intro joke, "You've got your VB in my XML and my XML in your VB." I mean, that's really what it's like when you look at it but since that day in 2005, you've come around, huh?
Don Demsak: Oh, definitely I've come around and most of it was because of Lutz's Reflector.
Carl Franklin: Yeah. How so?
Don Demsak: When you look at the code, if you haven't seen it yet, definitely stop by and check it out, but you actually have XML, sans the quotes, embedded in your VB code and it definitely harkens back to the nightmare that was classic ASP. For any of us old timers now, I guess.
Carl Franklin: Back in the old days.
Don Demsak: Back in the old days. That pain was so severe that it just sat with me and said, "This visually reminds me of this." And I didn't like it. Right down to the percentage equals and the yellow highlighting, it just made you regress to that period.
Richard Campbell: It's got to give you chills. We just got away from ASP for crying out loud.
Carl Franklin: Right.
Don Demsak: I mean, it was tough. It was definitely a tough thing to get over visually, but once I looked at it in Reflector and realized that the compiler was playing tricks with us and they just added some syntactic sugar to VB 4. After that, when the compiler actually sees the XML behind the scenes, it actually does the functional construction using the LINQ to XML object model. Once you get that into your head and, not that visual stuff really didn't matter, then it really came to make sense to me, that this is just some syntactic sugar, yeah, visually it looks this way but it's not strings behind the scenes, it's actually compiled down to just about the same stuff that if you would've typed it in C#. New X element open parenthesis library, normal stuff
Carl Franklin: Don, it seems to me that the problem with classic ASP wasn't what it compiled to but that the absolute spaghetti code that you could come up with just by mixing these two worlds in absolutely obscene ways and leads to write only code, debug proof code. So can that still happen with this stuff?
Don Demsak: That can still happen and there are performance implications how you actually write your stuff. So just like in classic ASP and just like what you can do now on ASP.NET, you can, in the middle of your markup, you can open up what they call an expression hole, which is the angle bracket, percent sign equals angle bracket, percent sign. You can open up a hole in the middle of your XML or your markup and then actually inject code in the middle there. You have to be really careful what type of code that you actually put in there and one of the things that, well the stories I'd like to tell, I actually got this story from Mike Champion, is the story of the Halloween problem.
Carl Franklin: Okay.
Don Demsak: The Halloween problem is something that they actually, if you are a SQL guru, or you consider yourself a SQL guru, a lot of times you're going to get the Halloween problem as a question in the end of your process. Basically, what it is, it happens when imperative data manipulation gets tangled up with declarative queries. If you have a declarative query in the middle of your declarative statements, you actually wind up doing some imperative data manipulation, doing a for each or opening up a cursor and looking through on your own, you wind up with issues on statefulness. So the story goes that way back when, in the early days of SQL, some programmers somewhere, had to go out and give everybody in the organization who earned less than $25,000 a 10 percent raise and then in his query, he actually opened up a cursor and did some work. It was recursive so what happened is the query actually ran successfully and didn't come back with any errors but if you went back and you looked at the results, it turns out that all the employees now earn $25,000 because it kept on giving them a raise until they reached that level. It's just an example of how you can, accidentally, mix some imperative coding in with something like declarative programming which typically doesn't have state and you wind up with strange results that you didn't expect.
Carl Franklin: Well, before we get into the details of this, just to put a cap on this point, in ASP, classic ASP, you could start declarative, you could write a few lines of code to get your data and then you could just go write an HTML page and then put little four loops in the HTML where it's mostly HTML and you could also do it the other way where you wrote a lot of code and the you would spit out HTML and both ways are heinous but with the XML literals, you have to start with code so there is at least that.
Don Demsak: Definitely, and it's more type safe.
Carl Franklin: It's more type safe, and one of the features that I discovered during our dnrTV discussions is that the XML is contrasted so that it's lighter, the font is lighter. It's almost like a background—it fades.
Don Demsak: It fades. They added the fade which is really cool. I haven't tried it in the nouveau black screen and all that but at least in the white background it does fade. It does a really good job fading it back there. That's the idea, it means data, so push it in the background just a little bit. So you've got the selected code [that] actually jumps out at you. And that was a little thing that they added, the VB Team added in, in the early CTP's and boy, it made a dramatic difference when you start looking at it.
Carl Franklin: So, let's get into just a little bit of what you can do with this. Let's say we've got an XML file and to use the example from dnrTV, the library is the top, a music library, so you got library and then you have artists and then albums and then tracks, sort of like this nested XML, and let's say that you have the task where you want to convert these to a CSV file or you want to print it.
Don Demsak: You want it in XML, or XHTML.
Carl Franklin: You want to go through the XML and you want to pull out some of this data for whatever reason. Your first inclination might be to reach for XPath but how would you
Don Demsak: Not most people.
Carl Franklin: Yeah, well, yours would.
Don Demsak: Mine would but not most people.
Carl Franklin: And I was commenting to Richard that I actually had to do this. I had to convert some data from XML to a comma separated value for importing an address book into Google Mail and it worked and I actually used the code that you wrote in dnrTV as a template and it took me all of five minutes to adjust it for the XML file that I was working.
Don Demsak: Oh, definitely. It definitely makes it so much easier to do.
Carl Franklin: How do we go about doing this?
Don Demsak: Well, something like that, if you have some template stuff, you've got some template codes, let's say it's XHTML. You have your XML file and you're going to go open it up using the XDocument and the XDocument.load.
Carl Franklin: Now that's new. XDocument is a new type.
Don Demsak: XDocument is a brand new class. It is not the root of all LINQ to XML like the XML DOM is.
Richard Campbell: Yeah, that was what I was thinking. DOM, DOC—sounds pretty close.
Don Demsak: The old school XML DOM was very document-centric. You couldn't create an XML element or XML attribute without actually using the factory methods off the document. So basically, you always have to have a document and every part of XML had to be associated with a document somewhere.
Richard Campbell: That was all well and fine until you had 400,000,000 elements.
Don Demsak: And you had all of these transient variables that you really weren't doing much with except, there were placeholders that you were going to throw around so you used a factory to create a new element and then later you had to go in and add the element wherever you wanted to put it and it was very non-intuitive. It was very classic C++ object-oriented programming but we're beyond that, we're beyond classic C++. We're into brand new object models and using generics and using functional programming and declarative programming techniques within our imperative code which is C# or VB—it's imperative. The idea behind C# or VB is that you're telling the computer how you want it done not what you want done.
Carl Franklin: So, you've got this XDocument. You open it up. You still have to use a namespace?
Don Demsak: You can still use the namespace but what's really cool in VB is they allow you to import a namespace just as if you we're importing a .NET
Carl Franklin: A code namespace, yeah, imports.
Don Demsak: And it looks just like an XML namespace. It's open angle bracket, XML namespace equals whatever and if you want to put a prefix in, you could put a prefix in.
Carl Franklin: Don, before we go too much further, tell us what is LINQ to XML and what is VB literals because you're talking about VB here that can do the imports but not in
Don Demsak: In VB you can do the imports. In C# you don't have that import capability. It's just some syntactic sugar.
Carl Franklin: I'm just curious as to why not C#? And I'm usually asking the other way around.
Don Demsak: That is really a big case here. The C# team managers and such have decided that they didn't want to extend their language to include en vogue things like XML. That at some point in time XML would be passé and people won't be using it. They'll be using JSON or whatever else they're going to be using and why tie their language to XML or any other language?
Carl Franklin: I've heard the word pollute. They don't want to pollute the language.
Don Demsak: Oh, yeah, they call it pollute.
Richard Campbell: You know what this reminds me of? Looking at XML literals? Do you remember the old data statement in BASIC way back?
Carl Franklin: I do Richard, and as a matter of fact, I needed the data statement recently because after our discussion of speech and Eliza, I found that code and started converting it and it had data statements in it.
Don Demsak: Now, wouldn't this be really cool with the voice XML.
The conversation continues online at http://www.dotnetrocks.com.
|Editor's Note: This article was first published in the January/February 2008 issue of CoDe Magazine, and is reprinted here by permission.|