Random photo
Loading...
Domains for sale
|
January 25, 2004Reading Feb 2004 MSDN MagWell, 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. "Comparing the Timer Classes in the .NET Framework Class Library" by Alex Calvo. "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. January 25, 2004 4:43 PM
| #Ramblings
Comments
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?
Dimitre. Posted by: Dimitre Novatchev at January 27, 2004 2:34 PMTo 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.
Dimitre. Posted by: Dimitre Novatchev at January 27, 2004 2:01 PMAnother 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). Well, it's compiled under 1.0 (VS.NET 2002). 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?
Dimitre. Posted by: Dimitre Novatchev at January 27, 2004 11:11 AMPost a comment
|