Re: Let's get back on topic (was pursuing the wrong goal...)

I find a some of this difficult to wrap my brain around constructively
outside the context of actual implementation.  I like the idea of building
ideas in a practical way for discussion.

For example, creating a series of Web Publications from simple to highly
custom and creating a UA (simulating I suppose a browser UA) to display
these within the context of the PWG direction so far, and then continue the
discussion around what works and what doesn't work, what is needed and so
on.

I remain unclear about what a UA *must* know about a manifest, for
example.  I can imagine all manner of things about what it *could* know,
and even what it *should* know.  I haven't had the pleasure of building a
Web App Manifest yet... it looks straightforward enough, but some seem to
think it may need such heavy modification for WP needs that it won't really
be a WAM any longer.  I could only really help answer this by having my
hands on something practical.

This is why I like Nicks initial proposal in the "continuing discussion
around polyfills" thread (that being:  *a server-side mechanism that would
allow a document to have polyfills ADDED to the document in real-time*).
Perhaps it is outside the context of our charter or goals, but it seems to
me that creating living examples of what we are working towards (or
alternatives in the case of Nick's suggestion), an actual implementation of
the ideas leading up to specification, might be helpful?  I am rarely able
to construct a fully functional model with the problems adequately resolved
outside the context of real world implementation.  it may be that
developers and engineers who have worked with WAM already don't need this
at all and have a clear vision that might just be muddied by troublesome
implementation tasks, or it may simply be too early for that, but I thought
I would throw it out there for consideration.


~J~



Jeffry Buehler

Client Solutions

@learnknowbly <https://twitter.com/learnknowbly/>

kls.knowbly.com


This message contains information which may be confidential and privileged.
Unless you are the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose to anyone the message or any of its
contents. If you have received the message in error, please advise by
replying to this e-mail and deleting the message.


On Fri, Feb 9, 2018 at 7:52 AM, Siegman, Tzviya - Hoboken <
tsiegman@wiley.com> wrote:

> Hi All,
>
>
>
> Let’s take a step back. I think that we have gotten way off topic.
>
>
>
> This thread started as a discussion that was fundamentally about whether
> we should move forward with an approach that is based on the Web App
> Manifest.
>
>
>
> The underlying question is this: The User Agent accessed the starting
> page that includes a link to the manifest. What does it do with it? How do
> we get from the UA having information to the point where we have a User
> Agent implementing the basic affordances for WP?"
>
>
>
> We seem to have some general constraints:
>
> - A user agent that is aware of WP (what we have been calling WP-aware),
> including stand-alone Reading system apps, should not be bothered by any
> scripts/polyfills/whatever that are included in the WP
>
> - Publishers of a WP should not be under the pressure to develop their own
> solution for WP-unaware browsers or other user agent
>
>
>
> So, to everyone who has commented positively or negatively on this thread
> (and anyone else), what happens when a WP-aware UA encounters the link to
> the manifest? (This question is valid even if we choose not to use WAM, by
> the way.)
>
>
>
> Thanks,
>
> Tzviya
>
>
>
>
>
> *Tzviya Siegman*
>
> Information Standards Lead
>
> Wiley
>
> 201-748-6884 <(201)%20748-6884>
>
> tsiegman@wiley.com
>
>
>
> *From:* Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
> *Sent:* Friday, February 9, 2018 10:16 AM
> *To:* Dave Cramer <dauwhe@gmail.com>
> *Cc:* Leonard Rosenthol <lrosenth@adobe.com>; daniel.glazman@disruptive-
> innovations.com; public-publ-wg@w3.org
> *Subject:* Re: Pursuing the wrong goal? (was Re: A followup/writeup on
> our Monday discussions (was Re: Continuing discussion on Polyfills))
>
>
>
> Well, since we're all sharing today, let me share the perspective from the
> Readium side.
>
> When we started thinking about Readium-2 about a year and a half ago, we
> looked at what works and what doesn't work so well in Readium-1.
>
> We quickly identified that:
>
>    - the server/client model is the only good solution for native apps as
>    well, and that even for EPUB, we're better off using an HTTP server
>    - that Readium-1 lacked a good manifest format, we needed something
>    more abstract that could work with any publication (not just EPUB) and that
>    would be the bridge between the server component (the one that parses
>    packaged publications and expose them using HTTP) and the client component
>    (pretty much what we've been talking about in the previous thread, with all
>    the publication specific affordances)
>
> We extended and improved previous work that was started during the EPUB
> 3.1 BFF effort and very quickly built prototypes that worked very well and
> unified our vision as well. Thanks to this manifest we could easily:
>
>    - build native apps for reading publications
>    - build Web apps and browser extensions for reading as well
>    - stream remote publications in a native app or a web app (the
>    business model or use case for that is IMO very obvious as well)
>
> As we continued working on this manifest, we also discovered that:
>
>    - our manifest is also a good fit for audiobooks and made it easy to
>    support streaming or caching for those (there's a desperate need to
>    standardize audiobooks)
>    - it's a good fit for comics as well, which a WG within EDRLab is now
>    working on
>    - it's also a good way of extending EPUB, since we can easily embed
>    our manifest at a well-known location (manifest.json) and rely on it
>    (instead of an OPF) for specialized use cases (like comics, where EPUB and
>    FXL are super limited and get in the way of the reading system)
>    - the hypermedia nature of its design also made it a good fit for a
>    new revision of OPDS (meant to distribute publications and browse/search a
>    catalog) as well as a new generation of OPDS parsers
>
> One thing that we never focused on where publications primarily
> distributed on the Web, because we didn't had a use case for them.
>
> I think that the whole "EPUB vs the Web" thing is misguided. Instead of
> long discussions about polyfills we should focus on:
>
>    - affordances ("what we want to build in terms of UX")
>    - use cases ("why we're working on these specifications")
>
> As we've seen with Readium-2 and the Readium Web Publication Manifest,
> sometime we accidentally find good solutions to problems that we never even
> considered in the first place.
>
> Best,
>
> Hadrien
>

-- 
This message contains information which may be confidential and privileged. 
Unless you are the addressee (or authorized to receive for the addressee), 
you may not use, copy or disclose to anyone the message or any of its 
contents. If you have received the message in error, please advise by 
replying to this e-mail and deleting the message.