- From: Kurt Cagle <kurt@kurtcagle.net>
- Date: Tue, 08 Jun 2004 08:54:55 -0700
Greetings all, I saw this group through a Google news item to an article, followed it, and was intrigued by what I found. For those who may not know me (most of you, in all likelihood) I'm the author of a number of XML, XSLT, CSS, SVG and web related books for Wrox/Wiley, SAMS, and others, and a general gadfly in the XML community. I've been back and forth on many of the issues targeted by this group, and while I'm not in complete agreement with the goals, I do think that WHAT addresses some fairly major holes in the spec. I have a few general comments, and will have more as I get a chance to review the draft specifications. 1) My gut reaction when I hear people talking about using IE6 as a baseline model for development is to cringe. IE6 represents an endpoint technology, reflecting standards that are now a couple of years out of date, and employing specific capabilities that raise some serious security concerns. There are a number of VERY good ideas to be taken from IE6, but frankly I think that the innovation that I'm seeing now in both the Mozilla and Opera sides makes me feel that it should only be used as one reference point among many. 2) XForms is a cool technology, even with its wrinkles, but its also far too complex for the average web developer. Having said that, I think the underlying MVC architecture has a lot to recommend it. XForms does the following that I feel is noteworthy to draw back into other models - a) Makes XML, not delimited query string text or form content, the preferred mechanism for communicating with the server. This is a huge win, all things considered, because it makes it possible to pass contextual or relational information from the client rather than force the server to map a dictionary into a complex data structure. b) Creates an abstract model for defining controls, which, while complex, are also both very portable and easily extensible. What XForms doesn't provide, and what WHAT is potentially useful for doing, is providing a consistent bridge layer between the abstraction layer and the final presentation layer. c) XForms can readily be accomplished both directly on the client and via server technology; having built systems capable of doing both, I find that there are advantages in having each technology. d) XForms is predominantly declarative. There are at least eight subtly different versions of Javascript out there, not to mention four or five distinct DOMs which add considerably to the complexity of programming imperatively in a web environment. Declarative architectures are more robust in the face of such differences than imperative ones are, especially if you create a set of standardized imperative component libraries. e) Given all that, walking away completely from XForms is probably not the most effective way of working, especially as it does have a couple years headstart over WHAT. 3) I wrote an XQuery book three years ago, as part of a Wrox team. I wrote an XQuery book last year as part of a SAMS team. Between the two, I've sold 30 copies. I'm convinced that XQuery, which represents the collective work of the largest database manufacturers (and is one of the few W3C specs actively supported by Microsoft) will be stillborn. Why? Because it confuses a very real need (the need to extract XML content from a data store in a consistent manner) with a perceived marketing need (the need to create a "better" SQL). I raise this point as a cautionary one; does WHAT provide enough of a benefit that browser vendors, web developers and the public will all see it as satisfying a real need? 4) Another cautionary tale. The wireless phone industry all lauded WAP/WML when it first came out, saying that it would revolutionize the way that content was handled on the handheld web. Yet today, WAP/WML is largely an irrelevancy in the face of chips that have become powerful enough to handle more traditional HTML views. Transitional technologies require the same amount of time and energy to implement as new technologies do, the same amount of programming to implement into the firmware of cards, the same adoption curve that "bleeding edge" tech has. As I see it WHAT is fairly conservative in that it recommends incremental changes into the browser environments rather than wholesale ripping out of core pieces of functionality. Yet if the same problems persist with the newer model as does with the older one, have you necessary made the problem any easier, or have you simply created more incompatibilities between systems? 5) I have written behaviors for Microsoft itself; it was cool technology back in 1999. Today, I typically implement those behaviors using external namespaces and the intelligent use of XSLT. This takes a little more work, but the code is generally much cleaner in its implementation. This is a case of different strokes for different folks, though I think there are some things that can and should be taken from this. Realistically, behaviors do not exist in isolation. Instead, you typically have clusters of tags and attributes on those tags that determine the basal characteristics of the behavior, bindings that connect such elements with others, and sets of methods that can be called on these elements. In other words, to me it makes more sense to declare a code extension of tags, in the form: <what:import href="myTagLibraries.xml" xmlns:foo="http://www.what.org/ns/foo"/> which can then be invoked as distinct elements: <foo:slidebar value="0" min="0" max="100" width="250px" height="50px" id="myFooBar" label="My Foo Bar"/> I also like the idea of bindable elements: <input type="text" id="boundText" value="0"> <what:set attribute="value" begin="myFooBar.onchange" to="{myFooBar.value}"/> </input> This may seem awkward in comparison to a Javascript rendition, but it's not really. What happens here is that instead of placing the change binding onto the slidebar (necessitating functions if the binding is even remotely complex or affects more than a couple of elements), you place a listener on each form element that could be affected by changes in <foo:slidebar>, and more you do so in a declarative fashion. This has long struck me as one of the real strengths of SVG, especially when you tie it in with animation elements. The second advantage to this approach is that you can effectively isolate the implementation details from the markup, and as a consequence, can implement it in one of multiple ways. This gives you binary behaviors, script behaviors, and transformations all within the same basic mechanism, rather than having to create elaborate "code-behind" schemes or place an undue reliance upon a framework such as .NET. 6) Bundled behaviors of this form also bypass the CSS mechanism that I find so cumbersome when dealing with behaviors in IE. I've written several books on CSS; it is an antiquated technology that is difficult to extend into XML without a huge amount of work, and it is rapidly being deprecated in most new web browser technologies in favor of some form of NON-STANDARD styling mechanism. This to me seems to be the REAL hole within the W3C universe, and it shows up everywhere; there is no reason when dealing with XML that we should be accessing a non-XML text file that defines in a complex parsing manner a limited set of stylistic attributes that then rely upon a difficult to use cascading model. Binding behaviors into the model seems to me the height of poor planning. 7) Don't discount SVG. I think that SVG is sitting just on or slightly past its inflection point; from my vantage point studying the technology, this year will see it become pervasive everywhere EXCEPT within Internet Explorer, either directly or through third party extensions. If you treat SVG as simply another behavior a la #5, or better, treat it as a behavior implementation with a generic behavior interface, then you can continue to use the simplified forms of WHAT while admitting the new technology. This should, in my mind, be an underlying principal for WHAT - that the standard should NOT out of hand eliminate other technologies simply for the sake of simplicity, especially when those technologies can buy you as much as SVG can. 9) Perhaps a continuation of #5. The goal with any such system is to push declarative rather than imperative solutions whenever possible, and to push generalized DOM solutions over application specific ones when you can't. My own estimation of DOM has changed considerably over the years. At first, I saw it as a transitional technology, but increasingly I'm coming to see DOM as being a a generalized interface language that eliminates much of the complexity of OOP framework systems. Again SVG is a good model for this - rather than creating a complex set of customized components (a rect object, an oval object, whatever), each with its own access methods and procedures, you create a generalized DOM for working with the object in an abstract fashion, setting the position by changing the value of an attribute, adding or removing objects into the model through straightforward DOM insertions/deletions, and so forth. Where's the advantage here? Consider an e-mail system in which you could effectively represent everything as an XML object. You wanted to find all mail written by kurt at kurtcagle.net written after June 1, 2004? You can use XPath as the universal addressing system into the DOM, making a call such as kurtLetters = incomingMail.selectNodes(".//mail[from='kurt at kurtcagle.net' and sent gte '2004-06-01']") You need to know the schema, but you don't need to know a specific API -- and what's more, you don't need the same API on different systems that still implement this schema. The combination of XPath and DOM replaces a lot of specialty mail systems with one general one. Moreover, once you move more processes into XML, this permeates the method invocation system as well. Let's say you wanted to forward each of these emails to a new address (myBackupAddress at kurtcagle.net). You can do so as follows: for (kurtLetter in kurtLetters){ newLetter=kurtLetter.cloneNode(true); forwardNode=newLetter.document.createElement("forward"); forwardNode.text='myBackupAddress at kurtcagle.net'; newLetter.appendChild(forwardNode); outgoingMail.appendChild(newLetter); } xmlhttp.open("POST","http://www.mailServer.foo"); xmlhttp.send(outgoingMail); while (outgoingMail.childNodes){ outgoingMail.removeChild(1); } I'm using an e-mail system here only to show the generic nature of that DOM. Yes, it is perhaps not as easy to read as a dedicated API, but its very genericness means that you could create this system universally. Simplicity and universality should both be bywords when dealing with the web. Okay, I've probably gone on longer than I should (and will probably be permanently banned from this mailing list as a consequence) but I just wanted to stress that a back to basics movement is fine so long as people understand that such basics should be used as a guideline, not a regressive step. Anyway, I'm looking forward to the discussions on this group. -- Kurt Cagle kurt at kurtcagle.net
Received on Tuesday, 8 June 2004 08:54:55 UTC