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
