- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 2 Dec 2005 11:30:03 -0800
- To: Kasimier Buchcik <K.Buchcik@4commerce.de>
- Cc: ML-www-dom <www-dom@w3.org>
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.
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.
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.
Regards,
Maciej
Received on Friday, 2 December 2005 19:30:23 UTC