Re: [dom3core] getAttribute

Hi,

On Fri, 2005-12-02 at 11:30 -0800, Maciej Stachowiak wrote:
> On Dec 2, 2005, at 1:37 AM, Kasimier Buchcik wrote:
> 
> > Hi,
> >
> > On Thu, 2005-12-01 at 23:16 -0800, Maciej Stachowiak wrote:
> >>
> >> On Dec 1, 2005, at 6:34 AM, Ray Whitmer wrote:
> >>
> >>>
> >>> Can you tell me how many implementers of the standard would be made
> >>> retroactively incompatible by this sort of change to an intentional
> >>> part of DOM Level 1? I am not talking the major vendors current
> >>> implementations, but other and prior implementatiions? Please
> >>> enumerate those which will not be broken and let's see how many you
> >>> leave out. It is perhaps not as relevant to me as you would like it
> >>> to be that you personally do not care about these other
> >>> implementations which followed the standard. I have know list but
> >>> know of enough.
> >>
> >> Making either empty string or null an acceptable return value in this
> >> case will break 0 implementations. Can you name any that would be
> >
> > How did you evaluate that it breaks 0 implementations?
> 
> Since previously conforming DOM implementations would remain  
> conforming, there's no possible way they could be broken. Unless I  
> misunderstand what you mean.
> 
> >> broken by making both behaviors conforming? I can't imagine how this
> >> is possible.
> >
> > Yesterday I already posted a description of such a scenario.
> >
> > In case you missed it:
> >
> > If we have (e.getAttribute('foo') != "") then this will evaluate to
> > true if:
> >  1) there is an attribute node and its value is other than ""
> >
> > The change you request, would evaluate this to true if:
> >  1) there is _no_ such attribute node (NULL != "")
> >  2) there is such attribute node and its value is other than ""
> >
> > So every existing code which tests if an attribute node's value is
> > non-empty, will break.
> 
> That's not a DOM implementation, that's a DOM application.

True, but then I'm not sure what the essence of your statement was,
if it referred to the implementation only; probably no implementation
would break if we would decide to return a hard-coded value of "foo"
for getAttribute(). What was your point in referring to the
implementation only?

> 
> I can't claim it would break 0 applications, but I would expect most  
> ECMAScript DOM applications follow the de facto standard on this, not  
> the written spec. In other words, relaxing the spec on this would fix  
> far more applications than it would break.

This is easy to say for you, but without a survey of the amount of 
code this change would break I'm see not much value in such a statement.
I would find it more difficult to change non-script code already
compiled and running, than script code with a text-replacing tool.

> I'm also not sure you understand the proposed change. The proposal is  
> to allow implementations to return EITHER empty string OR null in  
> these cases. Presumably Java-based or C++-based implementations would  
> maintain their current behavior.

I have understood the proposed change.
I don't think it would be wise to have such an option. Optional
behaviour should be restricted to issues which are not common, or
you will end up in a lot of additional code, just to handle both cases.
Neither I think the behaviour of such a fundamental method should
deviate from implementation to implementation.

Let's look at some code examples:

- code like (e.getAttribute('foo') != "") would break

- code like (e.getAttribute('foo') != NULL) and code like
  (e.getAttribute('foo') != ""), i.e. code for testing of a non-empty
  value of an attribute, would need to be rewritten to:
  ((e.getAttribute('foo') != "") && (e.getAttribute('foo') != NULL))

What code would profit from such a change?
Actually I have difficulties to understand what code would profit from
an optional return value of getAttribute().
If we take (e.getAttribute('foo') == NULL) as an example, and the
author does not know that DOM implementation will be used on the
user's side, then normally, a DOM implementation should be
queried for such an option; so we get:
if (someAttributeCanDoNULLMethod())
  if (e.getAttribute('foo') == NULL)
    ...
else if (e.getAttributeNode('foo') == NULL)
  ...

An optional return value would produce a lot of trouble in my eyes.

But I think you refer to a world where _all_ browser DOM implementations
would implement the option to return NULL; i.e. the author would
rely on NULL being returned, when an attribute is not existent and
would need not to write additional code to test for both cases. Then
the  broken code you refer to would work.

But this is exactly the case where I see the advantages of DOM -
a portable API - being eroded. Such code would not be portable any
more.

Plus, excuse me for repeating this once more, such an option
would _extend_ the semantics of getAttribute(), in a way that it
allows only certain programming languages to test for non-existent 
attribute nodes.

Regards,

Kasimier

Received on Monday, 5 December 2005 10:33:17 UTC