Hi Anne,
Thanks for your prompt reply, and for clarifying your intentions.
I had suspected that there was another way to interpret the
specification, but since I couldn't imagine why anyone working on a
W3C specification would want to prevent it from being used by other
specifications, I thought it best to give the spec the benefit of the
doubt.
Anyway, this clarification means that the spec falls down on two counts.
The first is that if you want to insist that there is a 'context
dependency' whereby XHR objects must only exist in a world that
supports the HTML 5 Window object, then you really need to change the
wording of section 4. It currently says:
Objects implementing the Window interface must provide an XMLHttpRequest()
constructor. [HTML5]
This does not imply that a conforming implementation of XHR needs to
support Window; it merely says that *if* a user agent supports Window,
then it must also support the XHR constructor.
However, as you can imagine, the XForms WG regards that tack is both
unnecessary and wasteful; hence the second count on which the spec
falls down.
Certainly, a big problem is that the HTML 5 spec is not yet complete,
so you are mandating a dependency on something that is not yet
available.
But this whole relationship is unnecessary because the XHR object
could be used in many different contexts, in web application
architectures far more varied than those narrowly conceived at
present.
You might say that since you are only documenting what currently
exists, then this is not your problem, which would lead to the
following comments:
* why go out of your way to prevent a standard from being reusable? This is why
it is wasteful;
* the HTML 5 Window object does not currently exist, so how can this
dependency?
* the original XHR object--the Internet Explorer ActiveX control--can
be instantiated
independently of a browser, so if you want to document 'what
currently exists' you
need to allow for this, whether or not it is 'good design'.
Our original requests for minor changes to the document to clarify
that the XHR object be usable in other contexts and other
specifications therefore still stand.
Regards,
Mark
On Fri, Jun 13, 2008 at 1:33 PM, Anne van Kesteren <annevk@opera.com> wrote:
> Dear Forms WG,
>
> Thanks for using our new list.
>
> On Fri, 13 Jun 2008 14:22:15 +0200, Mark Birbeck
> <mark.birbeck@webbackplane.com> wrote:
>>
>> This should be changed (or a note added) to stress that this
>> dependency on HTML 5 only applies if a user agent actually supports
>> the HTML 5 Window object. Section 4 makes this clearer, but the fact
>> that the dependency on Window is *conditional* in section 4 needs to
>> be reflected in section 2.1.
>
> Actually, support is not conditional.
>
>
>> In section 4 we have:
>>
>> "Objects implementing the Window interface must provide an
>> XMLHttpRequest()
>> constructor. [HTML5]
>>
>> [...]"
>>
>> Although an implementation need not support Window--as outlined in the
>> first paragraph quoted--
>
> You are not interpreting that paragraph correctly, I'm afraid. There's
> nothing optional about it. The Window object is required, objects
> implementing that object must provide a constructor.
>
>
>> In both situations Document is *required*, so a conforming
>> implementation needs to provide one somehow.
>>
>> The spec already leaves room for an implementation to provide this
>> 'somehow', in the note that was quoted above:
>>
>> Note: As per the conformance criteria implementations are free to
>> implement
>> this in any way they desire as long as the end results are identical
>> to those given
>> by the English prose.
>
> Actually, the specification is quite clear what Document object is meant.
> It's the one associated with the Window object one which the XMLHttpRequest
> constructor was invoked. The specific way this relationship is implemented
> is up to the implementation, of course, and that's what that note points
> out.
>
>
>> We feel that although these are minor changes, they would clarify for
>> implementers that the XHR object is usable in a broad range of
>> situations.
>
> I'm afraid you're misreading the specification rather badly. Is there
> anything I can do to make it more clear?
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
--
Mark Birbeck, webBackplane
mark.birbeck@webBackplane.comhttp://webBackplane.com/mark-birbeck
webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)