Re: fragment or sub-resources

Also posted another blog post with these ideas, which is a bit more
structured, I think.

I look forward to comments!

Also, btw: I will be travelling to Melbourne this week and will probably not
be able to attend the MFWG phone conference.

Regards,
Silvia.


On Mon, Sep 7, 2009 at 10:48 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>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)."
>
> The name "sub-resource" is IMHO closer to what the RFC calls a "secondary
> resource", which is what the fragment identifier creates:
>
> "The fragment identifier component of a URI allows indirect identification
> of a secondary resource by reference to a primary resource and additional
> identifying information."
>
> I think we can only compare queries vs fragments or resources (potentially
> with query) vs secondary resources (with fragment).
>
> </nitpicking>
>
> Now let's move on to the analysis of your thoughts.
>
> <fragquerydiff>
> I think I agree that the idea of separating queries and fragments based on
> transcoding needs is a good one.
>
> In fact, I would go a bit further: I think URI fragments can be used when
> the Browser can do the media fragment addressing by itself just from the
> data received; the retrieval of fragments from the server is then just an
> optimisation. This optimisation then only needs to communicate the URI
> fragment parts to the server and the server only needs to reply with the
> relevant byte range - the Browser does not require any further adapted file
> headers because it already deals with that resource and has its decoding
> pipeline already set up. Also, we are not creating a new resource, but just
> retrieving the relevant byte ranges.
>
> In contrast, URI queries must be used when the browser does not have the
> necessary data available from a normal resource retrieval operation that it
> would require to present the requested media fragment. This may be the case
> for some of the media fragment addressing schemes that we have discussed in
> the spatial domain (e.g. image components) and we should re-visit those
> (some time in the future). However, it works well for the temporal domain
> and should also work well for the track domain.
> </fragquerydiff>
>
> <uritemplates>
> In the query case, if we recommend the use of URI templates to servers that
> offer media fragment addressing with queries, then they could extend the
> scheme to e.g. providing lower bandwidth versions, or lower framerate
> versions or some other transcoded representation of the original media
> resource.
>
> How do you think a server could advertise its URI query capabilities for
> media fragments? Would it be a specific http protocol exchange through which
> a client can ask a server for its capabilities?
>
> Is the template substitution process that would be necessary to be
> undertaken by clients a overhead that is worth it?
>
> Further: how would a client (Web browser) inform the user that a particular
> server provides further addressing capabilities than other Web servers and
> make these available to the user?
>
> I think URI templates are nice, but they are more useful for particular
> services than others - for example, data services would be delighted IMHO to
> find out about the capabilities of a Web API through the API providing URI
> templates with all details. OTOH, a Web browser will not find a URI template
> all that exciting, since it experiences the Web through mostly pre-built Web
> pages and interaction processes. The Web developer would use the URI
> templates of the Web server to determine what he/she could display, but
> after that the interface would probably not adapt any more because it would
> require custom display code for custom extra functionality.
>
> So, while I think URI templates are great, I also think they may be an
> orthogonal concept to what we are trying to discuss here.
> </uritemplates>
>
> <querystandardisation>
> What we can discuss wrt URI queries are a set of standard queries that we
> would expect every Web server that also serves media to implement. These
> would probably be the full set of temporal, spatial, track and named URI
> fragments, plus potentially others that we discarded so far for URI
> fragments since they required transcoding.
> </querystandardisation>
>
> <querypresentation>
> I guess the only question that is still on my mind wrt media fragment
> addressing using URI queries is the question of presentation.
>
> In theory, a media fragment specified through a URI query is its own new
> resource. Therefore, it would be presented as a complete resource and not as
> a "secondary resource" as part of another primary resource. This, in the
> case of temporal URI queries, leads to e.g. the presentation of time offset
> 19 as the beginning of the resource.
>
> As discussed before and also suggested by Yves below, the "Link:" header
> could be an optionally added header that the Web Browser would use to
> determine the full dimension of the complete resource and display it as
> such. If a Web developer was able to add a request for such a header in the
> client, then the Web developer could decide whether to present a query-based
> media fragment with the dimensions of the primary resource or without them.
> </querypresentation>
>
> So, in summary (and some further understandings), I suggest the following:
>
> * not to worry about URI templates as a specification mechanism for
> query-based media fragment URIs, but rather specify some concrete query
> mechanisms that browsers should support.
>
> * using the single-step partial get approach for fragment-based media
> fragmet URIs WITHOUT the requirement to "add new container headers in order
> to serve a playable resource".
>
> * in the query case, there is no need to add a Range header for seconds,
> but it would be nice nevertheless to receive the content-range header with
> the actual delivered ranges as in the single-step partial get approach. This
> time WITH the requirement to "add new content headers in order to serve a
> playable resource".
>
> * using the "Link:" header for query-based media fragment URIs to
> optionally allow to specify the original dimensions of the video; this needs
> to be accompanied by a UA request parameter to add the "Link:" header.
>
> * using the dual-step partial get approach is an optimisation to the media
> fragment URIs where we want to enable existing Web proxies to store the
> retrieved byte ranges. This applies actually to both, the fragment-based and
> the query-based URIs.
>
>
> Cheers,
> Silvia.
>
>
> On Thu, Sep 3, 2009 at 7:13 PM, Yves Lafon <ylafon@w3.org> wrote:
>
>> During the last two teleconferences, we discussed a bit the issue of # vs
>> ? (ie: fragment vs sub-resources).
>> It seems that when we are not in the trivial case of just getting a part
>> of the compressed resource, ie: when transcoding is needed, that a
>> sub-resource might be a better match, it may have a Link: header pointing to
>> the original resource, but would be a resource on its own.
>>
>> Now, as you can't know in advance if the server support a specific syntax
>> for getting sub-resources of a specific resource, we might want to signal
>> this using a URI template [1], as in that case it really sets expectations
>> for the client (note that it is an example on how to advertise that a server
>> would use our syntax for sub-resource).
>> Comments?
>>
>> [1] http://tools.ietf.org/html/draft-gregorio-uritemplate-03
>>
>> --
>> Baroula que barouleras, au tiéu toujou t'entourneras.
>>
>>        ~~Yves
>>
>>
>>
>