PWP wiki: https://www.w3.org/dpub/IG/wiki/Task_Forces/locators
Leonard: SW may not be the solution
... Limited support among the vendors
Tzviya: This group is not looking at a specific solution for how to get there. We need to talk about what the locator looks like
Leonard: We do need to talk about the manifest
Ivan: General sense of manifest is a collection of data
available to the PWP for managing the components
... let's not close the door on the manifest including information other
than location
... it describes the PWP and makes it manageable by readers (user
agents)
... This TF will not define the manifest entirely. This TF will define
what is needed for the locator aspect of the manifest.
leonard: what we are talking about is a catalog of some/all
content in PWP
... it also has a mapping aspect
<lrosenth> think of it as a name + address (like you find a person)
leonard: Every object has a name and address. In EPUB these are one and the same. In PWP, the address might not be the same
Ivan: let's not get too far away from reality. You are
referring to URLs.
... I would not use the name/address analogy but a mapping of one URL to
another
... There should be a way of saying that there are relative and absolute
URLs.
As soon as we have that, it makes sense to say that there is a relative URL, and it can map to an absolute URL on the Web.
Leonard: If we go from a packaged thing to unpackaged
thing, then the relative URL may go to an absolute URL
... We also want to make sure that absolute URLs in unpackaged PWP can
go to relative in packaged
Ivan: We want to make sure that the constituents will not
change when the PWP changes state
... There may need to be constraints
...example: if HTML5 contains reference to remote font and there is no
mapping to manifest, then the tool may not be able to find the font
Leonard: Maybe this isn't an issue, because if the packaging tool can't recognize something, it just excludes that item
Tzviya: I think we need to specify a method for accessing remote content, not just say that it is up the tools
Ivan: What happens if we specify that a remote resource is essential content. What does the href point to?
Leonard: The image points to www.louvre.org/blah (remote
resource), downloads the image, and the URL should ideally be the same
thing
... The other part of the locator discussion is what is the link to the
image from the outside - e.g. link from PWP to PWP?
... Taking a more complicated example, what is the locator for embedded
CSV data?
<rdeltour> question is about the PWP's URL itself
<rdeltour> does it change when the PWP is being ported?
<rdeltour> we say the PWP has a "unique" URL, but is it stable over time? depending on its state?
ivan: We are in dangerous territory of confusing identifier and locator
<rdeltour> I'm asking about *locators*
<ivan> my preferred way would be http://a.b.c/myPWP/thecsv.csv
ivan: if I move a URL from my server to your server, then the URL will change
BillK: Are we suggesting that some portion of the proposed syntax remain stable
ivan: yes
Romain: I think the URL in question is important. If we are talking about SW, the structure will matter and may/may not work with the transition of states.
Leonard: We don't have to lock ourselves into a specific implementation
Tzviya: We do need to keep in mind that we will need implementations, and be aware of what is out there
Ivan: SW is not a standard yet, and we can provide feedback