XSLTs, when used/coded properly, should be really used as “rules-based” (i.e., “xsl:apply-templates”) instead of “serial-based” (i.e., “xsl:for-each” + “xsl:call-template”), and making your XSLT rules-based can be daunting at first but becomes powerful in the long run.  The only word I could describe it is that: beautiful.  I think XSLT is the closest thing I could get to the days I was writing in Prolog in my Computer Science classes.

XSLTs (again, when coded properly) are EASY to manage.  It is isolated.  If you have a good XML IDE like Stylus Studio (Not that crap XML Spy), it’s easy to unit-test.

It’s rather stupefying why some “programming gurus” out there detest it. Honestly, I would lose respect to any programmer who doesn’t consider XSLT to programmatically manipulate of complex XMLs…especially those people who’d rather write multiple lines of C# involving XElement than write an XSLT…or worse, LINQ to XML (*shudder*).

Apparently, I’m not alone on this: XSLT has been around since 1997, and the 1.0 has been part of the W3C Recommendation since 1999.  It’s not a fad.  And XSLT 1.0–despite its limitations–is still yet to be trumped by 2.0 because it’s already full-featured in itself.

Don’t get me wrong, XSLT is not the solution to everything XML-related.  However, itt should be part of any good programmer’s arsenal, along with that *other* awesome creation of Computer Programming world, Regular Expressions (that would be topic for another day).

Holy crap.  I could not believe I was reading all these whining.

I can certainly understand Jobs’ point on why Apple should restrict the tools to the bare minimum: At the end of the day, we want the devices to be as efficient as possible as far as power/resources is concerned.  It’s not so much as an issue with desktop devices, but it is a HUGE ISSUE on cellphones and portable devices.  No matter how thin a framework (Flash) is, it can never be as efficient as a code written in native language (Cocoa/Objective-C/C/C++).

Apple might be doing this restriction out of spite, but that’s hardly relevant.

We’ve seen Flash and how bloated and horrendous it is as far as resource management.  I would not want that thing draining the battery of my iPhone.

Upon searching, I stumbled upon on Scott Hanselman’s post on the project.  As I go through the comments, one commenter gave me an equivalent of a painful smack on the head; this is what he said:

I very rarely comment on blogs, but this time I have an itch that I just gotta scratch….

the question/concern I have is in regard to tight coupling and the lack of “Seperation of concerns” that this seems to introduce.

When setting the transaction isolation level in the application binaries arent we creating a very tightly coupled scenario in which the code has too much intimate knowledge of the DB?

How is a production DBA going to troubleshoot database performance,blocking, and deadlock issues? All we’ll see in the profiler is a bunch of inline SQL Statements with no indication of where they live or where they are coming from.

If the isolation level has to be changed, it would require a C# code change, a full QA cycle and a binary redeploy.

Seems to me that placing this in sprocs shields the app from having to know too much about the database.

Futhermore, this makes me think of some comments Bob Beauchemin had on his blog regarding performance tuning SQL generated by LINQ. He’s right…..if we cant control the SQL that is generated by the API, we will likely have huge performance issues that cannot easily be fixed without a huge redesign at the application level.

Currently, as all SQL code lives in sprocs, when I see a performance issue, I can turn the profiler on an very quickly determine the sproc that is the troublemaker and then I can quickly and easily modify the sql as needed to optimize it. Knowing all the way there are many ways to write the same query while yielding the same results but very different performance. Sometimes I just need to change a join to use a correlated sub-query instead. Somtimes I need to tweak the method used for filtering my WHERE Clause…..

while making changes to the sproc I can instantly see the performance gains by viewing the query plan and monitoring sub-tree cost, etc. If LINQ is generating SQL for me, this becomes impossible.

Am I worried about nothing here or are these issues really going to exist with the wide adoption of LINQ?

If you really look at it, L2E has lost its appeal.  Mr. pdxJaxon, I nominate thee as 2010 Programmer of the Year.

I re-wrote the part of the code that uses L2E to an sproc.  It’s now at least 50% faster.  Time to gloat.

Microsoft.WindowsAzure.StorageClient.StorageClientException: One of the request inputs is out of range.

After my usual WTF routine (which involves throwing chairs and strangling myself), I broke down and googled.  It turns out that all I need to do is change the name to “unittestqueue”.  That’s right, ladies and gentlement You cannot use capital letters to name your queues.

Awesome.

