Re: [Moderator Action] [dpub] 20160822 agenda

> On 26 Aug 2016, at 16:14, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> Certainly Boris should proceed – no problem there.
> 
> As for how to handle it in the UCR – I am not sure that a single introductory paragraph will do, since many people may skip over it and only look at the UC’s that interest them.  We should talk about this in a future meeting.

Sure.

Although… we will not have a call next week and the week after. Ie, we may have to handle this by email when we get to the editing round. Another option is that we leave this issue open until the final publication (sometimes in October); the publication before TPAC is only a draft anyway (ie, a stake in the ground).

Cheers

Ivan

> 
> Leonard
> 
> From: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>
> Date: Friday, August 26, 2016 at 10:05 AM
> To: Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>>
> Cc: Charles LaPierre <charlesl@benetech.org <mailto:charlesl@benetech.org>>, Dave Cramer <Dave.Cramer@hbgusa.com <mailto:Dave.Cramer@hbgusa.com>>, Boris Anthony <boris@rebus.foundation <mailto:boris@rebus.foundation>>, W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
> Subject: Re: [Moderator Action] [dpub] 20160822 agenda
> 
> Leonard et al,
> 
> I do understand where you are coming from and I also agree that there are cases where such an access issue may be an obstacle. However… I am not sure that this is the only use case where this comes up.
> 
> What I would propose is that:
> 
> - Boris finishes his contribution and we incorporate it into the UCR (alongside everybody else's pending contributions:-)
> 
> - We agreed that we'd declare a feature freeze on the 1st, and we'd spend some time (under the leadership of NickR and Heather) to get some unified style across all use cases. Ie, a purely editorial round. This may include naming conventions, stylistic updates, but also identifying such general issues like the one you refer to. Let us see then what the best action is. I *expect* (but have not checked) that there are several cases where access control of the PWP may become an issue, beyond this one. If there are several, then we may add, for example in the introductory part, some sort of a disclaimer making it clear that we are aware of this problem, but we do not touch this in the use cases themselves to improve readability. Or something like that. If there are only a few, we can come up with a language to cover those.
> 
> WDYT?
> 
> Ivan
> 
>> On 26 Aug 2016, at 15:17, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>> 
>> _IF_ you are able (technically and/or legally) to build a new package on the fly – you can do whatever you want.  However, you may not be able to do that in all cases and therefore you have to plan for that situation as well.
>> 
>> Let me give you two examples – one technical and one legal.
>> 
>> Consider a package that is digitally signed by the author/publisher.  Modification of that package would (most likely) break/invalidate the signature nor could you create a new package because that new one wouldn't have the signature included.
>> 
>> The second example is of course everyone’s favorite – DRM.  An author/publisher may have applied rights to the package (with or without encryption) that do not permit modification, even for the purposes of annotating.   And again, in that case, you couldn’t create a new package either.
>> 
>> 
>> Oh – and these are just the cases where we are talking about the packaged version.  The same concern applies to the unpackaged version as well, since it may be hosted by a service that doesn’t permit (or even support) annotations.  For example, consider my recent desire to comment on the PWP UCR document – which isn’t possible today with the server/system we use.
>> 
>> 
>> Leonard
>> 
>> From: Charles LaPierre <charlesl@benetech.org <mailto:charlesl@benetech.org>>
>> Date: Friday, August 26, 2016 at 8:14 AM
>> To: Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>>
>> Cc: "Cramer, Dave" <Dave.Cramer@hbgusa.com <mailto:Dave.Cramer@hbgusa.com>>, Boris Anthony <boris@rebus.foundation <mailto:boris@rebus.foundation>>, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>, "DPUB mailing list (public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>)" <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>>
>> Subject: Re: [Moderator Action] [dpub] 20160822 agenda
>> 
>> But if we are able to build a new package on the fly to give to the user with assistive technologies a package with all the audio and video stripped out for example why couldn’t we build a new package with additional annotations that reference the items within which are unable to be modified?
>> 
>> Thanks
>> EOM
>> 
>> Charles LaPierre
>> Technical Lead, DIAGRAM and Born Accessible
>> E-mail: charlesl@benetech.org <mailto:charlesl@benetech.org>
>> Twitter: @CLaPierreA11Y
>> Skype: charles_lapierre
>> Phone: 650-600-3301
>> 
>> 
>> 
>>> On Aug 25, 2016, at 1:50 PM, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>>> 
>>> If the annotations modify the “package”, and there are either technical or licensing reasons that prevent the modification of that “package” – yes.
>>> 
>>> Of course, that doesn’t mean that a given UA/RS couldn’t keep the annotations physically separate from the publication and “merge them on the fly”.
>>> 
>>> Leonard
>>> 
>>> On 8/25/16, 4:25 PM, "Cramer, Dave" <Dave.Cramer@hbgusa.com <mailto:Dave.Cramer@hbgusa.com>> wrote:
>>> 
>>>    On 8/25/16, 3:56 PM, "Leonard Rosenthol" <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>>> 
>>> 
>>> 
>>>> Because not all authors/publishers of PWPs will necessarily allow them to
>>>> be modified.
>>> 
>>> 
>>>    Most of what Boris mentioned sounded to me more like annotations than
>>>    modification of content. Are there use cases for preventing annotations of
>>>    a PWP?
>>> 
>>>    Dave
>>> 
>>>    This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
> 
> 
> 


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704