I saw something in the last couple of days that has been notoriously tacking in the SVG community, especially compared to this time last year ... hope. Last year, in Vancouver, the smallish crowd that showed up in a rather cavernous hotel's convention center seemed interested in what was going on, but there was something ever so slightly forlorn to the gathering. Even Adobe's announcement of the ASV 6 Beta, while generating a lot of buzz, didn't do much for the feeling that things were not moving at all, that the SVG movement would be swallowed up by Macromedia Flash.
Oh what a difference a year makes.
Measured in sheer numbers, Tokyo didn't quite reach the standards of Vancouver -- perhaps 200 people all told showed up for the four day long event. However, this was not necessarily a reflection of the weakness of the SVG community as a simple measure of the cost of getting to and attending in the very expensive Tokyo. While there were somes signs of a too-late organization (from the comparative lack of advertising about the conference to late notification of speakers to the rather circuitous peambulations on the Japanese Rail system before getting to the cruise on Wednesday night) this had as much to do with the fairly major demands placed upon the organizers of the Japanese conference (especially Jun ???, who should be applauded for doing this conference while still going to work in the evenings). The registration staff were professional and extremely courteous, and took my excruciatingly bad wit in stride.
So what things to say about the conference? This has been a kind of glass half full type of year. On the down side, SVG expertise is still probably not by itself enough to insure a company's survival, though for the first time in a while there were several such companies that seemed interested in at least trying. I spent a great deal of time talking with people from companies such as Vectoreal, helmed by SVG stalwart Ronan Oger. While work in the field is "soft", the comments that I heard indicated that it did exist, nonetheless, and for the first time I heard several company reps indicating that their companies were doing pilot studies of SVG. Given that last year, many of these same people were still trying to just educate their bosses (and themselves) about the format of the language, I suspect that as these projects come to fruition the result will be a plethora of applications, web services, and products by SVG Open 2005.
I found it interesting that many of the people in the field are working for the governments of Canada, Great Britain, the Netherlands, Germany, Spain, Norway, Japan, China, the Philipines, and Australia, among others. One particular programmer, working for the British Agricultural Service, is taking vectors to a new realm, using SVG to evaluate the vectors of livestock diseases. Not unexpectedly, the largest category of governmental work was in the area of maps and graphical information systems.
The Keynotes started off with Makoto Murata, co-creator of the RelaxNG schema language, discussing his work with developing validation resources for handling documents with multiple intertwined schemas, a problem that SVG in particular is susceptible too. The solution that he has devised (in conjunction with James Clark, the other co-creator of RelaxNG) was a new markup language called NVDL (Namespace Validation Description Language) which can be used in conjunction with an appropriate parser to extract and convert XML fragments and validate them independently. Given the rise of multiple-namespace documents in XHTML andf SVG, these standards have some great implications.
The second Tuesday keynote, by Naomi Inoue of KDDI Labs, served as a good indicator of two of the three primary themes the seemed to predominate this year - mobile SVG and mapping technology. KDDI is the developer of the goSVG browser, to be rolled out this year by Japanese Telephone giant NTT. While the applications involved - location trackers, dedicated localized services, and travel instructions - were fairly prosaic by SVG standards, at the same time, the fact that they existed at all was highly significant. NTT previously announced that they do plan on licensing Flash within their phone systems, something which caused dismay in more than a few circles, so the announcement this year that SVG is also being supported (to be rolled out in 2005) has given a boost to that technology.
Similarly, I talked for a while with Andrew Watanabe of Zoomon, a developer of embedded SVG technologies for a large number of cell phone manufacturers. He had interesting news about a new tool that Zoomon was releasing to be used with the SVG capability of Adobe Illustrator 10, cleaning up some of the namespace metadata that Adobe adds, letting developers add interactivity and animation to the otherwise largely static capabilities of Illustrator, and otherwise making SVG suitable for wireless output. I am planning on having an interview with Zoomon officers in a newsletter release later this year.
The second big story of the conference, though one not, unfortunately, accompanied by another Adobe ASV release, was the announcement of the sXBL specification. This effort brought together some of the XML Binding Language work done by the Mozilla team and the RCC specification proposed last year, an effort that pulled this particularly contentious part of SVG out of the 1.2 working draft,making it much easier to get the latter specification into Recommended status and consequently out into the development community. sXBL is fascinating, even in its present immature state, but is sufficiently complex as to warrant its own discussion.
The sXBL specification has now effectively started an arms race in framework binding languages, with the other major player being Microsoft's XAML specification. With their announcement, however, that Avalon (and consequently XAML) will be pushed to 2007 to be released with a new version of Windows XP, the XAML field has become a rather odd one of late. Phillip Mansfield, president of Schema Soft and organizer of the Vancouver connection last year, presented a compare and contrast session on XAML and SVG, highlighting work that they have done with Microsoft, while at the same time there was definitely the sentiment, expressed by more than one person, that XAML might prove to be alluring to the developers who like SVG but are stymied by the poor state of viewers or editors for it and like the multiple uses of the alternative language. Ironically, I think that Microsoft will likely end up coming into a crowded field with XAML when they do release it, as it seems to be taking a life of its own independent of the efforts of Redmond.
Curiously, however, the big worry about Flash (and Macromedia) is at a minimum, in abeyance. SVG developers in general have made the realization that Flash and SVG really ARE apples and oranges, with SVG increasingly taking up the slack in areas such as mapping, charts, information graphics, and publishing that are pretty much being ignored by Macromedia. Meanwhile, Flash doesn't seem to be making the inroads into the XML space that Macromedia's senior management had apparently hoped. This is in keeping with my own observation that indicates that the XML nature of SVG is beginning to manifest the curious viral nature of XML in general, where it takes over because of its abstract nature.
The papers that were presented this year were considerably drier and more academic than in previous years, I suspect in part because of the opportunity that this conference afforded Japanese developers (who tend to be clustered in academia, at least those working on XML technologies) a venue at home to be able to show off their theses. Most were variations on a theme - use of SVG for maps, mapping with SVG symbols, GPS applications and their integration with GIS/Cartography, that sort of thing. Yes, SVG is a godsend to the GIS crowd, but frankly I'm getting a little bit bored with the plethora of mapping applications.
Jan Klaas-Kollhof, a web developer from Germany, member of Vectoreal and an all around cool guy showed off a nice piece of distributed presentation software, something which could have some serious potential for both the educational and training markets. The best way of describing it would be as an interactive Power Point which multiple people can subscribe to, though that really doesn't do it justice. Jan also gave a very useful talk on Javascript and how modules and classes can be folded into application development. If you are a venture capitalist in Germany, you should seriously take a look at what he is doing - few enough programmers have that original-thinking creative gene, and they should be seen as rare and to be highly valued.
As with most conferences, much of the important stuff goes on outside of the presentations and papers, some of it fun, some of it quite serious. On the fun side, at least for me, came with a trip by the instructors of the Tuesday sessions after the last classes were given. I was, to be blunt, punch-drunk from exhaustion and jet-lag. I learned some important lessons about communication that night, however. Place ten people (all "Westerners") in a Japanese restaurant where none of the people speak a word of Japanese, and where none of the wait stuff could speak a word of English. Add in exotic foods (at least from the standpoint of those ten) and let the fun begin. In the end we enjoyed a five course meal with fish eggs, boiled prawns, raw fish, tofu, breaded chicken strips, and a few other entrees that I've yet to identify myself. I proceeded to fall asleep about the time for desert, and have the blackmail pictures to prove it (alas). The discussion touched on many things, not least of which being where SVG is hot and where its not. Legacy diagram (and blueprint) conversions seemed to be a real growth area for SVG, as is legacy graphic file interchange. Yes, SVG is more than a graphics format, but its worth remembering sometimes that it IS a graphics format, and as such is actually nicely set up to at least handle the conversion from other standard graphics programs.
The next night was what seems to have become the obligatory dinner cruise. The ship in question was quite nice, as was the dinner, but not surprisingly the conversation tended to turn pretty quickly to programming and standards issues, with a healthy dose of politicking thrown in for good measure. The night was further leavened by a race through the Japan Railway system, including periodic stops to get tickets. I have to admit to being very impressed with the Japanese rail system (especially the graphical kiosks which show the position of the trains, next destinations and so forth), but I would have preferred to not have to walk several miles to get to the cruise. I begin to understand why the Japanese are so fit.
There is still one day yet of the conference, including the annual "pester that W3C SVG Working Group" session which I plan to attend. if at all possible. While there's not a lot of hope on this, I'd like to see an arc element added to the mix, something along the lines of
<arc r="radiusValue" startAngle="startAngle" endAngle="endAngle"/>
It's more than past time to see this, especialy as circular arcs within SVG are incredibly difficult to do well.
Okay. More to come soon -- Kurt
September 9, 2004
September 6, 2004
Wee Morning Hours
I'm seriously jet-lagged, having done the ten hour trip from Vancouver to Tokyo (and no, I'm not unaware of the irony there) . I've had to go through immigration and customs, have learned that it does not take 1,000 Yen (about $10) to go from Tokyo station to Omiya where my hotel is (it's about $2.50, something I discovered after having used up a $10 ticket), have discovered that green tea does not do good things to laptop computer keyboards (I'm now typing on a lovely new portable keyboard with Kanji characters on the keys' faces), and am staying in the smallest hotel room I've ever been in in my life (the walk-in closet of my house is marginally bigger).
The conference starts in about four hours, I'm busily typing away on last minute stuff, and will report future progress once my two classes, on XSLT2 and XForms respectively, wrap up. I'll also be at the Stump the SVG Gurus Panel at 5:30, though given I've had maybe five hours of sleep in the last forty, it may be (for me) stump the fat Night of the Living Dead extra.
Oh, and unbeknownst to me we had a 6 Richter earthquake here in Tokyo last night. With all the train rides, I didn't notice it, but if these reports stop unexpectedly, blame the Tsunami.
The conference starts in about four hours, I'm busily typing away on last minute stuff, and will report future progress once my two classes, on XSLT2 and XForms respectively, wrap up. I'll also be at the Stump the SVG Gurus Panel at 5:30, though given I've had maybe five hours of sleep in the last forty, it may be (for me) stump the fat Night of the Living Dead extra.
Oh, and unbeknownst to me we had a 6 Richter earthquake here in Tokyo last night. With all the train rides, I didn't notice it, but if these reports stop unexpectedly, blame the Tsunami.
September 5, 2004
On My Way To Japan
It's 7:15 am at SeaTac Airport, about twenty minutes south of Seattle. My plane for Japan leaves in about an hour, after a brief layover in Vancouver. I get to ride a Mosquito hopper betwixt here and BC, one of those odd little throwbacks to the age of the prop plane that makes one think a little more favorably about the comfortable accomodations of today, even in cattle car flights. I've had about four hours of sleep (t'was dead on my feet after trying to find a decent power converter at 11 pm, dealing with two kids that were way too amped up to get to bed, and trying to get presentations done. It'll be a close call whether or not the presentation gets done before the class starts, but with luck things will fall into place.
The battles have already begun, however. Currently there is, within the sXBL group, a fairly heated discussion about whether XPath or CSS should be the default language for chosing selectors for template content. This little bit of arcana may be new to you, especially if you missed the announcement that sXBL had been released recently. For those whose W3C acronym dictionary may not be completely up to date, sXBL is the SVG specific XML Binding Language. The purpose of this particular language is to accept arbitrary XML (mostly) as input and generate through a series of templated transformations and event calls, a dynamic SVG tree. Many may know this technology under its somewhat older name RCC, part of the spec released last year at around this time, that did the same thing.
sXBL serves somewhat of the same purpose as XSLT, except that it is designed to work in an event driven environment on specific nodes rather than as a single transform against a complete XML document. This means that if some facet of the document changes (i.e., an event is received at some point in the tree) then the event will initiate transformations for the effected nodes automatically. This has a number of applications beyond SVG; it's currently used within Mozilla to perform shadow tree HTML implementations from external XML sources, for instance, and the idea of being able to create a dynamic interactive XML oriented application has applications in any ckind of modelling, simulation, gaming, or interface context. Consequently, it is likely that XBL will end up having very much the same kind of cascading effect upon the development community that XSLT did, far beyond its original focus.
The current controversy stems from the question of which selection language to use: XPath or CSS. From a data-binding orientation - which I basically see sXBL as being), XPath makes far more sense - it is designed to be able to retrieve specific nodal and subnodal properties, such as text and attributes, without requiring any Javascript or related code. This improves its portability, makes it easier to generate sXBL from external transformations, and radicaly simplifies accessing content from one schema inside of another display schema. The CSS side argues that XPath is too complex, too heavy-weight for vendors to support, and is inaccessible to beginning users. This is likely a red-herring, as sXBL is nearly as complex as XSLT, just in its own way.
The challenge of finding a good binding language is critical for this specification, as it will likely start making its way into the newly fired up development process of several browser vendors in short order. I would be interested in hearing other people with arguments on sXBL, and specifically the binding language issue, in order to try to present something at the conference.
Flights leaving soon, so I'll wrap this up.
-- Kurt
The battles have already begun, however. Currently there is, within the sXBL group, a fairly heated discussion about whether XPath or CSS should be the default language for chosing selectors for template content. This little bit of arcana may be new to you, especially if you missed the announcement that sXBL had been released recently. For those whose W3C acronym dictionary may not be completely up to date, sXBL is the SVG specific XML Binding Language. The purpose of this particular language is to accept arbitrary XML (mostly) as input and generate through a series of templated transformations and event calls, a dynamic SVG tree. Many may know this technology under its somewhat older name RCC, part of the spec released last year at around this time, that did the same thing.
sXBL serves somewhat of the same purpose as XSLT, except that it is designed to work in an event driven environment on specific nodes rather than as a single transform against a complete XML document. This means that if some facet of the document changes (i.e., an event is received at some point in the tree) then the event will initiate transformations for the effected nodes automatically. This has a number of applications beyond SVG; it's currently used within Mozilla to perform shadow tree HTML implementations from external XML sources, for instance, and the idea of being able to create a dynamic interactive XML oriented application has applications in any ckind of modelling, simulation, gaming, or interface context. Consequently, it is likely that XBL will end up having very much the same kind of cascading effect upon the development community that XSLT did, far beyond its original focus.
The current controversy stems from the question of which selection language to use: XPath or CSS. From a data-binding orientation - which I basically see sXBL as being), XPath makes far more sense - it is designed to be able to retrieve specific nodal and subnodal properties, such as text and attributes, without requiring any Javascript or related code. This improves its portability, makes it easier to generate sXBL from external transformations, and radicaly simplifies accessing content from one schema inside of another display schema. The CSS side argues that XPath is too complex, too heavy-weight for vendors to support, and is inaccessible to beginning users. This is likely a red-herring, as sXBL is nearly as complex as XSLT, just in its own way.
The challenge of finding a good binding language is critical for this specification, as it will likely start making its way into the newly fired up development process of several browser vendors in short order. I would be interested in hearing other people with arguments on sXBL, and specifically the binding language issue, in order to try to present something at the conference.
Flights leaving soon, so I'll wrap this up.
-- Kurt
August 31, 2004
XML News of the Week
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.
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 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)