[whatwg] A Quick Greeting and Some Comments

[Kurt Cagle]

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