W3C home > Mailing lists > Public > www-tag@w3.org > February 2004

RE: HTTP Methods. MGET.

From: Danny Ayers <danny666@virgilio.it>
Date: Sat, 28 Feb 2004 14:18:39 +0100
To: "Jon Hanna" <jon@hackcraft.net>, "Dare Obasanjo" <dareo@microsoft.com>
Cc: "Norman Walsh" <Norman.Walsh@Sun.COM>, <www-tag@w3.org>
Message-ID: <BKELLDAGKABIOCHDFDBPAEFMFMAA.danny666@virgilio.it>


> Quoting Dare Obasanjo:
>
> > Quoting NormanWalsh:
> > > If you need MGET to get metadata for the data that GET would
> > > give you, how do you get the metadata about the data that
> > > MGET gives you?
>
> MMGET?

If I understand/remember correctly, this doesn't come up - MGET isn't
metadata about the representation GET returns, it's about the identified
resource:

GET uri -> representation of uri
MGET uri -> description of uri

It's probably been mentioned already, but switching on the mime type doesn't
work as-is, as the RDF/XML won't usually be about the resource identified by
the uri. I've a feeling Patrick also had an answer for the suggestion of a
different mime type...

I too felt the URIQA proposal was a non-starter because of the demand for
the fundamental extension of extra verbs. But since arguing with Patrick
about it a while ago (faq definitely needed!), I haven't seen or come up
with an alternative that provides a comparable 'first class' service, a
level which may well be justified. Being pragmatic, perhaps multiple
messages over regular verbs will be needed. Or maybe there's an alternative
somewhere in reach of the current naming of graphs discussion.

Incidentally, Roy states "doubling method space is evil", and shows a
similar sentiment about halving method space, as HTML forms tends towards.
Is this because it has been determined (through formal reasoning?) we have
*exactly* the methods we'll ever need, or merely that only minor,
incremental additions/reductions should be considered?

Cheers,
Danny.
Received on Saturday, 28 February 2004 08:27:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:03 UTC