W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > February 2009

[closed] Re: HTTP "related protocols?"

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 05 Feb 2009 08:15:05 -0500
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2myd1ja92.fsf_-_@nwalsh.com>
"Florent Georges" <fgeorges@fgeorges.org> writes:
>> One particular use case the WG had in mind here was accessing
>> non-XML content using computed URIs (for instance, from the file
>> system, using a "GET-like" access). You can use p:data for loading
>> binary data, but the disadvantage of p:data is that it can't take
>> URIs that are computed dynamically - whereas in the case of
>> p:http-request, the c:request element (and its "href" attribute)
>> can by generated dynamically.
>   Thanks for the explanation!  So if I am right, the intent of the
> step is "to perform HTTP and HTTPS requests, and support as well the
> file: scheme (in this case, @method is optional, and if present must
> be GET.)"
>   If it is, maybe it would be more clear to make the description in
> the CR more precise in that regard?  And maybe that trying to reuse
> http-request to support file: is just a kind of ad-hoc polymorphism?
> (so a separate step would maybe be better?)

We could have added a separate step. But given that lots of applications
that accept http: URIs also accept file: URIs, it didn't seem worth it.
And we didn't want to set the precedent that there should be a different
request step for every conceivable protocol.

Please let us know if you're not satisfied by this explanation.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | The art of living is more like
http://nwalsh.com/            | wrestling than dancing.--Marcus Aurelius

Received on Thursday, 5 February 2009 13:15:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:26 UTC