W3C home > Mailing lists > Public > public-webapi@w3.org > October 2007

Re: Compatibility of SVG Tiny 1.2's getURL() and XMLHttpRequest

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 13 Oct 2007 21:41:27 -0700
Cc: public-webapi@w3.org
Message-Id: <E0381E10-DB1E-42DC-B6F1-353AD2ADE4A8@apple.com>
To: Cameron McCormack <cam@mcc.id.au>


On Oct 13, 2007, at 8:44 PM, Cameron McCormack wrote:

>
> Hi group.
>
> The SVG WG is currently tightening the description of the getURL and
> postURL methods so that it is clear what to do when faced with non- 
> HTTP
> IRIs.  You can see the current definition here:
>
>  http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGGlobal_getURL
>
> We wish to avoid unnecessary incompatibilities between these methods  
> and
> XMLHttpRequest.  Our current proposal is to define these methods such
> that:
>
>  * If getURL is called with an HTTP or HTTPS IRI, then an HTTP request
>    with the GET method will be used.
>  * Other IRI schemes may be supported for getURL, and if they are
>    supported, the method will retrieve the resource identified by
>    the IRI.
>  * If postURL is called with an HTTP or HTTPS IRI, then an HTTP  
> request
>    with the POST method will be used.
>  * Other IRI schemes may be supported for postURL, but only if they  
> are
>    functionally equivalent to HTTP (such as itms).
>  * For non-HTTP(S) IRIs, AsyncStatusCallback.status will be set to  
> true
>    if the resource was successfully retrieved in full, and false
>    otherwise.
>  * For non-HTTP(S) IRIs, AsyncStatusCallback.contentType will be set  
> to
>    null.
>
> Any pointers on compatibility issues which would make it more  
> difficult
> to implement getURL by means of using XMLHttpRequest behind the scenes
> would be appreciated.

The easiest way to ensure that getURL() and postURL() could be  
implemented with XMLHttpRequest behind the scenses is to define them  
in terms of equivalent XHR operations and normatively reference XHR  
(implementations would be required to act as if it had been  
implemented this way).

Better still would be to drop them and replace them with a requirement  
to support XHR, since they provide a subset of its functionality  
without significant added convenience.

Regards,
Maciej
Received on Sunday, 14 October 2007 04:41:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:58 GMT