W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: [XHR] SVG WG LC comments

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 16 Jun 2008 15:47:22 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: public-webapps@w3.org, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.ucugk8ke64w2qv@annevk-t60.oslo.opera.com>

On Fri, 13 Jun 2008 19:36:46 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> Anne van Kesteren wrote:
>>  On Thu, 12 Jun 2008 23:01:10 +0200, Jonas Sicking <jonas@sicking.cc>  
>> wrote:
>>>>>  │ This is the Document pointer.
>>>>> If 'pointer' or 'Document pointer' is a term (which the styling  
>>>>> seems to indicate) then please add it to section 2.2.
>>>>  The specification defines various terms throughout the  
>>>> specification. Only terms that didn't really fit anywhere else are in  
>>>> section 2.2.
>>> Still sounds like "Document" is the correct term here, rather than  
>>> "Document pointer".
>>  Still? What do you mean?
> As in "I still think he has a point".
> Using the term "pointer" seems bad since it's very C/C++ specific. I  
> don't think it's used in neither Java or EcmaScript, where the term  
> "reference" us more common. Additionally it is used very inconsistently  
> throughout the spec.

It's just a name. Why do you think it's used incosistently?

> I would suggest using simply the term "Document" or "Document member"  
> instead.

Document would be confusing as that is already defined by DOM Core.  
Document member also seems confusing as it is not an IDL member.

>>  However, that's not too important, determining the base URI seems  
>> important enough to justify this.
> But you are not using the Window object to determine the base URI. The  
> AbsctractView interface is enough to determine the base URI.

Then we can't cover cross-frame scenarios in the test suite. (Using  
contentWindow and such.)

> It is quite clear that the Window and HTML5 specs are not going to be  
> finished recommendations by the time we want to put the XMLHttpRequest  
> into Rec, so at that point we'll have to remove normative references to  
> them one way or another.

Duplicating large pieces of text into XMLHttpRequest from HTML5 seems like  
a bad idea and would lead to a less solid definition of what  
XMLHttpRequest is I think. And would hopelessly confuse people to no end  
when they no longer are in sync.

If we want to move XMLHttpRequest to REC faster than HTML5 we would need  
to find some way to move the pieces it depends on in HTML5 to move faster  
to REC or find a way to make a reference to concepts defined in drafts  
specifications from a REC.

Anne van Kesteren
Received on Monday, 16 June 2008 13:47:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:09 UTC