Re: Comments on latest UCR for discussion

2.2.9 Manifests Access
- OK – if we clean up the definition and description, I can live with it staying a separate section.

3.3/3.4
- Cleaning up the order in general may also fix this.
(and the point about section 4, wasn’t about it being security, just that it is a BIG topic (with more whitespace and larger font and probably different tones on a screen reader) so it stands out.

Leonard

From: Ivan Herman <ivan@w3.org>
Date: Monday, October 31, 2016 at 11:44 AM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: Re: Comments on latest UCR for discussion


On 31 Oct 2016, at 16:27, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:

[I am happy to submit PR’s (or just commit changes) but wanted to raise them for discussion first]

1 - Adding references to documents and ad-hoc publishing to the Abstract.  They are mentioned in the introduction but not in the Abstract.  I’d like to make some minor tweaks so that someone just reading the abstract knows we are looking at both. Any objections?

Yes, that is a good idea.



2 – Removing the word “traditional” publication from many instances.  Is there a reason we need to clarify them this way?  Let’s just call them publications (or at least, using our new term) Web Publications.   Objections?


+1


3 – Replacing references to books (outside of examples!) with publication.  There are still a few of these left that aren’t appropriate for the general descriptions.  Objections?


+1


4 – Is pagination a function of the publication or the user agent, or both?  The current text isn’t clear nor do I think we have ever considered which option(s) we want here.  My recommendation is to make it clear that it could come from either the pub itself or the UA.  Objections?


+1


5 – Currently there is an example in 2.2.6 (Personalization) about Buffy and her need for a WebPub that only provides captions & transcripts.  To me, this fits better in 2.2.7 (Constituent Resources) where it can focus on the need to only load certain types of resources (rather than treating it as a “personalized experience”).   Objections to moving it?

I agree. If this is moved, remember to adjust the reference to it in the appendix on accessibility requirements



6 – In 2.2.8 (metadata) the first two Usage Examples are more about requirements than use cases, as they don’t include specific people or scenarios (as all our other ones do).  I’d like to move the text out in the description and add some actual use cases that reflect them.  Objections?

+1



7 – I don’t get section 2.2.9 (Manifests Access) at all.  This is something that has been added recently (without discussion, AFAIK) and only serves to bring specific implementation and technical details into this document without any benefit.  I’d like to remove the remove the entire section and find a good home for the usage example – perhaps under personalization, with an additional piece there about publisher personalization (beyond just users).   Objections?

I do not remember when it got into the doc, to be honest. (I just moved it around in the latest round, although I may have merged some sections. I do not remember.)

I guess now that we have an entry in the terminology section the whole first part of that section can be removed. It is indeed unnecessary. That being done, I do believe that requirement there stands. I do not think this is really personalization, actually; if moved, it may have to do with distribution.


8 – 3.2 (Distribution Process) needs a usage example of email distribution of an ad-hoc publications, such as a secretary sending out meeting minutes or pre-read material.  Objections to adding one?


+1


9 – Just to make the flow a bit less confusing, I’d like to switch the order of 3.3 (Archiving) and 3.4 (Manifests and Links).  Due to the sub-sections of 3.3, it was confusing to just into the manifests without realizing that it was a level up.  By making the next thing after 3.3, be 4 Security should make things flow better.  Objections?


I understand your argument of switching 3.3 and 3.4, but I am not sure what you say about security...

One of the issues that I would like to discuss today is the order in general. Eg, I am not sure that the order of the sections within 2.2 are really the good ones; the flow would probably suggest that the requirements are put there reflecting some sort of a priority, which is not the case.

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