W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2003

Re: i18n reviews of DOM 3 Core and Load&Save

From: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Date: Sat, 20 Sep 2003 15:28:31 -0400
Message-Id: <p0600200abb92599ea16b@[192.168.254.4]>
To: Johnny Stenback <jst@w3c.jstenback.com>
Cc: Joseph Kesselman <keshlam@us.ibm.com>, Francois Yergeau <FYergeau@alis.com>, "'www-dom@w3.org'" <www-dom@w3.org>, www-dom-request@w3.org

At 11:01 AM -0700 9/20/03, Johnny Stenback wrote:


>Code bloat is not the only reason, the point is I don't want to 
>force implementors to write code they know they don't care about, 
>for whatever reason (code bloat, implementation time, QA resources, 
>you name it).


That's a rather unusual position to take as part of API standard 
development. The benefit of the standard API is that users can count 
on it across implementations, but that only works if the standard is 
rich enough to cover many, perhaps most, uses. Throwing basic pieces 
away because some developers don't need it although many do need it 
will produce a standard that may be small and easy to implement but 
isn't very practical for real work. It's one thing to eliminate 
convenience features that can be duplicated in a few method calls. 
It's quite another to remove important functionality like being able 
to specify the encoding as UTF-8. If DOM's serious about being a 
generic XML API then it needs to provide this. Otherwise, we might as 
well just all use our own custom APIs like XOM, JDOM, or MSXML. We're 
going to have to use custom DOMs anyway because DOM isn't 
guaranteeing us enough power to get the job done. :-(

-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Processing XML with Java (Addison-Wesley, 2002)
   http://www.cafeconleche.org/books/xmljava
   http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA
Received on Saturday, 20 September 2003 17:10:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT