I'm going to try to make this a regular feature for Tuesday, in lieu of my long (all right, verbose) normal rantings.
Microsoft Announces Longhorn to Ship in 2006, Cuts WinFS and Avalon
WinFS was to be the next generation file system, one which transparently melded local files with those on the web, as part of the process of creating Virtual Drives. Avalon, the core graphical system and the foundation upon which XAML sits, would have completely rebuilt the way that Windows handles its whole presentation layer. This week, Microsoft decoupled both technologies from the Longhorn mothership, saying that 1) they would probably be provided as upgrades in 2007, and 2) they would be backported to Windows XP.
Hmmm. What's left? Another two years of Microsoft's so-far less than sterling Security Inititative? Another version of .NET to add even more compatibility woes? Both of these technologies have been anticipated for months (or years in some cases) and Microsoft's inability to deliver on these raises some serious questions about the real state of Windows, and offers an opportunity for both the Linux community and the W3C to capitalize on if they are alert enough. The Avalon backport as well should beg the question - if I can get Avalon running on Windows XP (which will be a six year old system by the time Avalon sees the light of day) just what exactly do I need Longhorn for?
This may very well prove to be a new lease on life for SVG/XBL - IF the Graphics group acts quickly enough to get reference implementations in place, especially as the announcement about WinFS is also as effective an admission as is possible that maybe, just maybe, the http protocol isn't quite as bad as Microsoft has been saying.
XAMLON Releases Xamlon v0.9 with .NET Integration
In a curious bit of synchronicity, Xamlon, Inc. has released it's version 0.9 of it's Xamlon XAML interpreter, which can now be run within the .NET framework. Between Xamlon and competitor Mobiform , the third party XAML market is actually heating up much faster (apparently) than Microsoft's own technology is. Both of these companies seem to get something which has either eluded or stymied Microsoft's development efforts - XAML works much better when it is treated as an in-memory DOM application than as a pre-compiled system, even if the latter is slightly more efficient. Xamlon currently ties into .NET, making it easier to work with such features as intellisense and schema checking. I'll try to do a more formal review of Xamlon's product in a future blog.
Michael Kay Releases XSLT 2.0 Programmer's Reference
Michael Kay gained a reputation in the XSLT commmunity several years ago with his voluminous and comprehensive XSLT Programmers Reference. More recently, he has served as the Editor for the XSLT 2.0 Working Draft, and has also been keeping the Saxon XSLT/XQuery Processor up to date to reflect changes in the draft, making it the closest thing to a canonical implementation. Thus, it was natural for him to produce the next version of this bible for XSLT developers, and this week it was published and is currently available for sale on Amazon (I haven't seen it in stores yet, but it should be out shortly).
This book is pretty much indispensible in your library if you are planning on migrating to XSLT 2.0, and after having spent a year and a half myself with the evolving standard, I would heartily recommend making the change if you are programming within in Java or .NET (there is a .NET version being developed by Pieter Siegers and David Peterson, based upon the Saxon implementation) you should seriously investigate the tool, and buy Michael's Book.
Scribus Releases 1.2 Version of Desktop Publishing Suite
Open Source Company Scribus has released the 1.2 version of its open source desktop publishing suite for Linux. Scribus is an ambitious project - creating a full-featured desktop publishing system that provides an alternative to Quark Express, Adobe InDesign or Microsoft Publisher. Incorporating SVG and PDF generation and designed to work with SVG Editor Inkscape, Scribus has recently been adopted by a couple of newspapers for doing layout work (newspapers are, from personal experience, the acid test for a desktop publishing system). In addition to the formal 1.2 release, Scribus has also released an academic version, bringing decent desktop publishing software to potentially millions of kids in the schools.
I've been watching Scribus emerge from a very shaky beta project into a first class piece of software over the last couple of years, and am evaluating it myself for use in the print arm of Metaphorical Web Publishing once I launch that later this year. I'm more excited for its potential use in schools however - currently layout is accomplished in academic versions of MS Word, which while powerful as a word processor, has some significant limitations as a decent layout tool. With free, open source desktop publishing available to students, you will see an entire generation of kids who will be capable of laying out their own books and magazines -- coupled with inexpensive binding tools and JIT printers, and you see the foundation of a desktop publishing revolution that will make the 1980s look like a hiccup. (Thanks to Michael Bolger at svgx.org for this).
Orbeon Releases Orbeon Presentation Server Under GPL
Business software company Orbeon has released the Orbeon Presentation Server under the GNU Public License today. Similar to Apache's Cocoon, The OPS is a publishing system meant to tie into a business process manager, and as such it incorporates such technologies as XForms and its own internal XML Pipeline Language (XPL) . This one is definitely worth watching closely, as it may be the first real test of XForms as part of an overall high-powered integrated business system. (Thanks to Micah Dubinko for this)
W3C XML Binary Packaging Candidate Recommendation Released
XML has long had a blind spot - transporting content that isn't in XML format, such as images, sounds, or similar binary resources. They typical solution, the use of Base-64 encoding, has proved to be awkward at best, as it requires both an encoding and decoding step that can have a serious impact upon efficiency. The W3C XML-binary Optimized Packaging Recommendation, announced this week as having gone into Candidate Recommendation, provides a set of standards to permit the use of pure octet data rather than base-64 using MIME headers. With such standardization in place, this raises the possibility of creating XML parsers (and XSLT processors) that are capable of working with these binary bundles in a consistent fashion, making it easier to send a bundle of XML content and resource as a single stream of information.
If you have a product announcement you'd like to make to this blog or just see something that you think needs to be highlighted in the XML space, please send an email to me at kurt@kurtcagle.net.
August 31, 2004
August 29, 2004
Open Standarization vs. Market-Driven Innovation
A comment sent to my last blog posting has started me thinking about one of the more troublesome questions about the current state of the programming world. At what point does standardization (especially non-proprietary standardization) become more (or less) important than market-driven innovation.
To be on the safe side, let me define my terms. Market-driven innovation is essentially pushing to "completion" an api or architecture for the purpose of upgrading or innovating some kind of application, be it a paint program, a game, or an operating system. It is market-driven in that the API must be published at the same time as the application itself for users and third-party developers to make use of this API. For example, WinFX, the API for Longhorn, is very much tied into that architecture. In as much as the product (Longhorn) offers new functionality via an expanded (and perhaps improved) set of interfaces, these APIs essentially act as de facto standards.
Open standards, on the other hand, are generated (more or less) transparently, are not specifically tied into a product release, and (somewhat secondarily to this discussion) do not have license fees associated with them. Instead of describing what is (as a market-oriented API would do) such standards all too typically set benchmarks that must be met in order for a given implementation to be considered compliant to the standard. Thus, these standards serve as a goal, rather than a fiat description.
I'm aiming this particular discussion at the W3C, though other standards bodies are implied in the same arguments. One of the most frequently heard comments I hear about the W3C Recommendation process is that it is too slow. Certainly by the standards of commercial software vendors (such as Microsoft) it is. Take the SVG standard as an example. In early 1999, there was a fair amount of discussion about forming a W3C committee for the express purpose of building a language for graphical description of vector content, leading to the formation of the SVG group after two proposals (PGML and VML) had been offered up by Adobe and Microsoft/Macromedia respectively. The language was formalized in 2000, along with the release of one reference implementation - Adobe's SVG Viewer. Four years later, there are still critical things that are going into the standard (text flow, multimedia support and XML file import/export capabilities, among other things), and the notion of interactive SVG has effectively been offsourced into the XBL initiative.
Four years ago, .NET was still an interesting marketing idea, we were all still trying to get the taste of Windows ME out of our mouths, and Linux was still a geek platform, though there were signs of respectibility. On Internet time, four years is practically a whole generation. So why have these guys been moving at a snail's pace?
Or have they? The Law of Three seems to be an extraordinarily common pattern within program, and it can be roughly summarized as:
A software application can only be considered finished when it has gone through it's third release.
There are actually any number of perfectly good reasons for this. A few:
An open standard is not a product. Rather, it is a meta-product ... it is a description of the realistic expected behavior of an application that provides the greatest degree of compatibility with other applications while simultaneously providing the greatest degree of performance for any given implementation. It is a politicial document as much as a technological one, because the all of the primary players in the field must agree upon that point where compatibility vs. performance must lay. Politics moves slowly, especially in the business world, because of the realization on the part of all of the participants that they are ceding competitive advantages in the technology by participating in the standard process in the first place. Thus sometimes the most trivial points become major roadblocks, and deep level architecture can prove excruciatingly painful.
Yet, if you look around today, you may notice that SVG has quietly crept into just about every major graphics application on the planet, from Macromedia Flash and Adobe Acrobat to Microsoft's Visio. It's even beginning to show up in marketing literature and bullet points. Yet this is not because Adobe or Macromedia or Microsoft doesn't believe wholeheartedly that their home-grown solutions are far and away superior to SVG. Instead, its the fear that all of a sudden, their competitors have started to incorporate SVG, the market is beginning to clamour for it, and if they don't have that particular bullet point, they'll lose market share to the ones that day.
In that respect, Open Standard solutions are "Dark Horse" candidates, nowhere near as flashy as what each company produces in-house yet the best compromise for interchange and keeping the competitor from seizing that market advantage. This means that the "biggies" in any given field will be at best lukewarm to such standards, but they are also very much aware that there is a whole crop of new kids on the block that may very well hit the turning point and eclipse them all. Those new kids, on the other hand, not having any advantage in building yet another in-house standard, are perfectly happy to take a pre-existing standard and build the best shell for it, because much of that initial expensive design process is effectively done for free for them.
I think this is one of the reasons I am so ambivalent about companies that are deciding to jump to XAML and build XAML processors while Microsoft is still trying to get their act together with Longhorn. XAML is cool -- I've worked with a couple of different iterations of it, and while I have some quibbles about the somewhat monolithic nature of the schema I have to admit that there are some very smart minds there playing with the lower level architectures. It was a good design choice (especially if they get away from the requirement of needing to pre-compile it, security be-damned) , and it may very well prove the salvation of Microsoft as their product market otherwise decays.
However, all of those companies that are jumping onto the XAML bandwagon are placing themselves at the mercy of Microsoft, and once Longhorn is released, "XAML compatible" is going to be very much suspect. Such companies may be able to play the role of Borland and maintain such alternative interpreters (as Borland did with their OWL libraries back in the eraly 1990s) but most customers who want XAML viewer/interpreters are going to want Microsoft's version, if only because all it will take is one republishing statement for Microsoft to effectively render all other versions of XAML obsolete and unrunnable. Don't think they'd do it? They'd be foolish not too. Five letters ... DRDOS.
SVG and other XML standards (such as XForms) are going to have setbacks, are going to undergo multiple revisions in the face of user pressure, and are going to emerge stronger for it. Once SVG 1.2 is published, I suspect that it will be the last word on SVG proper, though binding architectures through XBL will take a couple of more years to happen. The next version of SVG (1.3 or 2.0) will be the logical jump from the 2D space to the 3D one, and it will likely involve a collision between two open standards groups that will push the completion of that process well into the 2006 time frame (just in time for Longhorn). More on that struggle lately.
However, the point I'm trying to make here is that I can reliably count on being able to use SVG 1.2 ten years from now with little or no modification, providing a great deal of stabilization that's necessary to move to the next level of abstraction on the web. Is anyone willing to bet me that XAML files generated today can still run 25 years from now the same way? That's what taking your time with the political processes involved in Open Standardization buys you, stability upon which to build the next layer of abstraction.
I welcome other people's comments on this thread here at http://metaphoricalweb.blogspot.com. I've deliberately stacked the deck here in favor or the Open Standards side, and if you feel strongly about the disadvantages of the Open Standards process compared to Close Standards (or just feel I'm full of it) feel free to let me know.
To be on the safe side, let me define my terms. Market-driven innovation is essentially pushing to "completion" an api or architecture for the purpose of upgrading or innovating some kind of application, be it a paint program, a game, or an operating system. It is market-driven in that the API must be published at the same time as the application itself for users and third-party developers to make use of this API. For example, WinFX, the API for Longhorn, is very much tied into that architecture. In as much as the product (Longhorn) offers new functionality via an expanded (and perhaps improved) set of interfaces, these APIs essentially act as de facto standards.
Open standards, on the other hand, are generated (more or less) transparently, are not specifically tied into a product release, and (somewhat secondarily to this discussion) do not have license fees associated with them. Instead of describing what is (as a market-oriented API would do) such standards all too typically set benchmarks that must be met in order for a given implementation to be considered compliant to the standard. Thus, these standards serve as a goal, rather than a fiat description.
I'm aiming this particular discussion at the W3C, though other standards bodies are implied in the same arguments. One of the most frequently heard comments I hear about the W3C Recommendation process is that it is too slow. Certainly by the standards of commercial software vendors (such as Microsoft) it is. Take the SVG standard as an example. In early 1999, there was a fair amount of discussion about forming a W3C committee for the express purpose of building a language for graphical description of vector content, leading to the formation of the SVG group after two proposals (PGML and VML) had been offered up by Adobe and Microsoft/Macromedia respectively. The language was formalized in 2000, along with the release of one reference implementation - Adobe's SVG Viewer. Four years later, there are still critical things that are going into the standard (text flow, multimedia support and XML file import/export capabilities, among other things), and the notion of interactive SVG has effectively been offsourced into the XBL initiative.
Four years ago, .NET was still an interesting marketing idea, we were all still trying to get the taste of Windows ME out of our mouths, and Linux was still a geek platform, though there were signs of respectibility. On Internet time, four years is practically a whole generation. So why have these guys been moving at a snail's pace?
Or have they? The Law of Three seems to be an extraordinarily common pattern within program, and it can be roughly summarized as:
A software application can only be considered finished when it has gone through it's third release.
There are actually any number of perfectly good reasons for this. A few:
- The first version of a product is its conceptualization, the second is its working prototype, the third is its final proof.
- The first version tells customers what's possible, the second tells the developers what the customers want, and the third is where the two meet in compromise.
- No standard exists by itself, it takes a while (and a couple different prototypes) before all of the potential interactions come to light.
An open standard is not a product. Rather, it is a meta-product ... it is a description of the realistic expected behavior of an application that provides the greatest degree of compatibility with other applications while simultaneously providing the greatest degree of performance for any given implementation. It is a politicial document as much as a technological one, because the all of the primary players in the field must agree upon that point where compatibility vs. performance must lay. Politics moves slowly, especially in the business world, because of the realization on the part of all of the participants that they are ceding competitive advantages in the technology by participating in the standard process in the first place. Thus sometimes the most trivial points become major roadblocks, and deep level architecture can prove excruciatingly painful.
Yet, if you look around today, you may notice that SVG has quietly crept into just about every major graphics application on the planet, from Macromedia Flash and Adobe Acrobat to Microsoft's Visio. It's even beginning to show up in marketing literature and bullet points. Yet this is not because Adobe or Macromedia or Microsoft doesn't believe wholeheartedly that their home-grown solutions are far and away superior to SVG. Instead, its the fear that all of a sudden, their competitors have started to incorporate SVG, the market is beginning to clamour for it, and if they don't have that particular bullet point, they'll lose market share to the ones that day.
In that respect, Open Standard solutions are "Dark Horse" candidates, nowhere near as flashy as what each company produces in-house yet the best compromise for interchange and keeping the competitor from seizing that market advantage. This means that the "biggies" in any given field will be at best lukewarm to such standards, but they are also very much aware that there is a whole crop of new kids on the block that may very well hit the turning point and eclipse them all. Those new kids, on the other hand, not having any advantage in building yet another in-house standard, are perfectly happy to take a pre-existing standard and build the best shell for it, because much of that initial expensive design process is effectively done for free for them.
I think this is one of the reasons I am so ambivalent about companies that are deciding to jump to XAML and build XAML processors while Microsoft is still trying to get their act together with Longhorn. XAML is cool -- I've worked with a couple of different iterations of it, and while I have some quibbles about the somewhat monolithic nature of the schema I have to admit that there are some very smart minds there playing with the lower level architectures. It was a good design choice (especially if they get away from the requirement of needing to pre-compile it, security be-damned) , and it may very well prove the salvation of Microsoft as their product market otherwise decays.
However, all of those companies that are jumping onto the XAML bandwagon are placing themselves at the mercy of Microsoft, and once Longhorn is released, "XAML compatible" is going to be very much suspect. Such companies may be able to play the role of Borland and maintain such alternative interpreters (as Borland did with their OWL libraries back in the eraly 1990s) but most customers who want XAML viewer/interpreters are going to want Microsoft's version, if only because all it will take is one republishing statement for Microsoft to effectively render all other versions of XAML obsolete and unrunnable. Don't think they'd do it? They'd be foolish not too. Five letters ... DRDOS.
SVG and other XML standards (such as XForms) are going to have setbacks, are going to undergo multiple revisions in the face of user pressure, and are going to emerge stronger for it. Once SVG 1.2 is published, I suspect that it will be the last word on SVG proper, though binding architectures through XBL will take a couple of more years to happen. The next version of SVG (1.3 or 2.0) will be the logical jump from the 2D space to the 3D one, and it will likely involve a collision between two open standards groups that will push the completion of that process well into the 2006 time frame (just in time for Longhorn). More on that struggle lately.
However, the point I'm trying to make here is that I can reliably count on being able to use SVG 1.2 ten years from now with little or no modification, providing a great deal of stabilization that's necessary to move to the next level of abstraction on the web. Is anyone willing to bet me that XAML files generated today can still run 25 years from now the same way? That's what taking your time with the political processes involved in Open Standardization buys you, stability upon which to build the next layer of abstraction.
I welcome other people's comments on this thread here at http://metaphoricalweb.blogspot.com. I've deliberately stacked the deck here in favor or the Open Standards side, and if you feel strongly about the disadvantages of the Open Standards process compared to Close Standards (or just feel I'm full of it) feel free to let me know.
August 28, 2004
The Contender
[Archived Blog Posts (and a chance to comment on posts) can be found at http://www.metaphoricalweb.com/.]
Perhaps it has been because I've been out of the loop for a bit, but I've discovered a curious thing lately. Internet Explorer is getting, well ... old, and maybe more than a little decrepit. Kind of like what happens when a large and stately mansion which hasn't been occupied for a while begins to gray, with windows broken here and there, the lush gardens turned weed-strewn and seedy. It slips away from being the palace on the hill to being a high class fixer-upper for someone with more money than sense.
This observation was brought to my attention because I was in the process of putting together a web-based XML editor for a client. I took it as axiomatic that if you wanted to do anything beyond displaying web pages, the only real choice out there was Internet Explorer. Yet after an unfortunate encounter with a virus from a spoofed zip file (actually a PIF ... is there any reason whatsoever why we still need PIFs for anything?) sent from the virused computer of a student of mine, my Internet Explorer didn't work quite right anymore. I couldn't get it to open up new window instances. That was great for pop-ups, admittedly, until I realized that the pop-ups were showing up in memory (with all that nasty viral Javascript code still working its malicious mischief), the windows were just not being displayed.
Before I knew it, something was sitting there on my socket queue, ruining the ability to serve anything complex (even JPEG images would only download to 50% before freezing). Then I tried to REMOVE Internet Explorer. Did you know that you can remove Mozilla, Netscape, Opera, just about every web browser out there ... except for the one that ships with Microsoft. What you get when you attempt to remove it through the "accepted" channels is a sort of Ur browser that's still there, accessible every time you type in a URL from a folder window.
After this, I attempted to reinstall IE, only to be informed that I couldn't install anything on top of the current version, which was apparently internally listed as being several dozen generations in the future. In the end, I spent a day backing up everything from my hard drive, reformatted and installed the latest version of Windows, vowing to be very circumspect around Internet Explorer.
One of my current business clients has a Content Management System that was built, periodically, by people with different visions and different levels of skill, and while it is serviceable enough, it has become a nightmare to maintain. Consequently, I was brought in to re-engineer it. CMS systems are simple in design and maddeningly complex in execution, but they represent a good area for XML people to tackle at least once in their career. One thing I decided to do with it was to revamp the editor and make it more useful for actually working with the markup language that they used. I could have used a stand-alone client, but given the variety of platforms that users were deployed to, I decided to go the web browser route.
My goal was to produce a user interface that has basic similarities to my current favorite XML editor, Oxygen (http://www.oxygenxml.com/). I had first encounted Oxygen when I was playing around with Eclipse, and soon became enamored of it. You can easily assign schemas or DTDs to XML to get full intellisense functionality, you could customize the XSLT engine so that it could easily use third party tools such as Saxon (something that was VERY useful for working with XSLT 2.0), it has a first-class debugger, and it is quite reasonably priced ($79, last I checked). Moreover, it integrates cleanly with Oxygen, and is the first XML tool of any quality that works as well in Linux as it does in Windows.
With that as a model, I set about to create similar function in a browser. My client came back to me approving the design, with the caveat that about a dozen of his writers who would be using the system were using Macintosh laptops, and could I make sure that it would work for them. That complicated the picture a bit. When it was introduced, Internet Explorer for the Macintosh was one of the best browsers out there ... in 1997. Seven years later, its not even close, and most of the functionality that I wanted to have - client side XSLT, web service request pipes, and so forth, didn't even exist there.
Safari, for the Macintosh, is becoming a first class browser, but its still very much a work in progress, with the necessary features for complex application development still at least months if not years in the future. Thus, I started doing some web searching, and noticed a curious thing. Every time I looked for a particular feature on non-IE browsers, onebrowse kept popping up. CSS 2.0 and partial 3.0 compliance, XmlHttpRequest, XSLT, XPath, nodal replacement, DOM support ... ubiquity of platform ... full support for PNGs ... text range support ... hmmmmmmmmm ...
Suppose that you had once been a major player, then you got clobbered by the new kid on the block, forced to watch as everything you'd built up got picked over by creditors until you had wandered into the bad part of town as a ghostlyhas-been. A bottle in one hand, you were on the verge of drinking yourself into oblivion when a kid comes along with his friends, stares at you, and says "You were somebody once, weren't you?"
They help you back onto your feet, get you sobered up and you learn to play by a new set of rules, until the day that you walk back into the stadium owned by that once-New Kid and say "Payback time."
Not Your Father's Mozilla
So it's the the plotline of any number of schmaltzy movies. This could still very well serve as the story of Mozilla, and its younger sibling Firefox. AOL, temporarily bloated with Internet bubble money, managed to buy up media giant Time Warner, and after that picked up the ailing Netscape, pummelled by Microsoft in the browser wars. AOL/Time Warner then preceded to effectively abandon the Netscape browser, firing most of the Netscape Navigator team and then releasing it to what was no dout conceived as oblivion - a team of largely unsupported open source geeks, who were willing to work on it in their spare time.
Picked up from the gutter, the underlying, eight year old Mozilla engine was effectively stripped to the ground and rebuilt, piece by piece, utilizing concepts that had evolved considerably since the first Navigator browser was created. The new engine cleaved closely to the W3C CSS and DOM specifications, though there are some minor distinctions in some of the XML technology that reflect the Microsoft model (including the inclusion of the XMLHttpRequest object, one of the most significant additions to the browser in a long while and one becoming pretty much standard in other browsers as well to the extent that the W3C will likely change the W3C DOM 3.0 specification to reflect this. The rendering model is fast, solid, and modular enough to handle any likely changes to the Recommendations.
More recently, the development from Gecko has split into two forks - the Mozilla 1.7 browser retains much of the characteristics of older Mozilla browsers, and it contains expanded developer functionality -- it is essentially a developer's toolkit. Firefox, on the other hand, is the future of Gecko - lighter-weight, fast, built for XML and for a wide consumer audience. It is in fact the browser that I chose to use for developing the content management system.
Efforts to support SVG are underway, and IBM and Novell have announced that they plan to roll their comprehensive XForms engine technology into the Mozilla code base. This would make Mozilla the first stand-alone browser to support the W3C XForms 1.0 Recommendation, although there are numerous XForms instances of varying degrees of conformance available, including Mozquito DENG, x-port Forms Player, Orbeon Open XML Framework, and the Mobiform SVGView Plus (thanks to Micah Dubinko and his summary page of XForm viewers for this information)..
In many ways, Mozilla 1.7 in particular can be thought of as the antithesis of Internet Explorer in that it attempts to conform as closely as possible to open standards. In addition to the high degree of W3C DOM 2.0 (and 3.0) support and CSS support, it also utilizes the most recent versions of ECMAScript/Javascript through the SpiderMonkey implementation. This in turn means that Mozilla developers can utilize many of the more significant Javascript capabilities, including the Setter/Getter functionality. For instance, you can now do something like this:
Listing 1. The use of Setter/Getter in Javascript (Figure 1)
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script language="Javascript">//<![CDATA[
Object.prototype.data getter = function(){
return parseInt(this.innerHTML);
}
Object.prototype.data setter = function(n) {
if (n >0 && n <= 100){
// empty the element of any previous data.
while (this.childNodes.length){
this.removeChild(this.firstChild);
}
// create a text node with the new value
var newNode=document.createTextNode(String(Math.round(n)));
// and insert it into the reference element:
this.appendChild(newNode);
// return the value as well as a matter of course:
return n;
}
else {
// this throws an exception which an exception handler can catch
throw "Error: Number out of range";
}
}
function increment(value){
if (value == null){value=1;}
var numberHolder=document.getElementById('numberHolder');
// This shows the power of getters and setters
numberHolder.data = numberHolder.data + value;
// This is equivalent:
// numberHolder.data += value;
}
//]]></script>
</head>
<body>
<h1>Setter/Getter</h1>
<p>Click on the plus button to increment by one, the minus button to decrement by one</p>
<div id="numberHolder" style="font-weight:bold;font-size:18pt;background-color:lightBlue;border:inset 3px lightBlue;width:30pt;">95</div>
<input type="button" onclick="increment()" value="+"/>
<input type="button" onclick="increment(-1)" value="-"/>
</body>
</html>
Figure 1. The use of Setter/Getter in Javascript
The setter/getter functionality makes it possible to add "property" interfaces to HTML and Javascript objects so that you interactive with the objects (such as the numberHolder <div> element in Listing 1) by setting or reading those properties. Thus, adding 4 to the numberHolder object becomes as simple as saying:
beyond 99, an exception will be raised.
As someone who has worked extensively with Microsoft Behaviors and the sometimes byzantine XML necessary to make them work, the simplicity of getters/setters, combined with prototyping comes as something of a relief.
Mozilla and Firefox are realistically the first true XML-centric browsers. You can view XML as structured (and collapsible) XML trees, though it will also recognize XHTML namespaces, and PI assigned CSS and XSLT stylesheets work fine with XML content.. Work on SVG is proceeding, though it has not yet been folded into the main development fork, and as mentioned previously, XForms support, much more comprehensive XLink and XPointer support exist as well.
>From an application development standpoint, however, it is the other natively supported XML objects that offer such a tantalizing glimpse into the bounds of an XML oriented browser. These are given in Table 1:
Unlike with Microsoft Internet Explorer, these objects are native within the brower, rather than being invoked as ActiveXObjects, so they participate much more fully in the security model of the browser itself. Moreover, they work across Windows, Linux, Unix and the Macintosh, whereas most of the ActiveX-based components are largely confined to Windows. This flexibility makes developing cross platform browser applications much easier.
The XMLDocument object isn't invoked directly, but comes from the document.implementation interface. While this marks a little bit of difference from the IE implementation, it is also something that can effectively be masked with some decent Javascript functions. For instance, the Internet Explorer XML DOM functions xml(), which serializes output to string, and loadXML(), which loads a string representation of an XML file into the dom, can be loaded into such an object (as shown in Listing 2)
Listing 2. DOMExtensionUtils.xml
// Defines XmlDocument.xml as the serialization mechanism
Document.prototype.__defineGetter__("xml",function(){
return (new XMLSerializer()).serializeToString(this);
}
)
// Loads an XML document from a text string
Document.prototype.loadXML = function(s){
var doc2 = (new DOMParser()).parseFromString(s,"text/xml");
while (this.hasChildNodes()){
this.removeChild(this.lastChild);
}
for (var i=0;i != doc2.childNodes.length;i++){
this.appendChild(this.importNode(doc2.childNodes[i],true));
}
}
You can then use the same functions with IE and Mozilla. Assume that you have a <div> element entitled "message", then you could actually load a message into XML and from there generate content:
var xmlDoc = document.implementation.createDocument("","",null);
xmlDoc.loadXML("<h1>A Message</h1><p>This is a message!</p>");
messageDisplay.innerHTML = xmlDoc.xml;
That example is trivial, of course, but illustrates how you could create effective XML services. A more comprehensive situation, though, would be a scenario where you had an XML document on a server containing various messages given by identifying key. As an example of this, consider the errorMessages.xml file (listing 3)::
Listing 3. errorMessage.xml
<messages>
<message code="1000">No information is currently known about this transaction.</message>
<message code="1001">Package appears to be corrupt.</message>
<message code="1002">Package manifest has bad pointer.</message>
<message code="1003">Package date exceeds limit.</message>
</messages>
When a given error condition occurs (here contained in the code attribute), then the appropriate message should be displayed in an error display box on the web page, as shown in Listing 4.
Listing 4. errorMessageXMLText.htm
<html>
<head>
<title>Example II - Error Messages</title>
<script type="text/Javascript">
var messageDisplay=null;
var messageData = document.implementation.createDocument("","",null);
function init(){
// Create a request pipeline to the server
messageDisplay = document.getElementById("messageDisplay");
var pipe=new XMLHttpRequest();
// Retrieve the messagesDocument via a synchronous (false) GET query
pipe.open("GET","errorMessages.xml",false);
pipe.send(null);
// Load the resultant text into the messageData XML "Data Island"
messageData.loadXML(pipe.responseText);
}
function displayMessage(id){
xpath = "messages/message[string(@code) = '"+id+"']/text()";
var res = messageData.evaluate(xpath, messageData, null, 0,null);
node = res.iterateNext();
if (node !=null){
messageDisplay.text = node.nodeValue;
}
}
// Defines XmlDocument.xml as the serialization mechanism
Document.prototype.__defineGetter__("xml",function(){
return (new XMLSerializer()).serializeToString(this);
}
)
// Loads an XML document from a text string
Document.prototype.loadXML = function(s){
var doc2 = (new DOMParser()).parseFromString(s,"text/xml");
while (this.hasChildNodes()){
this.removeChild(this.lastChild);
}
for (var i=0;i != doc2.childNodes.length;i++){
this.appendChild(this.importNode(doc2.childNodes[i],true));
}
}
Object.prototype.text setter = function(str){
while(this.firstChild){
this.removeChild(this.firstChild);
}
var textNode=document.createTextNode(str);
this.appendChild(textNode);
}
Object.prototype.text getter = function(){
return this.firstChild.nodeValue;
}
</script>
</head>
<body onload="init()">
<h1>XML Based Error Messages</h1>
<p>Select an error code to see its corresponding error message</p>
<select id="errorCodeSelector" onchange="displayMessage(this.value)">
<optgroup label="Choose an Error Code">
<option value="1000">Error Code 1000</option>
<option value="1001">Error Code 1001</option>
<option value="1002">Error Code 1002</option>
<option value="1003">Error Code 1003</option>
</optgroup>
</select>
<div><b>Error: </b><span id="messageDisplay"/></div>
</body>
</html>
Listing 4 provides a look at most of the XML based functions (with the exception of XSL Transformations) . Note that there are alternative approaches to many of these functions (such as the use of the load() method instead of the XMLHttpRequest object, but this at least illustrates the general usage of most of the basics.
The code fragment
var pipe=new XMLHttpRequest();
// Retrieve the messagesDocument via a synchronous (false) GET query
pipe.open("GET","errorMessages.xml",false);
pipe.send(null);
// Load the resultant text into the messageData XML "Data Island"
messageData.loadXML(pipe.responseText);
demonstrates the use of the XMLHttpRequest() component, which mirrors most of the same functionality as the Internet Explorer component of the same name. A connection is created with the server address given, using http GET, POST, PUT or similar http commands. By specifying whether you want the connection to be asynchronous (true) or synchronous (false) you can determine how you want to handle the incoming stream of information. The data once retrieved is contained in the responseText property, whichi in this case is reparsed into XML in the messageData variable. This is particularly useful for creating the equivalent of remote data islands within Mozilla or Firefox (creating local data islands will be covered in a subsequent blog).
The evaluate() function serves the same purpose as the selectNodes() and selectNode() function in Internet Explorer - a way to run an XPath expression on an XML document and retrieve the results. This function specifically implements the W3C DOM 3 XPath Interfaces, interfaces which can be confusing without some kind of reference. The evaluate() function itself takes five arguments:
xpath = "messages/message[string(@code) = '"+id+"']/text()";
var res = messageData.evaluate(xpath, messageData, null, 0,null);
with the first containing the XPath expression as a string, the second containing the context node where the XPath expression is evaluated (here the root node of the document), the third a namespace resolver for processing namespaces beyond the default (this will usually be null). The fourth parameter is a constant that can be used to indicate what kind of results should come from the expression, and again should usually be 0 (I'll be covering this more in subsequent blogs). The last parameter contains the variable that should receive the result - if set to null, then the output will be sent to the resulting value from the function. This last is typically used for internal processing with C++, not with Javascript, and consequently should almost invariably be sent to null.
The results of such an XPath expression will usually be an unorderd node set, accessed via the iterateNext() function, where each successive call will return an XML Node:
node = res.iterateNext();
if (node !=null){
messageDisplay.text = node.nodeValue;
}
If multiple nodes had been returned from the query, this could have been replaced with:
while(node = res.iterateNext()!=null)
messageDisplay.text = node.nodeValue;
}
which would have walked through each node in turn.
By making this functionality easily accessible from the DOM, both Mozilla and Firefox open up a number of possibilities for multiplatform web development that was once the exclusive domain of IE on Windows. At the very minimum an interface can be set up that will let you emulate the functionality of IE (though this is also something of a downstep at this stage). If you are working with an intranet, the possibilities that Mozilla and Firefox offer for application development improve dramatically, because you don't have to spend as much time working on backword-compatible code. Given the speed and performance of both of these browsers, I suspect the Fox is likely to give Redmond a serious run for it's money.
I'll be coming back to this topic periodically, in part to discuss the XSLT side of things in greater detail and in part to look at other aspects of the "XML browser" such as intrinsic web services support. As per usually, feel free to use any code that is contained within these blogs, though I would mailto:kurt@kurtcagle.net to let me know how you're using it. Until the next blog, enjoy and keep coding.
Perhaps it has been because I've been out of the loop for a bit, but I've discovered a curious thing lately. Internet Explorer is getting, well ... old, and maybe more than a little decrepit. Kind of like what happens when a large and stately mansion which hasn't been occupied for a while begins to gray, with windows broken here and there, the lush gardens turned weed-strewn and seedy. It slips away from being the palace on the hill to being a high class fixer-upper for someone with more money than sense.
This observation was brought to my attention because I was in the process of putting together a web-based XML editor for a client. I took it as axiomatic that if you wanted to do anything beyond displaying web pages, the only real choice out there was Internet Explorer. Yet after an unfortunate encounter with a virus from a spoofed zip file (actually a PIF ... is there any reason whatsoever why we still need PIFs for anything?) sent from the virused computer of a student of mine, my Internet Explorer didn't work quite right anymore. I couldn't get it to open up new window instances. That was great for pop-ups, admittedly, until I realized that the pop-ups were showing up in memory (with all that nasty viral Javascript code still working its malicious mischief), the windows were just not being displayed.
Before I knew it, something was sitting there on my socket queue, ruining the ability to serve anything complex (even JPEG images would only download to 50% before freezing). Then I tried to REMOVE Internet Explorer. Did you know that you can remove Mozilla, Netscape, Opera, just about every web browser out there ... except for the one that ships with Microsoft. What you get when you attempt to remove it through the "accepted" channels is a sort of Ur browser that's still there, accessible every time you type in a URL from a folder window.
After this, I attempted to reinstall IE, only to be informed that I couldn't install anything on top of the current version, which was apparently internally listed as being several dozen generations in the future. In the end, I spent a day backing up everything from my hard drive, reformatted and installed the latest version of Windows, vowing to be very circumspect around Internet Explorer.
One of my current business clients has a Content Management System that was built, periodically, by people with different visions and different levels of skill, and while it is serviceable enough, it has become a nightmare to maintain. Consequently, I was brought in to re-engineer it. CMS systems are simple in design and maddeningly complex in execution, but they represent a good area for XML people to tackle at least once in their career. One thing I decided to do with it was to revamp the editor and make it more useful for actually working with the markup language that they used. I could have used a stand-alone client, but given the variety of platforms that users were deployed to, I decided to go the web browser route.
My goal was to produce a user interface that has basic similarities to my current favorite XML editor, Oxygen (http://www.oxygenxml.com/). I had first encounted Oxygen when I was playing around with Eclipse, and soon became enamored of it. You can easily assign schemas or DTDs to XML to get full intellisense functionality, you could customize the XSLT engine so that it could easily use third party tools such as Saxon (something that was VERY useful for working with XSLT 2.0), it has a first-class debugger, and it is quite reasonably priced ($79, last I checked). Moreover, it integrates cleanly with Oxygen, and is the first XML tool of any quality that works as well in Linux as it does in Windows.
With that as a model, I set about to create similar function in a browser. My client came back to me approving the design, with the caveat that about a dozen of his writers who would be using the system were using Macintosh laptops, and could I make sure that it would work for them. That complicated the picture a bit. When it was introduced, Internet Explorer for the Macintosh was one of the best browsers out there ... in 1997. Seven years later, its not even close, and most of the functionality that I wanted to have - client side XSLT, web service request pipes, and so forth, didn't even exist there.
Safari, for the Macintosh, is becoming a first class browser, but its still very much a work in progress, with the necessary features for complex application development still at least months if not years in the future. Thus, I started doing some web searching, and noticed a curious thing. Every time I looked for a particular feature on non-IE browsers, onebrowse kept popping up. CSS 2.0 and partial 3.0 compliance, XmlHttpRequest, XSLT, XPath, nodal replacement, DOM support ... ubiquity of platform ... full support for PNGs ... text range support ... hmmmmmmmmm ...
Suppose that you had once been a major player, then you got clobbered by the new kid on the block, forced to watch as everything you'd built up got picked over by creditors until you had wandered into the bad part of town as a ghostlyhas-been. A bottle in one hand, you were on the verge of drinking yourself into oblivion when a kid comes along with his friends, stares at you, and says "You were somebody once, weren't you?"
They help you back onto your feet, get you sobered up and you learn to play by a new set of rules, until the day that you walk back into the stadium owned by that once-New Kid and say "Payback time."
Not Your Father's Mozilla
So it's the the plotline of any number of schmaltzy movies. This could still very well serve as the story of Mozilla, and its younger sibling Firefox. AOL, temporarily bloated with Internet bubble money, managed to buy up media giant Time Warner, and after that picked up the ailing Netscape, pummelled by Microsoft in the browser wars. AOL/Time Warner then preceded to effectively abandon the Netscape browser, firing most of the Netscape Navigator team and then releasing it to what was no dout conceived as oblivion - a team of largely unsupported open source geeks, who were willing to work on it in their spare time.
Picked up from the gutter, the underlying, eight year old Mozilla engine was effectively stripped to the ground and rebuilt, piece by piece, utilizing concepts that had evolved considerably since the first Navigator browser was created. The new engine cleaved closely to the W3C CSS and DOM specifications, though there are some minor distinctions in some of the XML technology that reflect the Microsoft model (including the inclusion of the XMLHttpRequest object, one of the most significant additions to the browser in a long while and one becoming pretty much standard in other browsers as well to the extent that the W3C will likely change the W3C DOM 3.0 specification to reflect this. The rendering model is fast, solid, and modular enough to handle any likely changes to the Recommendations.
More recently, the development from Gecko has split into two forks - the Mozilla 1.7 browser retains much of the characteristics of older Mozilla browsers, and it contains expanded developer functionality -- it is essentially a developer's toolkit. Firefox, on the other hand, is the future of Gecko - lighter-weight, fast, built for XML and for a wide consumer audience. It is in fact the browser that I chose to use for developing the content management system.
Efforts to support SVG are underway, and IBM and Novell have announced that they plan to roll their comprehensive XForms engine technology into the Mozilla code base. This would make Mozilla the first stand-alone browser to support the W3C XForms 1.0 Recommendation, although there are numerous XForms instances of varying degrees of conformance available, including Mozquito DENG, x-port Forms Player, Orbeon Open XML Framework, and the Mobiform SVGView Plus (thanks to Micah Dubinko and his summary page of XForm viewers for this information)..
In many ways, Mozilla 1.7 in particular can be thought of as the antithesis of Internet Explorer in that it attempts to conform as closely as possible to open standards. In addition to the high degree of W3C DOM 2.0 (and 3.0) support and CSS support, it also utilizes the most recent versions of ECMAScript/Javascript through the SpiderMonkey implementation. This in turn means that Mozilla developers can utilize many of the more significant Javascript capabilities, including the Setter/Getter functionality. For instance, you can now do something like this:
Listing 1. The use of Setter/Getter in Javascript (Figure 1)
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script language="Javascript">//<![CDATA[
Object.prototype.data getter = function(){
return parseInt(this.innerHTML);
}
Object.prototype.data setter = function(n) {
if (n >0 && n <= 100){
// empty the element of any previous data.
while (this.childNodes.length){
this.removeChild(this.firstChild);
}
// create a text node with the new value
var newNode=document.createTextNode(String(Math.round(n)));
// and insert it into the reference element:
this.appendChild(newNode);
// return the value as well as a matter of course:
return n;
}
else {
// this throws an exception which an exception handler can catch
throw "Error: Number out of range";
}
}
function increment(value){
if (value == null){value=1;}
var numberHolder=document.getElementById('numberHolder');
// This shows the power of getters and setters
numberHolder.data = numberHolder.data + value;
// This is equivalent:
// numberHolder.data += value;
}
//]]></script>
</head>
<body>
<h1>Setter/Getter</h1>
<p>Click on the plus button to increment by one, the minus button to decrement by one</p>
<div id="numberHolder" style="font-weight:bold;font-size:18pt;background-color:lightBlue;border:inset 3px lightBlue;width:30pt;">95</div>
<input type="button" onclick="increment()" value="+"/>
<input type="button" onclick="increment(-1)" value="-"/>
</body>
</html>
Figure 1. The use of Setter/Getter in Javascript
The setter/getter functionality makes it possible to add "property" interfaces to HTML and Javascript objects so that you interactive with the objects (such as the numberHolder <div> element in Listing 1) by setting or reading those properties. Thus, adding 4 to the numberHolder object becomes as simple as saying:
numberHolder = numberHolder + 4;or even
numberHolder += 4;This also makes possible exception handling - if an attempt is made to set the value of the numberHolder
beyond 99, an exception will be raised.
As someone who has worked extensively with Microsoft Behaviors and the sometimes byzantine XML necessary to make them work, the simplicity of getters/setters, combined with prototyping comes as something of a relief.
Ich Spreche XML
What is a browser? Five years ago, you could reasonably say that a browser was a device to view HTML. However, in mid 2004, XML has been out for nearly seven years, and XHTML has been a standard for five of those. Yet for all of that Internet Explorer is notoriously unfriendly toward XHTML - recognizing neither the XHTML namespace nor even an XHTML prefix. It does recognize the XML stylesheet processing instructions, though PIs in general are being pushed out in favor of namespaces as the preferred way of identifying the functionality of objects. And Internet Explorer has this incredibly annoying tendency of rendering HTML output as non-XML compliant HTML, making it notoriously difficult to process without a huge amount of DOM manipulation work.Mozilla and Firefox are realistically the first true XML-centric browsers. You can view XML as structured (and collapsible) XML trees, though it will also recognize XHTML namespaces, and PI assigned CSS and XSLT stylesheets work fine with XML content.. Work on SVG is proceeding, though it has not yet been folded into the main development fork, and as mentioned previously, XForms support, much more comprehensive XLink and XPointer support exist as well.
>From an application development standpoint, however, it is the other natively supported XML objects that offer such a tantalizing glimpse into the bounds of an XML oriented browser. These are given in Table 1:
| Object name
| Description
|
| XMLDocument
| Supports the standard W3C DOM Document implementation, and can be extracted from the web page document object.
|
| XMLSerializer
| Used for converting XML DOM Documents into either a string or streamed binary serial output.
|
| DOMParser
| Converts a stream, file or stream representation of an XML document into an internal DOM Document
|
| XSLTProcessor
| Creates an XSLT object that can be used for building transformations
|
| XPath Parser
| Performs XPath queries on XML documents.
|
| Web Services
| Handles SOAP and WSDL Services
|
| XUL/XBL
| These components are useful for adding functionality into the browser itself, and are XML based.
|
Unlike with Microsoft Internet Explorer, these objects are native within the brower, rather than being invoked as ActiveXObjects, so they participate much more fully in the security model of the browser itself. Moreover, they work across Windows, Linux, Unix and the Macintosh, whereas most of the ActiveX-based components are largely confined to Windows. This flexibility makes developing cross platform browser applications much easier.
The XMLDocument object isn't invoked directly, but comes from the document.implementation interface. While this marks a little bit of difference from the IE implementation, it is also something that can effectively be masked with some decent Javascript functions. For instance, the Internet Explorer XML DOM functions xml(), which serializes output to string, and loadXML(), which loads a string representation of an XML file into the dom, can be loaded into such an object (as shown in Listing 2)
Listing 2. DOMExtensionUtils.xml
// Defines XmlDocument.xml as the serialization mechanism
Document.prototype.__defineGetter__("xml",function(){
return (new XMLSerializer()).serializeToString(this);
}
)
// Loads an XML document from a text string
Document.prototype.loadXML = function(s){
var doc2 = (new DOMParser()).parseFromString(s,"text/xml");
while (this.hasChildNodes()){
this.removeChild(this.lastChild);
}
for (var i=0;i != doc2.childNodes.length;i++){
this.appendChild(this.importNode(doc2.childNodes[i],true));
}
}
You can then use the same functions with IE and Mozilla. Assume that you have a <div> element entitled "message", then you could actually load a message into XML and from there generate content:
var xmlDoc = document.implementation.createDocument("","",null);
xmlDoc.loadXML("<h1>A Message</h1><p>This is a message!</p>");
messageDisplay.innerHTML = xmlDoc.xml;
That example is trivial, of course, but illustrates how you could create effective XML services. A more comprehensive situation, though, would be a scenario where you had an XML document on a server containing various messages given by identifying key. As an example of this, consider the errorMessages.xml file (listing 3)::
Listing 3. errorMessage.xml
<messages>
<message code="1000">No information is currently known about this transaction.</message>
<message code="1001">Package appears to be corrupt.</message>
<message code="1002">Package manifest has bad pointer.</message>
<message code="1003">Package date exceeds limit.</message>
</messages>
When a given error condition occurs (here contained in the code attribute), then the appropriate message should be displayed in an error display box on the web page, as shown in Listing 4.
Listing 4. errorMessageXMLText.htm
<html>
<head>
<title>Example II - Error Messages</title>
<script type="text/Javascript">
var messageDisplay=null;
var messageData = document.implementation.createDocument("","",null);
function init(){
// Create a request pipeline to the server
messageDisplay = document.getElementById("messageDisplay");
var pipe=new XMLHttpRequest();
// Retrieve the messagesDocument via a synchronous (false) GET query
pipe.open("GET","errorMessages.xml",false);
pipe.send(null);
// Load the resultant text into the messageData XML "Data Island"
messageData.loadXML(pipe.responseText);
}
function displayMessage(id){
xpath = "messages/message[string(@code) = '"+id+"']/text()";
var res = messageData.evaluate(xpath, messageData, null, 0,null);
node = res.iterateNext();
if (node !=null){
messageDisplay.text = node.nodeValue;
}
}
// Defines XmlDocument.xml as the serialization mechanism
Document.prototype.__defineGetter__("xml",function(){
return (new XMLSerializer()).serializeToString(this);
}
)
// Loads an XML document from a text string
Document.prototype.loadXML = function(s){
var doc2 = (new DOMParser()).parseFromString(s,"text/xml");
while (this.hasChildNodes()){
this.removeChild(this.lastChild);
}
for (var i=0;i != doc2.childNodes.length;i++){
this.appendChild(this.importNode(doc2.childNodes[i],true));
}
}
Object.prototype.text setter = function(str){
while(this.firstChild){
this.removeChild(this.firstChild);
}
var textNode=document.createTextNode(str);
this.appendChild(textNode);
}
Object.prototype.text getter = function(){
return this.firstChild.nodeValue;
}
</script>
</head>
<body onload="init()">
<h1>XML Based Error Messages</h1>
<p>Select an error code to see its corresponding error message</p>
<select id="errorCodeSelector" onchange="displayMessage(this.value)">
<optgroup label="Choose an Error Code">
<option value="1000">Error Code 1000</option>
<option value="1001">Error Code 1001</option>
<option value="1002">Error Code 1002</option>
<option value="1003">Error Code 1003</option>
</optgroup>
</select>
<div><b>Error: </b><span id="messageDisplay"/></div>
</body>
</html>
Listing 4 provides a look at most of the XML based functions (with the exception of XSL Transformations) . Note that there are alternative approaches to many of these functions (such as the use of the load() method instead of the XMLHttpRequest object, but this at least illustrates the general usage of most of the basics.
The code fragment
var pipe=new XMLHttpRequest();
// Retrieve the messagesDocument via a synchronous (false) GET query
pipe.open("GET","errorMessages.xml",false);
pipe.send(null);
// Load the resultant text into the messageData XML "Data Island"
messageData.loadXML(pipe.responseText);
demonstrates the use of the XMLHttpRequest() component, which mirrors most of the same functionality as the Internet Explorer component of the same name. A connection is created with the server address given, using http GET, POST, PUT or similar http commands. By specifying whether you want the connection to be asynchronous (true) or synchronous (false) you can determine how you want to handle the incoming stream of information. The data once retrieved is contained in the responseText property, whichi in this case is reparsed into XML in the messageData variable. This is particularly useful for creating the equivalent of remote data islands within Mozilla or Firefox (creating local data islands will be covered in a subsequent blog).
The evaluate() function serves the same purpose as the selectNodes() and selectNode() function in Internet Explorer - a way to run an XPath expression on an XML document and retrieve the results. This function specifically implements the W3C DOM 3 XPath Interfaces, interfaces which can be confusing without some kind of reference. The evaluate() function itself takes five arguments:
xpath = "messages/message[string(@code) = '"+id+"']/text()";
var res = messageData.evaluate(xpath, messageData, null, 0,null);
with the first containing the XPath expression as a string, the second containing the context node where the XPath expression is evaluated (here the root node of the document), the third a namespace resolver for processing namespaces beyond the default (this will usually be null). The fourth parameter is a constant that can be used to indicate what kind of results should come from the expression, and again should usually be 0 (I'll be covering this more in subsequent blogs). The last parameter contains the variable that should receive the result - if set to null, then the output will be sent to the resulting value from the function. This last is typically used for internal processing with C++, not with Javascript, and consequently should almost invariably be sent to null.
The results of such an XPath expression will usually be an unorderd node set, accessed via the iterateNext() function, where each successive call will return an XML Node:
node = res.iterateNext();
if (node !=null){
messageDisplay.text = node.nodeValue;
}
If multiple nodes had been returned from the query, this could have been replaced with:
while(node = res.iterateNext()!=null)
messageDisplay.text = node.nodeValue;
}
which would have walked through each node in turn.
The Power of the Fox
By making this functionality easily accessible from the DOM, both Mozilla and Firefox open up a number of possibilities for multiplatform web development that was once the exclusive domain of IE on Windows. At the very minimum an interface can be set up that will let you emulate the functionality of IE (though this is also something of a downstep at this stage). If you are working with an intranet, the possibilities that Mozilla and Firefox offer for application development improve dramatically, because you don't have to spend as much time working on backword-compatible code. Given the speed and performance of both of these browsers, I suspect the Fox is likely to give Redmond a serious run for it's money.
I'll be coming back to this topic periodically, in part to discuss the XSLT side of things in greater detail and in part to look at other aspects of the "XML browser" such as intrinsic web services support. As per usually, feel free to use any code that is contained within these blogs, though I would mailto:kurt@kurtcagle.net to let me know how you're using it. Until the next blog, enjoy and keep coding.
August 25, 2004
Conquering Writer's Blog
After having written books for more than a decade, a curious thing happened to me: I stopped writing without noticing it. I had been fairly reliable in getting books and articles cranked out, a book every five to six months, an article or two a month, since 1992. In 2002 I had my name on five books, two of which I'd written in their entirety. In 2003, I had two published, but that was a little deceptive ... they had both been written in 2002 and the production process slipped into 2003. By late 2003, my writing pace slowed ... I had several article I'd hoped to get to magazine publishers, but somehow, there was always something else getting in the way of getting them done.
By late 2003, I went to work for a small e-publisher (a long story that will no doubt eventually make it to press, but not now) as Chief Architect. I wrote very little, and the challenge of putting words on paper became ever more difficult for someone who had been used to slinging out several pages a day. This extended into this year until comparatively recently, perhaps a couple of months ago, when I realized that it had been more than a year since I had written an article for publication, I had pretty much left what book projects I'd had on the transom rot away, and I hadn't even added anything to the Metaphorical Web or written the long, sometimes very involved e-mail letters that I have become somewhat notorious for.
Writer's Block is one of those strange afflictions that those of us in the writing biz occasionally succumb to. I believe that most writers are not conscious in the same way that other people are; they live very much within themselves, and a great deal of brain activity actually occurs just beneath the surface of consciousness. Writing dialog is actually a pretty clear indication of that - the consciousness, the ego, of the writer is subsumed while those of the protagonists and antagonists comes to the fore. A writer often "hears" these voices and transcribes them, rather than consciously plotting what his characters will say.
This is not necessarily quite the case with technical writers, but there's a similar process of mentally building up castles in their minds that can be quite complex .... and often very fragile. It doesn't take much to cause those castles to come crashing to the earth, and the more turmoil that's in the life of a writer, the more difficult it is to perform that bit of mental levitation.
That turmoil was very much a factor of life last year, to such an extent that not only did the words not come, but the mind tricked itself into thinking that things were okay when they weren't. The brain's a sneaky little bastard when it wants to be. Writer's block creates a wall around that part of you that is charged with writing, and seeks out anything it can seize on to prevent you from expressing yourself.
The day that I made the realization that I had not published in anything for months was also the day that I wrote a three thousand word article, spontaneously, after looking at a magazine and realizing that I had the basis for an article. After that, it was like those sequences from the Weddell Ice Shelf breaking free from Antarctica, as that voice within me that had been so silent began to make itself heard again.
This blog that you're reading now is, to a great extent, a reflection of that voice beginning to reassert itself. A great number of things have taken place in the last year, some good for the areas that I cover, some not so good. I think that we're entering into the next "epoch" of computing, one in which many of the things that we assumed to be true since the mid-1980s proves not to be. I plan on covering this coming age, chronicling the events from a technology perspective, while hoping to provide as many insights into my belief that ultimately all society is software.
To those of you coming from the Metaphorical Web Yahoo Group, I will continue to maintain that site but will be doing most of my writing now on the metaphorical web blog. I am also planning on blogging from the SVG Open Conference in Japan from the 6th to the 9th, where I will be teaching classes on XSLT2, XForms, and possibly SVG publishing. If you can't make it to the conference, I hope to provide at least some insights into the precedings.
To all others, I bid you welcome, and hope that you enjoy this, the Metaphorical Web.
Kurt Cagle
By late 2003, I went to work for a small e-publisher (a long story that will no doubt eventually make it to press, but not now) as Chief Architect. I wrote very little, and the challenge of putting words on paper became ever more difficult for someone who had been used to slinging out several pages a day. This extended into this year until comparatively recently, perhaps a couple of months ago, when I realized that it had been more than a year since I had written an article for publication, I had pretty much left what book projects I'd had on the transom rot away, and I hadn't even added anything to the Metaphorical Web or written the long, sometimes very involved e-mail letters that I have become somewhat notorious for.
Writer's Block is one of those strange afflictions that those of us in the writing biz occasionally succumb to. I believe that most writers are not conscious in the same way that other people are; they live very much within themselves, and a great deal of brain activity actually occurs just beneath the surface of consciousness. Writing dialog is actually a pretty clear indication of that - the consciousness, the ego, of the writer is subsumed while those of the protagonists and antagonists comes to the fore. A writer often "hears" these voices and transcribes them, rather than consciously plotting what his characters will say.
This is not necessarily quite the case with technical writers, but there's a similar process of mentally building up castles in their minds that can be quite complex .... and often very fragile. It doesn't take much to cause those castles to come crashing to the earth, and the more turmoil that's in the life of a writer, the more difficult it is to perform that bit of mental levitation.
That turmoil was very much a factor of life last year, to such an extent that not only did the words not come, but the mind tricked itself into thinking that things were okay when they weren't. The brain's a sneaky little bastard when it wants to be. Writer's block creates a wall around that part of you that is charged with writing, and seeks out anything it can seize on to prevent you from expressing yourself.
The day that I made the realization that I had not published in anything for months was also the day that I wrote a three thousand word article, spontaneously, after looking at a magazine and realizing that I had the basis for an article. After that, it was like those sequences from the Weddell Ice Shelf breaking free from Antarctica, as that voice within me that had been so silent began to make itself heard again.
This blog that you're reading now is, to a great extent, a reflection of that voice beginning to reassert itself. A great number of things have taken place in the last year, some good for the areas that I cover, some not so good. I think that we're entering into the next "epoch" of computing, one in which many of the things that we assumed to be true since the mid-1980s proves not to be. I plan on covering this coming age, chronicling the events from a technology perspective, while hoping to provide as many insights into my belief that ultimately all society is software.
To those of you coming from the Metaphorical Web Yahoo Group, I will continue to maintain that site but will be doing most of my writing now on the metaphorical web blog. I am also planning on blogging from the SVG Open Conference in Japan from the 6th to the 9th, where I will be teaching classes on XSLT2, XForms, and possibly SVG publishing. If you can't make it to the conference, I hope to provide at least some insights into the precedings.
To all others, I bid you welcome, and hope that you enjoy this, the Metaphorical Web.
Kurt Cagle
Subscribe to:
Posts (Atom)