March 2004 Archives
This tool is undeservedly forgotten, but frequently asked and usually hard to find (somehow it's constantly moving around MSDN breaking the links). I'm talking about "Internet Explorer Tools for Validating XML and Viewing XSLT Output". IE out of box doesn't allow you to validate XML, the only way is to write some script. Also
when you open an XML document with attached XSLT stylesheet in IE you cannot view the result of an XSL Transformation, instead View Source shows source XML. These regrettable omissions make it hard to work with schemas and XSLT with bare IE.
Enter "IE Tools for Validating XML and Viewing XSLT Output" - Microsoft add-in for IE, which adds two commands into the browser's context menu - "Validate XML" and "View XSL Output". Very useful, a must to have for any XML developer. And implementation is soooo simple, just few lines of javascript. I wonder - can Microsoft make it into the core Internet Explorer code so it's available in each IE without additional add-in installation?
Ivan posts a link to the "GHOST TOWN" - a story of a real girl riding on a motorbike through the closed Chernobyl area, where nuclear powerplant has exploded back in 1986. Lots of fantastic photos. Abandoned cities 18 years after the disaster. Deadly amazing and sad story.
I've been there 2 years ago. My mother was born and grew up in a region close to that area (near to Kiev) and that's where my granddad and grandma rest in peace. They've been told about the nuclear disaster a week after! Fucking commy wanted to keep it in a secret. Sad story.
May be I missed something, but looks like Travis Bright is converting Apache Xerces XML parser to .NET. I wonder what for?
Aha, he's PM for the Java Language Conversion Assistant (JLCA). That explains. Btw, one day I stumbled across CSS parsing in .NET. Java version of the product I've been working on used W3C's Flute CSS parser and I didn't manage to find any .NET CSS parsers. So I just created J# project in Visual Studio, imported Flute's java sources, compiled them into dll with no any hitch and that's it - it just worked.
Well, of course the breaking news today are all about recently launched MSDN XML Developer Center. Should admit I've been checking http://msdn.com/xml several times a day last weeks :) At last it's up and it looks just great! Somebody said it's like blessing for XML. Kinda true. Of course the Dev Center has dedicated RSS feed - http://msdn.microsoft.com/xml/rss.xml - subscribe now. It's overwhelming to see a link to my blog in the front page too! WOW, now I should write only smart stuff.
Apparently it's possible to set a background image in VisualStudio.NET text editor via undocumented API. Interesting exercise.
[Via Mike Gunderloy]
Daniel says he's disappointed in SAX.NET project I was writing about. Unlike lazy me, he downloaded it and inspected implementation. Well, I mostly agree with him. This piece of direct thoughtless porting of complex convolute Java API to .NET looks weird and kinda unnatural. "namespace System.Xml.Sax {" isn't what I like to see altogether. Too many conventions are broken. Too bad to taste good. Well, I hope are they will improve things. At least todays conversation in xml-dev gives some hopes to think that.
Attributes2 and friends are traces of long SAX API evolution. SAX was created in a vacuum, there wasn't standard Java XML API at that time, while SAX.NET is going to live in .NET land and must be System.Xml-friendly. The question is is it feasible at all?
W3C announced the creation of the XML Binary Characterization Working Group.
Chartered for a year, the group will analyze and develop use cases and measurements for alternate encodings of XML. Its goal is to determine if serialized binary XML transmission and formats are feasible.
The WG has been created as a result of the Binary Interchange Workshop. Here is what their goals are:
The XML Binary Characterization Working Group is tasked with gathering information about uses cases where the overhead of generating, parsing, transmitting, storing, or accessing XML-based data may be deemed too great for a particular application, characterizing the properties that XML provides as well as those that are required by the use cases, and establishing objective, shared measurements to help judge whether XML 1.x and alternate (binary) encodings provide the required properties.
Too bad. I was hoping that won't happen and now I only hope they will decide that's bad idea and interoperability costs more than "overhead of parsing". Dare well argued Binary XML is evil here and I only subscribe to the views he quotes.
A long and convolute discussion about security problems of using EXSLT.NET in ASP.NET took place in EXSLT.NET message board. Here I'd like to formulate some short summary.
Looks like Google got new site skin. I like it. Lightweight and clean.
This webcast is going to be really interesting one: MSDN Webcast: Real-World BizTalk Server 2004 Editing and Mapping Techniques - Level 200
This session is a deep dive on the BizTalk Server Editor and Mapper. Learn how to model flat-files and EDI-files. Learn how to detail with complex mapping scenarios including embedding your own XSLT, using .NET components in maps, performing cross-referencing and exercising the table extractor functoid.
Presenter: John Ballard, Program Manager, Microsoft
Enroll here.
[Via Frank Arrigo]
May be I missed the train, but look what I discovered in the recent "Microsoft This Week" newsletter: MSN toolbar. It looks exactly like Google toolbar, moreover what's funny, http://toolbar.msn.com and http://toolbar.google.com pages are just the twins!
After all that's good move. I hope the competition is going to be fruitful for us, ordinar users. Let's compare. Both can block pop-up ads, search the net (obviously), keyword highlight. MSN toolbar can launch MSN Hotmail, MSN Messenger and My MSN directly, Google toolbar can't. Google toolbar can fill in forms with one click, MSN toolbar can't. Well, personally, as 1) I'm not using MSN Hotmail and My MSN, 2) my MSN messenger starts at Windows startup; 3) I like/use Google's autofill feature a lot - I still stay with Google toolbar.
Visual Studio 2005 Community Technology Preview March 2004 - Full DVD available for MSDN subscribers!
Arrrgh, I missed that day - 20 March my blog crossed 1 year timeline. Here is what I wrote a year ago:
Well, blogging is really infectious disease and finally I got the infection. I have installed Movabletype engine on my site quite easily (c'mon, it's cgi based) and here is my first record.
Lets see how it works. Administering is not bad and default template looks really nice, but I'm sure I'll modify all the style once I get some free time.
I named my blog "Signs on the Sand" (it took me the whole evening and the night to formulate my feelings), because I believe that's what all these words worth and that's their final destiny. Hmmm, whatever, I like it.
So happy blogging to me.
Ok, my productiveness was 190 blog items a year. Too bad. Must write more. Anyway, I'm glad I stepped in and today I just can't imagine myself without blogging and reading blogs. Every my morning starts with Mozilla Mail and RSS Bandit. So happy blogging to all of us!
Hey, SAX for .NET topic is becoming hot. I was aware of one implementation (to be unveiled really soon), being developed by my fellow MVP/XmlInsider, but apparently there is another one, by Karl Waclawek. Here is what he writes in xml-dev mail list:
The SAX dot NET project on SourceForge has the
goal of porting the SAX2 API to C#/.NET:
http://sourceforge.net/projects/saxdotnet
A release 0.9 (beta) can be downloaded from:
http://sourceforge.net/project/showfiles.php?group_id=95340 .
What's mostly untested is the helper classes.
The rest has already undergone usability testing
in the form of implementing an adapter for Expat.
Karl is known as seasoned XML developer, I particularly know him as one of Expat XML parser devs. Expat is a great XML parser, originally developed by James Clark (enough said). It's written in C and is magically fast one. At my work we use it as base XML parser for all XML tools we write for mainframes, yeah, that's really good one.
I'm glad to see growing appreciation of the .NET in broad XML community and I do believe community-developed implementation of SAX for .NET would be great step forward this way. The very fact of emerging SAX for .NET projects doesn't mean XmlReader's pull-based XML parsing paradigm is bad or disappoints some of us. Both pull and push parsing paradigms have pros and contras and having both available in .NET is a good sign of the technology maturity.
Here is a definitive answer:
Beginners always ask this question.
Those with a little experience express their opinions passionately.
Experts tell you there is no right answer.
Mike Kay
Update: this post is outdated, see "WordML2HTML with support for images stylesheet updated" for updates.
Here is a new version of WordML2HTML XSLT stylesheet, developed by Microsoft for Word 2003 Beta2 and adapted by me to Word 2003 RTM. I called this version "1.1-.NET-script". Here is why. Along with some bug fixes (typo with w:rStyle, empty <title> in generated HTML etc) I implemented basic support for images. That required XSLT extension function, which I implemented with .NET and <msxsl:script>. MHT and MSXML/Jscript versions are coming soon.
Here I go again with another experimental creature from my XML Bestiary: IndexingXPathNavigator. This one was inspired by Mark Fussell's "Indexing XML, XML ids and a better GetElementByID method on the XmlDocument class". I've been experimenting with Mark's extended XmlDocument, played a bit with XPathDocument and "idkey()" extension function Mark was talking about. Finally I came to a conclusion that 1)XPath is the way to go (that' not the first time I say it, right? :) and thus what should be extended is XPathNavigator; 2)no need to reinvent the wheel as XSLT's keys is proved excellent stuff.
That is what IndexingXPathNavigator is - XPathNavigator, augmented with XSLT keys functionality: it supports declaring keys, lazy or eager indexing and retriving indexed nodes via key() function all as per familiar and proved XSLT semantics.
Here is what MovableType blogging engine team writes:
We're taking our first steps towards the release of Movable Type 3.0. The pre-beta version has just finished its initial two rounds of alpha testing and we're now opening the testing to a larger audience ...
What's new includes: "significant change to the existing interface that embraces web standards, usability and localization", "new set of default templates", "suite of comment management features and versatile comment registration", API authentication hooks, Atom API.
Starting today, we'll be giving all of our users much more information on what to expect in Movable Type 3.0.
Sounds promising.
Hey, good news about GotDotNet Workspaces again! Changes on the releases section scheduled for tomorrow include: per-release download count (AT LAST!!!), no more zero-byte/corrupt downloads (I hope), no more Passport sign-in for downloads (great), off-site hosting of releases (cool). Really sweet.
[Via Andy Oakley]
XAML, Windows Forms Markup Language (WFML), Report Definition Language (RDL), Relational Schema Definition (RSD) and Mapping Schema Definition (MSD). You get the idea what the trend is nowadays. It's all XML. What I'm wondering though - why still there is no alternative ASP.NET XML-based syntax? How long ASP.NET will stay as "almost XML"? Wouldn't it be nice an convenient? After all Java has XML-based JSP syntax since 2001.
Hey, apparently recent Opera browser beta has RSS reader embedded. Here are some screenshorts - here and here. I like that trend.
[Via 10x More Productive Blog]
Ok, I've implemented EXSLT Random module, which consists of the only function random:random-sequence() for EXSLT.NET library. Here is how it looks now:
Dare is looking for suggestions on what the tagline of the MSDN XML Dev Center (which is about two weeks from being launched) should be. I stink on naming and have almost nothing to suggest. Anyway, here are my document-centric-minded slogans:
- Marking up the world
- The universal data format
- The language information speaks
- Lingua franca of the information world
Personally I'd vote for Dare's "The language of information interchange".
Speaking of talking about unreleased technologies. Here is MHO: basically I would prefer to see more "early bird" articles and may be even releases, orienting and leading us devs on what's cooking inside the house and how it'll smell. That's important to know to build personal learning curve and usually very interesting. With usual disclaimers about volatile nature of a subject of course. The timespan till release shouldn't be too big of course. And material sould be more theory-oriented, not implementation-oriented. But still I agree that released stuff is a way more important to cover than "glimpses".
Interesting new blog at blogs.msdn.com - "C# Frequently Asked Questions", where the C# team posts answers to common C# questions. Subscribed. Why doesn't C# support default parameters? Why doesn't C# support multiple inheritance? Why doesn't C# support #define macros? Ask your question here.
Watch out for some improvements in the Workspaces bug tracker next week (Tuesday 3/16/04).
GotDotNet Workspaces are about to be updated. Improvements: better bug search, separating bugs by a custom field (such as build number), customization of bug display, ability to export bug lists to XML, file attachments. Not bad.
[Via Andy Oakley]
Great article "XQuery from the Experts: Influences on the design of XQuery" by Don Chamberlin. It's an excerpt from a chapter of "XQuery from the Experts: A Guide to the W3C XML Query Language" book. Good reading. Why relational data model doesn't fit XML, why SQL can't be used to query XML data model, basic principles that underlie the design of the XQuery language etc.
That's a milestone in XSLT technology life - the most famous Java XSLT processor Saxon goes commercial. Here is what Michael Kay (author of Saxon and XSLT 2.0 editor) writes:
In March 2004 I founded Saxonica Limited to provide ongoing development and support of Saxon as a commercial venture. My intent is to continue to produce the basic (non-schema-aware) version of Saxon as an open source product, while at the same time delivering professional services and additional modules (including a schema-aware processor) as commercial offerings.
Well, that was predicted. The complexity schema added to XSLT closes the era of one-man XSLT processors.
Another interesting quote from Mike - about Saxon processor (it's not "XSLT processor" anymore, but "collection of tools" as it supports XPath 1.0, XSLT 1.0, XPath 2.0, XSLT 2.0 and XQuery 1.0) name:
The name Saxon was chosen because originally it was a layer on top of SAX. Also, it originally used the Aelfred parser (among others); Aelfred of course was a Saxon king...
Rick Schaut writes about stupidity of the XOR trick these days:
So, not only is the XOR swap stupid because it's obscure, it's stupid because, with modern optimizing compilers, the eventual result often ends up being contrary to the intended result of using the coding trick in the first place.
The moral is, before you consider using some obscure coding trick for the sake of performance, write up some sample code, and take a look at the actual code your compiler generates. More often than not, you'll find that the less obscure method results in better code.
That great deal smells declarative programming style! Just declare what you want and let compiler do optimization tricks. +1. After years of XSLT coding and an optimizing XSLT compiler I developed once upon a time I'd say what Rick said perfectly fits XSLT/XPath/XQuery family. It's the most difficult thing when going XSLT lerning curve - to stop thinking procedurally and start thinking declratively. A common sample is alternating in XSLT - whenever you need to distinguish odd and even rows, do not go thinking about manual counting, incrementing of a variable etc. That's not the way to go. Just rely on XSLT processor and declare you are interested in even ( position() mod 2 = 0) or odd ( position() mod 2 = 1) rows.
Somehow it happened that one of the most commonly used XmlReader usage patterns ignores NameTable.
That's really unfortunate! Everybody, including Microsofties, MVPs and of course zillions of users blindly follow it, carelessly slowing down XmlReader's parsing speed.
XML.com has published good article "Using XML Catalogs with JAXP". XML Catalogs are successors of SGML Catalogs and in simple words it's a system for defining resolving of resource identifiers (URIs or Public Identifiers) in XML. If you are .NET minded - it's about having XML document (called catalog), where you declaratively define how URIs in DOCTYP, xsi:schemaLocation, xsl:include/xsl:import/document() etc should be resolved by XmlResolver. So instead of writing you own XmlResolver you declare that "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" should be resolved as "C:/dtds/xhtml1-strict.dtd" in catalog file and get things done.
I'm sure many of you know this page, but for the rest - here is useful link to default Visual Studio .NET shortcut keys. I like this stuff. My favorite one is CTRL + TAB to navigate over opened files.
[Via Jason Mauss]
I'm going to implement EXSLT Random module for EXSLT.NET lib. It contains the only extension function:
number+ random:random-sequence(number?, number?)
The function returns a sequence of random numbers between 0 and 1 (as text nodes obviously). The first argument is number or random numbers to generate (1 by default) and the second one is a seed.
The problem is that .NET's Random class accepts seed as int, while in XPath numbers are double. So simple (I hope) question: how do you think it should be converted?
Hey, look at what Scott Woodgate writes:
Let the first ever BizTalk Server Developer Competition commence. We are giving away cash prizes totalling $25,000 USD including a huge $15,000 USD first prize. The purpose of the BizTalk Server 2004 developer competition is to highlight and reward programming excellence using BizTalk Server 2004 and Visual Studio .NET.
Complete details here.
How cool is that?
Yeah, that's cool, Scott. I'm going to participate! Timing is till August 31, enough time to get accustomized to BizTalk 2004 RTM, which by the way was released just today and is ready for MSDN subscribers.
Dare writes:
We were planning to add support for xml:base to the core XML parser as part of implementing XInclude but given that that it recently went from being a W3C candidate recommendation to going back to being a W3C working draft (partly due to a number of the architectural issues raised by Murata Makoto) the future of the spec is currently uncertain so we've backed off on our implementation.
Yeah, XInclude makes its tangled way to the Recommendation status really slowly. It's been CR for a long time and even there were some slips about PR, but then it's been backed off to WD soapbox again. These days XInclude is ready to climb up again. Many architectural issues have been fixed, syntax and semantics have been modified with respect to the Web architecture, there are enough full implementations for all major platforms (.NET, Java, C). And here is what Jonathan Marsh writes today in www-xml-xinclude-comments@w3.org maillist:
We believe this is resolution completes our resolution of outstanding
issues on XInclude, and we plan to release a new CR draft soon.
By the way, I wrote an article about XInclude and XInclude.NET and hope it'll be published soon.
Meantime some of you guys sent me logos for the XInclude.NET logo contest. Thanks! I'm going to arrange a page with a poll to see public opinions.
|
|
Recent Comments