Remote resource URLs containing a query component like this:

"https://www.youtube.com/v/xyz?version=3"

Should be allowed in the OPF. The character '?' should not cause validation errors since the resource is not included in the OCF.

In the case of the URL above, should the resource declared in the OPF contain the query component or not ?

But what if the resource to be pulled is only defined in the query string?

If all your audio/video is streamed from a single gateway server, dependent on value(s) in the query string you pass to the server, is it valid to have a single entry for all of them in the OPF that is the location minus query string? Eventually we'll hit problems with media types not matching.

I agree in this one case it would make good sense not to have to include the full URL including query string, but for uniqueness testing I can't see a way around it for the general case.

I agree.

Note however issue 190 where there was a problem with taking the query string into account.

What I propose is:

• for local resources, ignore the query string.
• for remote resources, the query string matters.

Should this be clarified in 3.0.1 or is this just bound to be ever subject to interpretation ?

Yes, I agree. Whether you pass a query string into a local resource should not factor in (unlike external content, local resource must physically exist in the container, so the ambiguity here should never apply).

Only when a protocol is specified at the start of the string should the entire src be treated as a unique instance.

It might be worth clarifying, but I'm not sure if the specifications are the right place. If we do, I think it would have to be in the item element def in Publications, as this is a unique issue to the package document. It's very informative, though, so maybe just not having epubcheck generate an error will be enough. I think the majority of people are likely to just copy and paste the full URL from the audio/video src into the item's.

This issue was closed by revision r454.