Unlike that travesty that is called LINQ to Entities, LINQ to XSD just works. Don’t let the Alpha 0.2 designation fool you; it’s full-featured, including near-seamless integration with Visual Studio 2008…unlike some tool out there that’s already in version 3.0 but performs like it’s in pre-alpha version.

So why/when would use LINQ to XSD? Sure, you can hand-code .NET objects based on your XML Schema and rely on the [Serializable] attribute and just use XmlSerializer…that works…if your schemas aren’t terribly complicated. However, when you start using a more complex XSD that changes often, automating the process certainly eases the pain.

But what does LINQ to XSD offer over something like…the all-time-favorite class generator, XSD.EXE? Well, first of all, XSD.EXE still generates classes around the “old” .NET objects, XmlDocument; LINQ to XSD builds around that more awesomerz XDocument objects. Second, the way LINQ to XSD integrates with VS2008 is elegant in such a way that it doesn’t make the developer feel stupid: it hides the abstraction of creating the classes BUT it provides a “back door” for all the classes it creates–i.e., it still provides access to the internal classes it abstracts from you (OH, HELLO THERE, LINQ to ENTITIES…)

When you include an XSD in a LINQ to XSD project, you are given the “compile option” to create LINQ to XSD classes…No, you never see the generated .NET source code for the classes (actually, you can…but it’s not intended to be exposed), but that’s fine…in fact, you will prefer it this way, anyway; and…you can still browse the object classes generated…sweet, isn’t it? Change the XSD? Go ahead, the object classes gets regenerated, too…In contrast with XSD.EXE where…bah…I’m not even going there.

So there you have it: one of the few features of LINQ that works. Imagine that.

<data format="text">
  <internal-data format="integer">123</internal-data>
  <payload>The quick brown fox jumps over the lazy dog</payload>
</data>

The XSLT result will be:

var doc = new XDocument(
  new XElement("data",
    new XAttribute("format", "text"),
    new XElement("internal-data",
      new XAttribute("format", "integer"),
      new XText(@"123")
    ),
    new XElement("payload",
      new XText(@"The quick brown fox jumps over the lazy dog")
    )
  )
);

You can now use the generated code in a method or unit test. Of course, the example is stupid simple; you can probably hand-code it faster. The XSLT only becomes useful when the XML becomes a bit more intricate that it requires more than 10 minutes to hand-code.

Simple enough, yes? A knowledge of XSLT would, of course, is needed to understand what the XSLT does, but for somebody who just wants a code generator, all you need is an XSLT engine (like Visual Studio 2008).

One limitation of the XSLT is that it can only deal with ONE XML Namespace…so multiple namespaces will need a bit more work on the final generated C# file before it becomes useable.

Trivia: This was supposed to be the topic of my third CodeProject article which I ended up deleting…because the good people at CodeProject thought it “lacks substance” Which I thought was a bit painted with hypocrisy when a huge number of articles in CP have no substance at all. OH, WELL.

Download the XSLT.

Rant #1: “LINQ Method cannot be translated into a store expression.”

As always, Microsoft and their cryptic error messages.  I ran across this error while developing a Worker Role Azure application that heavily relies on LINQ to Entities.  The experience is somewhat akin to this, but it was a bit more rude awakening experience for me.  I kinda know why this doesn’t work now, but my beef with this is that why isn’t it flagged as a COMPILER error?  Why is it a run-time error?

Rant #2: Why do I have to explicitly have to call .Detach() to an Entity when the EntityConnection and context is already out of scope?  I mean, WTF is that?  And why oh why do I have to explicitly call .Attach() to a new EntityConnection and context?  Shouldn’t it automagically work?!

Now, I know LINQ to Entity is still basically in its infancy, and I’m sure by .NET v27.5 or whatever, Microsoft may have even perfected it.  That’s assuming they don’t introduce another programming paradigm into their Framework.

Sometimes, I wonder WHY Microsoft had to tack on the LINQ stuff to existing C# or VB or whatever.  Wouldn’t it make more sense to define a new language altogether?  Calling delegates/methods/functions across multiple languages is dead easy anyway.

I still don’t see the value of LINQ at all…the only somewhat cool use of the extension is the ability to filter contents an IEnumerable object.  THAT’S ABOUT IT.  Database access?  I still prefer ADO.NET.  XML?  XSLT and XPath is enough for that.

I’ll probably write a new CodeProject article about it…or maybe not…ZZzzz.