I think the goal should be somewhere in the middle. I agree that the definition of PWP should be, as much as possible, implementation agnostic, but I agree with Dave that saying "we don't care" is also not appropriate.
We may have to define a PWP Processor in the abstract sense. What a processor is supposed to do to answer to different use cases, what are its functionalities, that sort of things. We may not define it in a normative way in the sense of some formal language or terminology, but we have to understand what can, cannot, should, or should not be done with a PWP. And it is certainly important to know whether the realization of such a PWP processor is possible with today's technologies, what is PWP specific and what can be reused off the shelf, etc.
Ivan
> On 5 Jan 2016, at 16:24, Cramer, Dave <Dave.Cramer@hbgusa.com> wrote:
>
> On Jan 5, 2016, at 9:41 AM, Leonard Rosenthol <lrosenth@adobe.com <mailto:lrosenth@adobe.com>> wrote:
>
>> Nick – the specifics of how an RS chooses (or not) to cache are out of scope for PWP. They may make sense for some sort of format-specific work (eg. best practices for PWP with EPUB) but we don’t care about it here.
>>
>> Remember – PWP is format/packaging and implementation agnostic. (we seemed to all agree to that pre-holidays)
>>
>
> The fact that an existing web technology can solve a critical use case for PWP is on-topic in my opinion, and learning about such things can only help our work. Such technologies may not be a part of the documents we produce, but saying "we don't care about it here" I think sends the wrong message.
>
> 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/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704