W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2009

Re: fragment or sub-resources

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 8 Sep 2009 09:51:13 +1000
Message-ID: <2c0e02830909071651s1fee1e2ej8e1877e93ed50cec@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: public-media-fragment@w3.org
On Tue, Sep 8, 2009 at 1:11 AM, Yves Lafon <ylafon@w3.org> wrote:

> On Mon, 7 Sep 2009, Silvia Pfeiffer wrote:
>  Hi Yves, all,
>> Let me start with some nitpicking.
>> <nitpicking>
>> I think we need to be careful in our choice of words: calling URIs with a
>> query component "sub-resources" is a dangerous undertaking.
>> According to RFC3986, the query component is part of a resource identifier
>> -
>> not a sub-resource identifier:
>> "The query component contains non-hierarchical data that, along with data
>> in
>> the path component, serves to identify a resource within the scope of the
>> URI's scheme and naming authority (if any)."
> In my description, a sub-resource is a resource with a relation to another
> one englobing it (let's call it the parent one). Unless given by a specific
> mean (like an HTTP Link header), no relation between what I called a
> sub-resource and the "parent" pre-exist, and certainly not a relation based
> on the URI syntax. But I agree we need to be very careful there, and have a
> common vocabulary.

I also found it very difficult to specify what relation the resource created
by the query has to the original resource. Sub-resource is a bit too close
for my taste, since it's a different resource, and maybe parent is, too, I
don't know.

The problem that we have is: without the "Link" header, there is no
relationship between the two resources. With the "Link" header, it's almost
the same as with the fragment and it turns from an unrelated resource into a
sub-resource / child resource / derived resource.

So, if somebody has a good set of word for specifying these so there are no
misunderstandings, please speak up.

Received on Monday, 7 September 2009 23:52:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:43 UTC