- From: David Peterson <david.peterson@iname.com>
- Date: Tue, 30 Dec 1997 23:34:13 +1000
- To: "DOM Mailing List" <www-dom@w3.org>
Hi there. I'm new to the list, so I appologise in advance for any doubling up I'm making. I've been making an implementation of the Java API listed in the current DOM spec and have noticed a few things that are in the API that aren't in the spec and vice-versa (mostly properties, although a couple of methods as well), and a few that seem to be name changes. Also, I was wondering if there is already an implementation of the API out there somewhere. If not, I'll probably post this one. I've currently got the core classes in the 'dom' package, the HTML-specific classes in 'dom.html' and the XML-specific classes in 'dom.xml'. Any better/more official package locations would be appreciated. Anyway, I've listed a few of the discrepancies. I'm mainly making a point. 'API' refers to the Java api and 'spec' refers to the IDL specification. HTML ==== HTMLDocument: getScripts() - This is not listed in the spec. I'm not sure if this is a level 1 or 2 feature. HTMLLocation get/setQuery() - This is listed as 'wstring search' in the spec. It would probably be better if they both had the same name. get/setFragment() - I think this is 'wstring hash' in the spec. Hash is probably easier for the average HTML coder, but Fragment is more appropriate for XML's extended linking abilities. I was also wondering why reload has a boolean parameter. Surely you'd either want to reload or not reload, and if not, just don't call the method. And I'm unsure on the purpose of replace. HTMLElement get/setTagName() - These are not listed in the spec. I'm guessing that this returns/sets the 'name=xxx' attribute. Though what the difference is between that and get/setId is, I don't know. get/setId() - These are also not listed. Also, if TagName does return 'name=xxx', I'd suggest eliminating TagName and only having this method, since I believe that HTML4.0 recommends using 'id' instead. Also, on a purely asthetic level, capitalising ID (eg getID) would make it more aligned with the standard Java implementations (eg Beans). Etc, etc. There are quite a few more, but it that's not the point. I'm not trying to debunk or insult your work, or anything, and I'm aware it is a work in progress. In fact, the work that's been done in a fairly short time is impressive. I'm mainly asking for clarification. Thus, I have the following questions: 1) Will the api's be better synchronised in the next release? 2) If so, how long until the next release? 3) Until then, should I try and allign my implementation to the specification or to the listed Java API? Or combine the two? Thanks for your time. David Peterson
Received on Tuesday, 30 December 1997 08:43:39 UTC