Re: Some significant items for discussion on "What is a Web Publication?"

Hi Leonard,

On Sun, Jan 22, 2017 at 5:16 PM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> While working on the PWP document today, I can into a few things that I’d
> like to raise for discussion (either via email or phone tomorrow, or both).
>
>
>
> Let’s start right up front with the definition of a Web Publication J.
> It currently reads “A Web Publication (WP) is a bounded collection of
> resources, envisioned and created as a whole”.  I would like to review the
> second half of that sentence – about the envisioned and created as a
> whole.  In the world of documents, the most popular feature of processing
> applications is the ability to combine parts of other documents together to
> create a new one.  In that use case, the resources weren’t “envisioned and
> created as a whole”.  You could say that the author/publisher envisioned
> that collection and intentionally collated those resources together – but
> that’s different from what is here.  I would also put forth that the
> application of annotations to a WP can create a new WP that also was not
> “envisioned and created as a whole”.
>


I much prefer the WP definition later in the document (I'm looking at the
current Editors Draft):

"A Web Publication (WP) is a collection of one or more constituent
resources, organized together in a uniquely identifiable grouping, and
presented using standard Open Web Platform technologies."

Perhaps the document should be careful about redefining terms in the
introduction that are defined elsewhere.


There is a requirement that “The package must include the unique identifier
> of the manifestation—a Web Publication’s origin is essential information if
> a PWP becomes portable”.  Two paragraphs later it goes into further detail
> about the origin inclusion and even mentions trust. Unfortunately, that
> requirement seems to imply some potential implementation considerations
> that the WebPackaging work is proving to not be feasible – see
> https://github.com/dimich-g/webpackage/issues/7.  I would like to remove
> the second half of that sentence (about the origin) and also remove the bit
> about trust from the latest paragraph.  Let’s just leave it open that we
> want a unique identifier, but that’s it, and that the origin is not
> necessarily related to the identifier.
>

As a veteran of many "unique identifier" battles, I retain my original
position that this document MUST (in the RFC 2119 sense) somehow tie the
unique identifier requirement into the Open Web Platform. Otherwise, the
probability that various organisations will claim compliance using
proprietary schemes approaches 1.



> Here’s the one where George, Charles and others are going to be scream –
> but I believe it is an extremely important point – you can’t mandate
> accessibility in a WP (ie. “A Web Publication must be accessible to the
> broadest possible range of readers”). We should make it a strong
> recommendation (a “should” vs. a “shall” in ISO terminology) and do all we
> can to promote this direction.  However, given our goals to support not
> only curated publications but also ad-hoc publications, it is not
> reasonable to expect them all to be accessible.  Just as not every page on
> the web is accessible, web publications need not be either.
>

I must agree with George here. There are always reasons to duck a11y, and
they mostly come down to economics. I'd rather the W3C as a standards body
take a firm, and frankly uncompromising, stance on things like
UN-sanctioned rights.



> Another area that we cannot mandate – but should make a strong
> recommendation – is that “A Web Publication must be available and
> functional while the user is offline”. An author may produce a publication
> that is only designed to be used online – for example, one that connects to
> an online system. We don’t wish to prevent the development of such a
> publication.
>

Changing the offline requirement would gut much of the document as it
stands. Not only would it change Section 1.1 Web Publication, but also
Section 2.1.1 Online/Offline requirements for user agents.

I'm not sure why Leonard thinks we cannot mandate an offline requirement,
especially given the state of existing browsers. I think the offline
requirement should stay in.



> Finally, I think we say too much about the use of the manifest.  It says
> “We also introduce the abstract concept of a manifest, which serves to
> carry information about the constituent resources of the publication, their
> sequence, and presentation”.  I think we should only say that it carries
> the resources and not mention sequence and presentation. This is consistent
> with our statement, earlier in the same section, about how we aren’t going
> to define “manifest” (and leave it in the generic FRBR sense).
>

This would appear to be another area with multiple definitions. Leonard is
correct that we should stick to one.