- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Mon, 10 Oct 2016 15:39:47 +0000
- To: Ivan Herman <ivan@w3.org>
- CC: W3C Digital Publishing IG <public-digipub-ig@w3.org>
- Message-ID: <802BA7B9-50C1-46AC-B557-C91ACFCCB417@adobe.com>
3.1 – I like that, with some small tweaks to focus on the publication and not the UA. Thanks!
5.1/5.3 – You are right. Removing 5.3 and merging example with 5.1
On archiving – good idea. Done.
And same on accessibility. Done. (but didn’t add the schema.org reference)
From: Ivan Herman <ivan@w3.org>
Date: Monday, October 10, 2016 at 10:15 AM
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: Re: Comments on the dedupe branch - for discussions later today
On 10 Oct 2016, at 15:11, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
Appreciated.
Yeah, let’s wait on the meeting before adding the issues…
Explanations on your questions
3.1 – I removed it because (IMO) it didn’t actually talk to the topic, but just grabbed multiple concepts and threw them together. I agree it would be good to have a use case where, but this wasn’t it.
It could be as simple as "Yoshio usually reads a book on his tablet when he is at home, but he does not carry it around while commuting on the train, so he prefers to use his phone to continue reading his favorite novel. He expects the environment to provide a good reading experience regardless of the device he uses.
3.3 – Good point. They do indeed need cleanup!
3.4 – Yes, definitely should add a use case around that.
4.1 – I was trying to find a way to differentiate logically different versions (where you and I each have the same version, but you’ve added comments to yours) and technically different versions (where the author puts out a change). Open for suggestions.
The problem is that the concept of version is fuzzy. When do you qualify a PWP to be a different version? We may say that defining it to be a different version is the author's/publisher's privilege… But I could also consider your examples as not being different. Let us discuss that on the call if we have time!
4.2 – Yes, first use case could use a cleanup. I thought about 2nd and 3rd when I was working on it and felt that it was worth leaving them separate as they talk about two different types of distribution – a purchased subscription vs. a loaner. But I’m open to alternatives.
Yeah, they are a bit different… Maybe we can leave as it is indeed.
5.3 – The way I looked at it, Reading Order and Alt Reading Order are two reasons we need Random Access, but they aren’t the only reason. I wanted to keep them separate so that folks understood each of the three as separate requirements (though it may end up that they are all solved by the same thing technically).
But we already say, in 5.1:
"It should be possible for the author to convey several potential reading orders that may go beyond the “default” for the content of the publication. This alternative reading order may only includes specific parts of the publication rather than the full content of the PWP."
Ie, we already talk about alternative reading order! I think moving the use case from 5.3 into 5.1 and remove 5.3 would be perfectly fine.
6.1 & 6.2 – I wanted to leave the requirements in place so that people could see that there are other reasons we need the same concepts, but did indeed try to link it back. Maybe putting back a specific use case for each would make them stronger in their current form. Definitely open to suggestions.
Keeping the requirement is fine. What I am proposing is to remove the lines like "Req. 25: The locations of all PWP components should be discoverable." and replace the back reference using the <a class="req-ref-full" href="#r_p13n"></a> trick (where r_p13n should be the id for the other requirement). I just want to reduce the number of formal requirements that can be (and will be) extracted from the text.
7.1 – Referencing the schema.org<http://schema.org/> work would seem like a great idea, even if only as part of a use case. And as for Anita – fine with me, the name was already there.
7.2 – Same comment as 6.1/6.2, I felt it was important to clearly spell out that there is another reason we need those things. But perhaps we can find an alternative way to accomplish the same thing.
Same comment:-)
B – Absolutely! (I didn’t touch that section)
C – Agreed, good idea!
Thanks for taking the time to read over my changes and send this feedback! Talk to you in a few.
Talk to you soon!
ivan
From: Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>
Date: Monday, October 10, 2016 at 6:28 AM
To: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Comments on the dedupe branch - for discussions later today
Leonard, all,
first of all, the changes in the dedupe branch of the UCR document are great, thanks Leonard for this!
I do have a number of (mostly minor) comments below. I was wondering whether I would put them into the issues' list, but I was afraid of polluting the github issues with a number of potentially ephemeral comments; ephemeral, because the idea would be to discuss the document, including these, later today, and if we agree on them (or reject them) on the call, they may be incorporated into the text right away. I am fine turning the issues into "real" issues after the call if it helps the editors.
The comments are purely in document order, not in the order of any other priorities of any kind.
* Section 3.1 Horizontal dependencies
There was a use case in the original use case document on device independence. The idea was to have a (albeit possibly simple and obvious) use case for each of the horizontal aspects listed into the explanation text, hence the DI use case. I am not sure it is a good idea to remove it.
* Section 3.3. Constituent Resources
The first 5 use cases are not 'personalized', so to say. They should be but, reading them closer, I wonder whether all of them are not subsumed by the other use cases that follow, ie, whether they could simply be removed (maybe the 'preload' feature of the 2nd is not reflected yet?)
* Section 3.4, Metadata
It may be a good idea to add a use case on the fact that publishers need a way to include, or include a reference to, metadata whose vocabularies are defined by a specific area and whose role is essential in the publication chain. ONIX is an obvious example (this issue did come up during the discussions)
* Section 4.1, Distribution and Versioning
I am not sure I understand the "(technically)" side remark…
* Section 4.2, Distribution Process
The first use case says "He expects to be able to receive the PWP as a file (rather than only having access to it)". I am not sure that is true. As the rest of the sentence says, Ahmed "expects...to be able to load it onto its different reading devices.", but he does not care whether this is via a file or some other mechanism.
I wonder whether the second and third use cases in the same section are really different. They both refer to the fact that the access to a publication is time limited. If so, they should be merged, imho.
* Section 5.3, Alternative reading orders
Isn't that section, and the related requirement, subsumed by 5.1 (Random access)?
* Sections 6.1 and 6.2 (Archival Discovery and Newly Published Versions)
Both sections, though define formally a new requirement, say that "this requirement is the same as XXX". We should not define a duplicate requirement formally in this case; those are automatically put into the table in the appendix, may be referred to from an external document, may be used, later, as a reference to see whether a spec fulfills all requirements, etc. We could
- Either describe the extra, archival-related use case and then refer back to the existing requirement (like what do at the beginning of section 7 for Accessibility) or
- Remove those sections altogether and add the relevant use cases where they belong.
I am, mildly, in favour of the first approach
* Section 7.1, Accessibility metadata
- I wonder whether it is useful to put an explicit reference to the Accessibility Metadata that is on its way to become part of schema.org<http://schema.org/>…
- (absolutely minor) I was also wondering whether the name 'Anita' is really appropriate as the name for a use case on Hindi Braille. The corresponding wikipedia page[1] does refer to Sanskrit, but also says that "The name Anita is mostly used in Hungary and Spanish, Portuguese, Italian speaking countries as well as Indian languages with Sanskrit origins." but, at least to my ears, it is a bit misleading. What about using a more clearly Indian name like, see [2] (note that 'Anita' does not appear on [2]…). (B.t.w., we do not have a single Japanese or English name on among our users…)
* Section 7.2 Alternative media
* Same as for 6.1 and 6.2: let us not define a formal requirement if it is an alias to an existing one
* Appendix B. Acknowledgement
We should add Marcos, Mike Smith, and Hadrien Gandeur to the acknowledgement list…
* Appendix C. References
I wonder whether we should not remove the [pwp] reference. By now it is fully out of sync, including its editors' copy. We may want to put it back if we publish the final version of the UCR but, for now, it may only be the source of confusion...
Talk to you later!
Ivan
[1] https://en.wikipedia.org/wiki/Anita_(given_name)
[2] http://www.iloveindia.com/babynames/traditional-girls.html
----
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
----
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
Received on Monday, 10 October 2016 15:40:23 UTC