clarify package document location within container

[mattgarrish]

A problem that came up during the ESC work is that if you locate the package document in a sibling directory from the components, some major reading systems won't recognize them (the package location becomes like a domain root and resources outside it aren't available).

For example, with this directory structure:

/EPUB/package.opf
/components/whatever

The resources under the components directory aren't accessible.

This is contradictory behaviour to the specifications, as there is no requirement that the package document be at the root and not be able to access resources in a sibling directory, but given the reality is it worth making a similar recommendation to storing all resources under a dedicated directory that all package documents be located at the root of that structure? (when there is more than one opf, at least)

If resources are shared between renditions, then a structure like this is going to become problematic:

/EPUB/fxl/package.opf
/EPUB/reflow/package.opf
/EPUB/video
/EPUB/audio

As you won't be able to reach across directories. Similarly, if the resources go into one of the fxl/reflow directories, the one they don't go into still won't have access.

The multiple-renditions specification doesn't say anything about this issue.

[mattgarrish]

I'm removing this issue from 3.1 and re-assigning it to the multiple renditions specification as that's where any guidance belongs.