Title Image

Don Xml's Grok This

The home of Don Demsak
Welcome to Don Xml's Grok This Sign in | Help
in Search
Home Grok This All Things Techie Music Blog Photos Downloads

This Blog

Syndication

Site Sponsors

Recent Posts

Archives

DonXml's All Things Techie

Question – XSLT and XML Schema – Resource File or Code

I briefly touched on this subject a while back, but it has recently come up again.  Should we treat XSLT and XML Schema (and others, maybe XQuery) as just resource files, or are there cases where it would be better to treat them as first class .Net languages?  Since both XSLT and XML Schema came to life via the W3C, they have been traditionally treated like resource files (late bound script files in the best cases), that need to get deployed with your app, and are interpreted at runtime (and hopefully cached).  I guess this is because these are declarative and not imperative languages.  But, SQL is a declarative language, and we do have forms of the language that get compiled before runtime (stored procedures).  At the moment, we can not do this with either XSLT or XML Schema, but the question remains, is this something that might be useful (boy I can see the flame wars over compiled XSLT versus dynamic XSLT already, just like the stored proc versus dynamic SQL).


With .Net 2.0, XSLT can now be compiled to MSIL using XslCompiledTransform, but it XSLT is still treated as a resource file.  With XML Schema, they can be cached, but as far as I know, you can’t compile them down to MSIL.  The most significant feature (in relation to this idea) is that MSBuild supports multiple programming languages in the same project.  So, in theory, if you can compile C# and VB.Net in the same project, why not XSLT or XML Schema?  There are certain things that I can write faster using a declarative language (and seem more natural), then with an imperative one, and why should picking one over the other force me to either compile it or, treated as a resource file.

The next logical step in this inspiration is why stop at XML based languages?  Meaning, what about XQuery?  Would XQuery be a better language to include within Visual Studio (over XSLT)?  I know that a lot of developers have a real hard time with the syntax of XSLT, since it is based on XML.  Combine that with the fact that more data developers know SQL over XSLT, and does that make XQuery a better language for the VS.Net developer?  Especially considering XQuery is all about querying hierarchical data, which is probably more important to a VS.Net develop, then a language to fully transform hierarchical data.

I’d like to get some feedback on this.  I’m I going over the edge here, or is this something that will make things easier for the average developer?

Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!
Published Wednesday, June 01, 2005 1:43 PM by donxml
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

David Douglass said:

Good questions Don.

As of the moment, I’m not an XSLT fan. The things you’re talking about could help to change that. If XSLT were treated as just another .NET language, we could get complete intellesense, on-the-fly compilation, and full debugging support. Since XSLT is not object oriented, I think any XSLT program would have to implicitly derive from XslTransform and implicitly load the script.

I think compiling schemas might be useful only as an optimization technique. Maybe this could be combined with making the code for validation less clumsy.

XQuery is a candidate for compilation along the same lines as the schema: only for optimization since it isn’t procedural.
June 2, 2005 7:07 AM

Phil said:

The way I see it, stuff like XSLT and XML Schema and even, to some degree, XQuery and XPath are, very much like SQL, in that they are "ugly to write" for the OO-focused developer (and an "impedence mismatch" of some sorts considering the constant switching of paradigms for the developer). Thus this "ugliness" has little to do with tool support. I see these languages like I see assembly code (vs. 3gl languages) or HTML. They are at their best if they are generated from a more abstract, domain-focused language. So you have to deal with them, but only if you need to transform some higher-level code into these languages. XSLT is already a transformation language? So what? Surely for very specific requirements you'd still want to conceive a _simpler_ transformation language, write your transformations (of your domain-specific XML documents) in that (also domain-specific) transformation language, and transform the transformation scripts in your own transformation language to the equivalent (and clumsy as usual) XSLT transformations, then run these transformations.

Sounds like a joke, even to me now as I write this, but I was in fact serious about it...
June 3, 2005 8:08 AM

John Wood said:

Interesting topic.

Compiling XSD is certainly something I'd like to see - but the question is, compile it down to what? Until we have more alignment between the common type system and XML schema types we'd have a hard time doing anything with a compiled XSD file.

Saying that, they've managed to do something along those lines with C-Omega (bridge the gap a little), so perhaps there is some hope for compiling XSD as part of your project, and then using those types as first class citizens in the language.

XQuery is also interesting, although I can't see that you'd derive much benefit from a compiled version of XQuery on the client - it's declarative for a start, so it wouldn't just compile down to IL. As to whether it should be just another .Net language, well getting MS to include XQuery in the framework at *all* is hard enough, let alone getting them to embrace it as a real language with a compiler.
June 9, 2005 1:12 AM

Don Demsak said:

Actually, in .Net 2.0 XSLT does compile down to IL (actually QIL), which is how you can place breakpoints within your XSLT in .Net 2.0
June 9, 2005 12:53 PM

John Wood said:

Interesting I didn't know that. In fact that's the first time I've heard of QIL -- can you point me to any documentation?
Thanks,
John
June 9, 2005 2:03 PM

Leave a Comment

(required) 
(optional)
(required) 
Submit

About donxml

I’m an independent consultant, specializing in .Net solutions architecture, based out of New Jersey who also doubles as an evangelist for XML, Domain Driven Design, enterprise architecture and .Net. I do not work for Microsoft, the W3C or any other big company that you may know of (at least not yet). I’ve been an indie for over ten years, and although I’ve been tempted a couple times to take a job with companies like Microsoft, I’ve haven’t found something better than my current situation. I work mostly with the large pharmaceuticals that are based here in New Jersey, and usually find myself on long term contracts. Definitely not the prototypical indie consultant, but it lets me dedicate time to my non-income generating activities like the developer community stuff, plus financing open source projects like XPathmania and MVP-XML. If you would like to talk to me about doing some contract work, just contact me via the contact page. My rates vary widely, depending on lots of different variables, but mostly distance from Jersey, and type of work. Plus, I’ve been known to donate some of my code for various projects.

Tags
Copyright 2007
Powered by Community Server, by Telligent Systems