Re 2: Restructuring of the UCR

(I sent out this email this morning my time but… I realized that I sent it only to Heather and not to the whole group! Absolutely stupid of me; put it on my jet-lag…)

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].

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.

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.

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

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

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")

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...

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"

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".

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"

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

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

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)

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

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.

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