Re: Comment/Suggestion: DOM L3 L&S

Duncan_Stodart@insession.com writes:
 > Open to suggestions.  Coming from Apache's Xerces C++ implementation I'd 
 > suggest an URL.

Whether the domain values are URIs or short strings specified in the
DOM spec doesn't make any difference to me, since I'd expect language
bindings to provide convenient named constants I can refer to.
Judging from the current round of DOM 3 drafts, I'd expect the W3C to
go for short strings, and forget to deal with namespace control within
that space.  (Such as reserving some prefix for future W3C use, and
recommending some Java-esque reverse-domain prefix convention.)

Reception seems to have been poor when I suggested clarifying that for
the Load/Save specification, but I don't remember the exact response
off the top of my head.

(I still think that's important, and using URIs at least implicitly
hints at that, if the W3C doesn't want to be specific on this topic.)

 > I know this does raise issues wrt to mapping implementation errors to w3c 
 > defined errors, and also implementations must decide when to return DOM 
 > error codes and when they should return error codes in other domains but I 
 > can't see a way to allow callers to have fine granularity of control any 
 > other way.  This also allows W3C to grow the error code set as the general 
 > community require yet allowing implementations to press ahead without 
 > extending the standard through proprietry interfaces/methods.

Yes, which is nice.  It might even be reasonable for the DOMError
objects to provide a sequence of domain/code pairs, so that if an
error matches some non-W3C error, and later a W3C-specified error code
is defined, both can be associated with the error.  That feels a bit
heavy, but then, we are talking about the DOM, and error handling
never has the same performance requirements as normal processing.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

Received on Friday, 30 August 2002 11:42:13 UTC