Well, it's Sunday. Calm and peace around newsgroups, forums and blogs. But in Israel it's workday, really. And I like it btw. RSS waves brought me today really enjoyable reading - MSDN Mag February 2004 issue. Nice. Here are couple of cynical comments though:
"Console Appplications in .NET" by Michael Brook.
I'm console-oriented guy too and my first .NET application was nxslt.exe command line utility for running XSLT (in fact I rarely run it in real command prompt, using as external transformer in XML Spy instead). But I'm not so wacky as Michael is! What he is showing in the article is "the world's first command-line RSS reader". Well, it's really hard to think up good samples for an article...
"Comparing the Timer Classes in the .NET Framework Class Library" by Alex Calvo.
I didn't realized there are three different timer classes in .NET FCL - System.Windows.Forms.Timer, System.Timers.Timer and System.Threading.Timer. Good to know. Here is a summary comparison table.
"WEB Q&A", Nancy Michell is still not aware of XInclude way for combining XML documents. Too bad, DTD sucks on combining loosely coupled documents. XSLT doesn't, but hurts perf. XInclude is the way to go.
"XML in Yukon. New Version Showcases Native XML Type and Advanced Data Handling" by Bob Beauchemin. It's excerpt from upcoming "A First Look at Microsoft SQL Server "Yukon" Beta for Developers" book. Good intro. Here are some perls:
The introduction of this native XML data type, coupled with the emerging industry standard XQuery language, should spark a revolution in database application development.I'm pessimistic on that. I hope for some changes, but not a revolution. And do we really need another revolution?
Having XML data inside a relational database may offend some relational purists, but it means that your data lives in a single repository for reasons having to do with administration, reliability, and control.Hehe, poor relational purists, it's time to think XMLish.
In addition to the query capabilities of XPath, XQuery allows element and attribute construction via XSLT.WTF? I'm sure it should be "like XSLT".
"The XQuery Designer in Action" - cool. Now I'm dying to give it a shot.
Yet another thought, although this goes far away from the main topic -- the same 1.0 1.1 problem exists also with EXSLT for .Net.
Or am I wrong?
Cheers,
Dimitre.
To provide for download two versions of nxslt.exe will be more user-friendly than to force them to manually build nxslt.exe with 1.1.
Probably give the 1.1 version of nxslt.exe a completely different name, so that there would be no confusion.
I think the time has come to use 1.1 and if I had nxslt.exe working with 1.1 I would not use the older version at all.
Having nxslt.exe only for 1.0 deprives the users from using the possibly better 1.1 XSLT processing.
As I understand it, the main purpose of nxslt.exe is to give the users easy access to this functionality, not to give them access to an obsolete version of the framework.
In summary, a 1.1 version of mXslt.exe is much needed and will be immediately useful.
Cheers,
Dimitre.
Another idea. I can provide for download two versions of nxslt.exe, compiled for 1.0 and 1.1 .NET (with appropriate flag in usage printout).
Hmmm, not friendly for testing both .NET frameworks...
Well, it's compiled under 1.0 (VS.NET 2002).
AFAIK, when you have 1.0 and 1.1 installed it'll run under 1.0 then.
It's a question how to make .NET version switchable. The only way I'm aware of is to have nxslt.exe.config file, where to declare required .NET version. Some more investigation is needed though. What do you think is the best - command line switch or two versions of exe?
That task is top of my nxskt-related todo list. There is also emerging .NET 2.0.
Hi Oleg,
I am using nXslt.exe in my everyday work and it is really a great tool.
I am under the impression that nXslt.exe as distributed has been built to work with the .Net Frameworl 1.0 only.
Am I right and if not, what is the way to use the 1.1 classes when executing nXslt.exe?
Cheers,
Dimitre.