Re: Re 1: Restructuring of the UCR - my initial comments

On 10/24/16 2:24 AM, Ivan Herman wrote:
> Hi Heather,
>
> wonderful...:-)
>
> I have a number of comments, possible discussion points on the latest
> version. They are not in any particular order, just as I read the
> document.
>
> I know there are lots of things here (though some of them minor). I am
> happy to take the next editorial round to handle those!
>
> (I will answer to your questions in a separate mail.) So here we go:
>
> 1. The abstract says:
>
> "This document describes the various use cases that highlight the gaps
> that exist that impede publisher work flow and the user experience
> when working with non-traditional web publications. The requirements
> that come from those use cases provide the basis for the technical
> considerations in the “Portable Web Publications for the Open Web
> Platform” document [pwp] companion document."
>
> Somehow the first sentence does not work for me, I am not sure I
> understand it... And the second sentence would also need some changes
> to avoid problems with the current discrepancies among the documents.
> What about something like:
>
> "This documents describes the various use cases highlighting the
> problems users and publishers face when traditional publications are
> to be used in a digital, Web environment. The requirements that come
> from those use cases provide the basis for the technical
> considerations a companion document, currently entitled "Portable Web
> Publications for the Open Web Platform"[pwp].

I like your text. Changed.

>
> 2. We keep to the 'PWP' acronym in section 3 ("Packaged Web
> Publication"), whereas we keep the term 'web publication' in section
> 2. I would propose we do use 'WP' for "Web Publication" for the sake
> of consistency whenever appropriate.

Done.

>
> 3. The first sentence in section 2 ("Web publications are one or more
> resources...") is, in fact, our main definition of what we mean by Web
> Publications. I think it would be worthwhile somehow emphasizing this,
> either by using bold or something, or explicitly calling it out in the
> introduction or the terminology section that _this_ is what we mean by WP.

It is in the Terminology section. I added <em> tags there just for fun.

>
> 4. The W3C publication rules usually capitalize the word 'Web'. We may
> have to go through the text to do that whenever it makes sense

The W3C does not use CMOS. Do we need to capitalize "publication" as
well, as in "Web Publication"?

>
> 5. Section 2.1.1: I am a little bit bothered that this section
> (Alternative modalities) is dominated by accessibility issues (5 out
> of 7 use cases) and 4 out of those 5 are on braille rendering. I think
> we should consider reducing the braille rendering (there is quite an
> overlap among the use cases), we may have a use case on audio
> rendering (e.g., the fact that a recipe collection may use audio
> rendering because the cook cannot really handle the table while using
> the recipe), maybe also refer to senior citizens for another audio...
>
> More specifically, what about:
>
> - removing the last use case (BigBox Publisher...) which does not add
> any new aspect
> - I wonder whether the use case on James and the class of students is
> really different from this document's point of view. Both emphasize
> the fact that high quality braille may have to be generated by the
> publisher and included as an alternative modality, and one cannot
> necessarily rely on some on-the-fly tool external to the publication.
> Personally, I would remove the example for James
> - I would add the audio example for recipe books

I'm going to avoid touching this one given the discussion on the call
today. The DPUB-ARIA group will look at this.

>
> 6. Section 2.1.4: the requirement does not read well in English for my
> taste... maybe "When annotations are associated with a web
> publication, there should be no impediments in enabling the content of
> the annotation to be compatible with assistive technology."
>
> But, more importantly, I really wonder whether this requirement brings
> anything new. Annotation is part of the publication (maybe that should
> be emphasized somewhere?) and this requirement is therefore subsumed
> by section 2.1.2 ("Horizontal dependencies")

I've adjusted the text, but let's see what the ARIA group does here.

>
> 7. Section 2.1.5: I wonder whether this section should stay in the
> first place. Accessibility use case should (and are!) part of many
> different requirements, and this section does not add anything new...

DPUB-ARIA

>
> 8. Section 2.2.4: I think it is worth emphasizing, in this case, that
> we are referring to a _Web Publication_, ie: "There should be a way to
> uniquely identify a Web Publication"

Text adjusted.
>
> Also, the text says "This unique identification should be able to
> mapped onto the location of the publication.": the identifier may be a
> Web Address (a URL) itself. I guess one could rather say "If not
> expressed as a URL, there should be a way to map this unique
> identification onto a Web Address".

Changed.

>
> 9. Section 2.2.5: if the difference between offline and online
> disappears, I wonder whether this section does represent a separate
> requirement _for Web Publications_. We may want to re-think this in
> terms of Packaged Web Publications, but not at this place.
>
> 10. Section 2.2.6: I believe the title should be "Accessibility Metadata"
>

Changed.

> I also wonder whether it is worth keeping 5 use cases. The first and
> last one are very similar (even in terms of the topic of the book),
> for example, and the fourth is also not clear whether it adds anything
> new. I would propose to keep the first three only.
>
> *However* see my comments below

DPUB-ARIA
>
> 11. Section 3.1: this section is not for Packaged Web Publications
> only, but for Web Publications in general. I actually wonder whether,
> logically, the current section 2.2.4 should not be the first section
> in section 2.2, and then the current 3.1 should become the one right
> after it to become 2.2.2

Moved.

>
> 12. Section 3.2.1: is again non Packaging dependent. I believe should
> be moved after the newly positioned 3.1 (ie, would become 2.2.3)

Moved.

>
> 13. Section 3.4 is not Packaging dependent either. It should be put
> under 2.2.
>
Moved.

> That being said, the second use case is on something a bit different;
> it refers to the fact that some resources may not be packagable,
> though part of the WP. That may deserve a separate section here with
> that use case. We could do that without setting a new requirement,
> formally, just referring to the generic one, but adding a packaging
> specific use case.
>
> 14. It is an open question to me whether the security section (3.6) is
> WP or PWP. Looking at the use cases of 3.6.1, for example, the third
> is more generic, ie, WP; but, in fact, taken it this way, these may be
> general web security issues.
>
> My gut feeling is (but not sure) that 3.6 as it stands to day, should
> be removed, but we may want to add something more specific that is
> related strictly to the packaging aspect.
>
> Maybe I would follow Heather's idea of merging this section with the
> current 4.1 and have that as a separate top level section on security.

Top level security created, POE title removed, sections merged.

And with this, I've run out of time. I will leave the rest to you! :-)

-Heather

>
> 15. Section 3.7.1 is again not Packaging specific. I believe that
> should be part of the Web publication section.
>
> 16. I think that 3.7.2 should be part of the terminology (what do we
> mean by manifest?)
>
> 17. I believe section 3.7.4. should stay (reacting to a question in
> the draft...)
>
> 18. I do not think that the title of section 4 should be 'permission
> and obligations', it is the name of an existing Working group...
>
> 19. Section 4.2 is closely related to the manifest stuff and is
> general to any WP, should be moved to the relevant information.
> Actually, the requirement has overlaps with 2.2.6 (see my comment #10
> above), and I wonder whether this should not _replace_ 2.2.6 (taking
> over some of the use case in 2.2.6)
>
> Cheers
>
> Ivan
>
> ----
> 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
>
>
>
>