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

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 15 Oct 2007 11:38:34 +1000
To: public-webapi@w3.org
Message-ID: <20071015013834.GB8636@arc.mcc.id.au>

Bjoern Hoehrmann:
> So what do implementations actually allow now and in the future? It
> seems to me, as you don't actually give precise rules for other schemes,
> you might aswell say, implementations may support other schemes, and
> must handle them in a manner analogous to HTTP, and possibly update the
> specification if some new specification that maps other protocols onto
> HTTP APIs that you can reference emerges.

That is in effect what I’d like to say, but I was hoping to have it
written with stricter requirements than just “analagous”.  Perhaps that
is not possible for the POST case while still being useful.

> >By “functionally equivalent to HTTP” I mean “is the same as HTTP but
> >happens to use a different URI scheme”, which is closer to the actual
> >wording that would be included (“functionally equivalent” being a bit
> >weasely).
> 
> You mean if the underlying protocol *is* HTTP, right?

Well, yes.

> As I said, I do not think this is a particularily sensible
> restriction. If some implementer can and wants to support postURL on
> some additional scheme, they are highly likely to just ignore such a
> restriction.

Sure, if people want to disregard specs they will.

But, as I say in my reply to Maciej, given that it is just that the
underlying protocol is HTTP and that the request URI could just be
replaced with one that has the http scheme, I think it’d be safe to drop
this requirement.

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au
Received on Monday, 15 October 2007 01:39:01 GMT

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