I have previously written about the Microsoft XML parser (MSXML) and have had quite a lot of fustrations with it and was pleasantly surprised to find a post on the Microsoft XML Team’s WebLog on the subject. The post is called “Using the right version of MSXML in Internet Explorer” and provide details on the different versions of MSXML and which version to use where. The post even has an executive summary section which I recommend you skim though I’ll reproduce the most important 4 bullets for MSXML here:
- Use MSXML 6.0 – it is “in the box” on Vista and available for download on Win2k, XP, and 2003. It has the best security, performance, reliability, and W3C conformance
- MSXML 3.0 is our preferred “fallback” – It is installed on every OS from a fully patched Win2k SP4 installation on up, so it requires zero-deployment and is serviced regularly with the OS
- MSXML 4.0 was released to the web about 5 years ago, but at this point has been superseded by MSXML 6.0 and is only intended to support legacy applications
- MSXML 5.0 for Microsoft Office Applications is purpose-built for Office applications and isnt intended for broad deployment. Internet Explorer 7 actually has the MSXML5 components “off-by-default” in the Internet zone so your customers will get a goldbar for each MSXML5 control on a page if your code tries to instantiate it. The best recommendation is to avoid MSXML5 in your web apps (only machines with Office 2003 or higher will have it, anyway.).
Skim it now or save the bookmark for when you need to deal with MSXML.
Just say no to XML? @ Java O’Reilly.
"Validation reports whether a document adheres to the rules specified by the schema. Different parsers and tools support different schema languages such as DTDs, the W3C XML Schema Language, RELAX NG, and Schematron. Java 5 adds a uniform validation Application Programming Interface (API) that can compare documents to schemas written in these and other languages. Learn about this XML validation API."
yeasterday I have been reinventing the wheel and (re)writing XPath 2.0 functions as named XSLT templates since the MSXML 3 in Internet Explorer 6 isn’t XPath 2.0 compliant. As always there is however a Microsoft proprietary solution using the urn:schemas-microsoft-com:xslt namespace. This namespace adds support for a number of utility functions as mentioned in the “Microsoft XPath Extension Functions“-article over at Microsoft Developer Network.
You have to be running MSXML 4 for this namespace to work however which means that even the proprietary solution isn’t workable for me since MSXML 3 is the default for Internet Explorer 6.
While researching this subject I found that MSXML 3 (or 4) isn’t the newest version. There is a MSXML 5 (only used with Office 2003) and a MSXML 6 (supplied with Visual Studio 2005). Even the newest MSXML 6 doesn’t however support XPath 2.0. The supported API’s in MSXML 6 is:
- XML 1.0 (DOM & SAX2 APIs)
- XML Schema (XSD) 1.0
- XPath 1.0
- XSLT 1.0
Come on already – please implement the standards!
I’m doing quite a lot of work at the moment defining XML document “languages” and associated XML schemas (why I’m happy for the great XML and XML Schema (XSD) support in Callisto) at the moment. In that connection I’m also doing XSLT stylesheets for end-user presentation in Internet Explorer (version 6 or higher). We have to make Internet Explorer a requirement for user-presentation since Firefox doesn’t support resolving entity references when using XSLT which we need for content reuse.
Once this was settled it was all well and good until I yesterday discovered that Internet Explorer 6 (and hence MSXML 3.0) doesn’t support XPath 2.0 which means that all the nifty XSLT functions defined in XPath 2.0 such as the date/time functions cannot be used. Bummer!
So here I am back at reinventing the wheel rewriting all the date/time functions as named templates using the substring XPath 1.0 substring function. Even more bummer!
For some reason I fail to understand the recently released collection of plugins from the Eclipse Foundation (also referred to as Callisto) doesn’t include support for XSLT even though it has editors for XML, DTD’s and XML Schema (XSD). Support to XSLT is however very easy to add since you can use the EclipseXSLT plugin.
Installing is as easy as creating a new remote update site under “HelpSoftware UpdatesFind and Install” and installing it from there. The address to the update site is http://eclipsexslt.sourceforge.net/update-site. Took me 5 minutes or so. Easy. It does however require that you already installed the XML part of the Callisto release.