OCF-invalid characters should be allowed in remote resource URLs

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by rdeltour@gmail.com on 27 Mar 2013 at 2:59

[GoogleCodeExporter]

Original comment by rdeltour@gmail.com on 27 Mar 2013 at 2:59

• Added labels: Milestone-3.0.1

[GoogleCodeExporter]

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

Original comment by rdeltour@gmail.com on 27 Mar 2013 at 3:18

[GoogleCodeExporter]

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.

Original comment by mgarrish on 27 Mar 2013 at 3:39

[GoogleCodeExporter]

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 ?

Original comment by rdeltour@gmail.com on 27 Mar 2013 at 3:54

[GoogleCodeExporter]

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.

Original comment by mgarrish on 27 Mar 2013 at 5:56

[GoogleCodeExporter]

This issue was closed by revision r454.

Original comment by rdeltour@gmail.com on 27 Mar 2013 at 8:05

• Changed state: Fixed