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

* Cameron McCormack wrote:
>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

I am not sure what you would be tightening; for example, for getURL it
says "this method will attempt to fetch the resource at that IRI using
the HTTP GET method." and you cannot do that for non-HTTP resources.
It seems you would be significantly extending the feature. It is also
not clear to me whether these changes are motivated by possible future
extensions to XMLHttpRequest to support to accomodate other protocols
(in which case a concern would be what implementations that simply pass
requests on to XMLHttpRequest have to implement on top of that).

>We wish to avoid unnecessary incompatibilities between these methods and
>XMLHttpRequest.  Our current proposal is to define these methods such
>that:

If you want to avoid incompatibilities, the appropriate approach would
be to define the functionality in terms of XMLHttpRequest.

>  * Other IRI schemes may be supported for getURL, and if they are
>    supported, the method will retrieve the resource identified by
>    the IRI.

It is not clear to me what this means, for example, with respect to the
requirement "User-agents are required to support the gzip content coding
and must decode it before passing it on to the callback."

>  * Other IRI schemes may be supported for postURL, but only if they are
>    functionally equivalent to HTTP (such as itms).

I am not sure what you mean by "itms" or what "functionally equivalent
to HTTP" means, but this would seem to be an odd restriction; you don't
have it for "getURL", and you can POST to mailto:... or news:... just
fine, as demonstrated e.g. by libwww-perl. XMLHttpRequest also does not
expose any checks, so implementations would probably need additional
logic to ensure they don't improperly support postURL().

>  * For non-HTTP(S) IRIs, AsyncStatusCallback.status will be set to true
>    if the resource was successfully retrieved in full, and false
>    otherwise.

That seems to be rather underdefined. What would happen, for example,
if you successfully retrieve the resource, but there are errors in the
gzip encoding, which implementations must remove? Or if the operation
is not a resource retrieval operation (you don't retrieve any resource
if you do a NNTP "POST", if implementations may support that)?

>  * For non-HTTP(S) IRIs, AsyncStatusCallback.contentType will be set to
>    null.

Why would that be? E.g., if you getURL() a data:application/xml,...
surely you'd want to know the type?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 14 October 2007 04:58:32 UTC