[whatwg] A Quick Greeting and Some Comments

Kurt Cagle wrote:

> 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.

Good post here but you seem to be missing that the XML DTD/Schema is the 
API in these cases. For SVG you need to know the attributes of the 
elements whereas in an OO API you need to know the properties of the 
classes. I don't see what the difference is in the following 3 cases:

<svg:circle x="10cm" y="10cm"/>

var circle = document.createElementNS( SVG_NS, "circle" );
circle.setAttribute( "x", "10cm" );
circle.setAttribute( "y", "10cm" );

var circle = new svg.Circle;
circle.x = "10cm";
// or using some JS2 like syntax for the unit
circle.y = 10cm;



erik

Received on Tuesday, 8 June 2004 01:04:17 UTC