Re: [dpub] PWP-UCR merges and questions

O.k. I see where you are going, and yes, that is an important feature but then, at least for me, the _description_ of the requirement is not clear (enough). A first shoot at it could be:

[[[
The fundamental requirement on identification already states that there should be a way to uniquely identify a publication (see 2.2.2 Uniquely Identifying a Web Publication). This requirement can easily be extended to constituents of a Web Publication by using standard Web identifications. However, a model that would extend this identification to the resources contained in a <em>Packaged</em> Web Publication is also necessary, making it possible to refer to a resource regardless of whether the resource is within an Web Publication or within its packaged version.
]]]

The requirement definition could also be a bit re-written, trying to remove the reference to a manifest.

[[[
A Portable Web Publication should include a a mapping of the identification of a constituent resource between the Web and its equivalent in a package.
]]]

WDYT?

Ivan





> On 31 Oct 2016, at 14:20, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> The issue is that the manifest item is not about identification of the constituent parts/resources.  It is also not about an implementation (other than saying we need a list/manifest).
> 
> What that item is addressing – at least for me – is a common use case.
> 
> Original, “on the web”, content refers to an image on a different site (let’s say, our favorite Mona Lisa).  When it is packaged (and brought “off the web”), the person packaging it up wants everything self-contained but also can’t modify the original content (eg. an archival scenario).  As such, the resource needs to be included in the package but somehow the remote URL needs to now refer to an internal URL.
> 
> That help?
> 
> Leonard
> 
> From: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
> Date: Friday, October 28, 2016 at 10:39 AM
> To: Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>>
> Cc: Tzviya Siegman <tsiegman@wiley.com <mailto:tsiegman@wiley.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
> Subject: Re: [dpub] PWP-UCR merges and questions
> 
> 
>> On 28 Oct 2016, at 16:23, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>> 
>> No, Ivan, that is not correct.
>> 
>> The identification use case (which is covered in 2.2.1 and 2.2.2) is completely different than the manifest and links case.   The identification case is about the PWP itself (aka the “single unit”), whether packaged or not.  The manifest/links section is about working with constituent resources (2.2.7) of the PWP when packaged.
> 
> I know.
> 
> The description of the requirement in 3.4 says:
> 
> [[[
> The fundamental requirement on identification already states that there should be a way to uniquely identify a publication (see 2.2.2 Uniquely Identifying a Web Publication). This requirement should be extended to resources within a publication, such as a chapter, an image, or a mathematical formula. While the Web provides a model for this for non-packaged resources, a model that will work for the packaged version is also necessary.
> ]]]
> 
> What I was arguing for is that, as a short description of what a requirement is for this description, the proposal of Tzviya in the PR, which says:
> 
> [[[
> There should be a method of uniquely identifying components of package.
> ]]]
> 
> seems to be a more adequate description than what is currently in the UCR text:
> 
> [[[
> Manifests should include a means to remap/redirect a given URL to another, either within a package or externally.
> ]]]
> 
> which already hints at a solution (which may or may not be correct).
> 
> (Maybe using 'constituents' rather than 'components' might be better, to stick with the terminology we use elsewhere.)
> 
> Ivan
> 
> 
> 
> 
>> 
>> Leonard
>> 
>> From: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
>> Date: Friday, October 28, 2016 at 10:10 AM
>> To: Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>>
>> Cc: Tzviya Siegman <tsiegman@wiley.com <mailto:tsiegman@wiley.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>> Subject: Re: [dpub] PWP-UCR merges and questions
>> 
>> 
>>> On 28 Oct 2016, at 15:35, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>>> 
>>> Thanks for merging these as well as providing the PR #’s.
>>> 
>>> A few comments.
>>> 
>>> Pagination:
>>> On the issue of maintaining the original page numbers – since we are focused only on the publication format, is this something that you are expecting to be part of the PWP itself?   And is it really a mandatory requirement (must) or a strong recommendation (should)?
>>> 
>>> Manifests & Links
>>> That change needs to be reverted as the new text is not the same requirement as the originals.   The original talks about the ability to actually map (or redirect) from one URL to another, while the new one talks of identification.  Completely different things.
>> 
>> But isn't it correct that the identification of a part of a publication across all 'states' (to use an outdated word:-) is the _real_ use case and requirement? The mapping/redirection is a tool to achieve that, isn't it?
>> 
>> Ivan
>> 
>> 
>> 
>> 
>>> 
>>> Security
>>> Section 4.2 is important because it discusses some specific use cases in the context of PWP in which a UA might not allow a publication to work as the publisher/author originally intended because its capabilities have been restricted. So while I agree that this is “in support of the horizontal dependency of security”, I think it is important to call these out for folks who may expect this.
>>> 
>>> Section 4.3 is the opposite of 4.2.  Where 4.2 is about a UA restricting a publication’s usage of the OWP, 4.3 is about how a publication could become “trusted” and thus allow more capabilities than it might normally.  This is basically the PWP equivalent of HTTPS and “trusted sites”.
>>> 
>>> So yes, we need both. If people have specific wording improvements – definitely happy to consider them.
>>> 
>>> Leonard
>>> 
>>> From: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com <mailto:tsiegman@wiley.com>>
>>> Date: Friday, October 28, 2016 at 8:54 AM
>>> To: "DPUB mailing list (public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>)" <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>>> Subject: [dpub] PWP-UCR merges and questions
>>> Resent-From: <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>>> Resent-Date: Friday, October 28, 2016 at 8:55 AM
>>> 
>>> Hi All,
>>> 
>>> I merged several PRs to PWP-UCR
>>> 
>>> Ivan’s proposed changes [1], which included Heather’s reorg, data inclusion, the accessibility table, and a general editorial review
>>> 
>>> The A11y TF’s rewording of Pagination section to avoid confusion around the multiple uses of the word “pagination” [2] and proposed changes to section 2.1.1 “Alternative Modalities” [3]
>>> 
>>> I proposed new language for Manifests and Links [4] because it was a little hard to discern intent. Please review so we can merge.
>>> 
>>> I also have some questions for the group to discuss:
>>> 
>>> 1.       Section 3.1 <http://w3c.github.io/dpub-pwp-ucr/index.html#distro-vers> “Distribution and Versioning”: We had discussed using a word other than Versioning, because versioning carries a lot and different meanings for the Web and Publishing worlds. Please provide suggestions.
>>> 2.       Section 4.2 <http://w3c.github.io/dpub-pwp-ucr/index.html#limiting_features> “Limiting a Web Publication's Features” and Section 4.3 <http://w3c.github.io/dpub-pwp-ucr/index.html#escalating_trust> “Escalating Trust”: Upon re-reading this, please clarify what these use cases and requirements provide that the section on Horizontal Dependencies does not provide. I believe that we have successfully made a case outlining Accessibility use cases that are less than clearly defined in the Web world. Perhaps it is my lack of familiarity with security issues, but these security examples are rather fuzzy to me, and I think we need to better define them.
>>> 
>>> [1] https://github.com/w3c/dpub-pwp-ucr/pull/151 <https://github.com/w3c/dpub-pwp-ucr/pull/151>
>>> [2] https://github.com/w3c/dpub-pwp-ucr/pull/152 <https://github.com/w3c/dpub-pwp-ucr/pull/152>
>>> [3] https://github.com/w3c/dpub-pwp-ucr/pull/153 <https://github.com/w3c/dpub-pwp-ucr/pull/153>
>>> [4] https://github.com/w3c/dpub-pwp-ucr/pull/154 <https://github.com/w3c/dpub-pwp-ucr/pull/154>
>>> 
>>> Tzviya Siegman
>>> Information Standards Lead
>>> Wiley
>>> 201-748-6884
>>> tsiegman@wiley.com <mailto:tsiegman@wiley.com>
>>> 
>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Technical Lead
>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
> 
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704