Re: responseXML/responseText exceptions and parseError

Zhenbin Xu wrote:
> Sorry I accidently deleted part of reply. Inline...
> 
>> -----Original Message-----
>> From: Jonas Sicking [mailto:jonas@sicking.cc]
>> Sent: Thursday, June 19, 2008 2:17 PM
>> To: Zhenbin Xu
>> Cc: Anne van Kesteren; Sunava Dutta; IE8 Core AJAX SWAT Team; public-
>> webapps@w3.org
>> Subject: Re: responseXML/responseText exceptions and parseError
>>
>> Zhenbin Xu wrote:
>>
>>>>> [Zhenbin Xu] Regardless what different browser does today, rich
>>>> parsing
>>>>> error is an important feature for developers. I have found it can
>>>> pinpoint
>>>>> the exact problem that otherwise would have been difficult to
>>>> identify when
>>>>> I sent incorrectly constructed XML file.
>>>>>
>>>>> And given that the goals is to define a useful spec for future
>>>>> XHR implementations, we should define how rich parser error is
>>>>> surfaced instead of omitting it because nobody but IE supported it.
>>>>>
>>>>> It is even more important we define it in the XHR spec because it
>> is
>>>> not
>>>>> part of DOM Core. Otherwise such a key piece would be lost and we
>>>> will
>>>>> have diverging implementations.
>>>> The goal of XHR Level 1 was to get interoperability on the feature
>> set
>>>> that exists across the major implementations of XHR today, so I
>> don't
>>>> think parse error information fits the bill there, but it sounds
>> like a
>>>> great feature to look into for XHR Level 2.
>>> [Zhenbin Xu]
>> Did something happen to your reply here?
>>
> 
> [Zhenbin Xu] Indeed it would already be very useful if XHR1 is to summarize
> behaviors of all major implementations today, and document the common behaviors.
> In which case the spec should try to accommodate all major browsers and
> leave controversial parts to XHR2. This is why we suggested the "null or exception"
> language.

So strategy that the spec has been following has been to use the feature 
set that is common between browsers, but for those features try to 
define a good useful spec that archives interoperability and a solid API 
for developers to develop against.

The reason we didn't want to write a spec that "accomodates all major 
browsers" is that such would be largely useless. When you get into the 
details browsers behave differently enough that the spec would have to 
be so fuzzy that it would essentially just be a tutorial, not a 
specification.

Wordings like "null or exception" is a pain for developers. It's also 
something that is hard to build future specifications on. Especially 
when taken to the whole XHR spec.

Hope that explains why the spec looks the way it does?

/ Jonas

Received on Thursday, 19 June 2008 22:20:36 UTC