Re: fragment or sub-resources

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
>
>
>