Re: EPUB Road Map

One of the things to consider is who is the intended audience for each of
the specs and what are the group's goals.

Wolfgang is correct, in interpreting the W3C process as more stable but the
flip side to that is that implementors may not want to work on parts of the
spec until the spec becomes finalized because, until it is finalized there
is a potential that the feature will not make it into the final
specification or be declared "at risk" and be postponed to the next version
with the same caveat that it might or might not get implemented.

If you want to make a version for authors in addition to one for
implementors, please consider doing it as a separate document like WHATWG
did with their HTML spec (https://html.spec.whatwg.org/dev/ and
https://html.spec.whatwg.org/multipage/) where the first link reads
differently and slightly less technical than the spec itself.

I don't know how realistic it is but the community may want to explore
doing something like the way TC39 manages the annual Javascript
specification releases as outlined here: https://tc39.es/process-document/.
This would make it easier to incorporate new proposals that have working
code attached to them.

On Thu, Aug 8, 2019 at 6:59 AM Wolfgang Schindler <
ws.schindler@googlemail.com> wrote:

> I think it depends on our understanding of the concept of a living
> standard.
>
> Publishers and Developers of RS need a stable point of reference for their
> development of contents and systems which is an expensive activity. The
> option of having to face changes to the spec at any time would be a
> nightmare if it would not be hedged in by the strict principle that
> backwards compatibility is always guaranteed. If you refer to point X in
> the current spec, but find out that it has been changed a few weeks or days
> ago, is a deeply unsettling experience. Am I misunderstanding something
> here or misinterpreting your idea?
>
> For me a big difference between W3C and WHATWG is that a W3C spec (once
> accepted) is a stable document until it is superseded by a new version,
> while WHATWG documents are a kind of a moving target.
>
> I think it will also make sense to take care of the different audiences
> of  a spec as authors and editors will need a different approach.
>
> Best,
> Wolfgang
>
> Am Mi., 7. Aug. 2019 um 16:29 Uhr schrieb Avneesh Singh <
> avneesh.sg@gmail.com>:
>
>>
>> It also depends on what we mean by living standard.
>> Right now there is no living standard process in W3C. Work is going on on
>> proposals.
>>
>> I think it would be good to wait for proposals to come out and then
>> evaluate if it suits the needs of EPUB 3 road map.
>>
>>
>> With regards
>> Avneesh
>>
>> *From:* Laurent Le Meur
>> *Sent:* Wednesday, August 7, 2019 19:40
>> *To:* Dave Cramer
>> *Cc:* W3C EPUB3 Community Group
>> *Subject:* Re: EPUB Road Map
>>
>> Hi,
>>
>> Because (X)HTML 5 is a living standard, this would make sense for EPUB 3
>> to be also a living standard and it would give publishers, distributors and
>> application developers the *feeling of stability* for EPUB 3 they badly
>> need.
>>
>> When a snapshot has to be built, for instance to create an equivalence
>> with the ISO EPUB spec, this can still be done via a publication date or a
>> minor version, but in the latter case the communication would still be on
>> "EPUB 3", not on a specific EPUB 3.x.
>>
>> re. possible revision to EPUB 3, ok for adding core media types of
>> similar updates, to be discussed by the CG and BG;
>> but opening EPUB 3 to pure HTML would be a nightmare (for EPUB Check and
>> many reading systems especially).
>>
>> Laurent
>>
>>
>>
>> Le 6 août 2019 à 18:26, Dave Cramer <dauwhe@gmail.com> a écrit :
>>
>> Now that EPUB 3.2 has been published, what's next for EPUB? This will be
>> discussed in the CG call this Thursday (agenda forthcoming) but it's a big
>> question (or a bunch of questions), and I hope discussion will extend
>> beyond the CG calls. Some thoughts:
>>
>> 1. How should EPUB 3 be maintained? I personally thing EPUB 3.X is a good
>> candidate to become a living standard in the manner of HTML. I also wonder
>> the specs be easier to read and maintain if written in a different way, for
>> example Matt's suggestion to separate reading system conformance from
>> content conformance?
>>
>> 2. What, if anything, needs to be added or changed in EPUB 3? There are
>> some possible changes that would not invalidate any existing EPUB, such as
>> adding opus as a core media type or allowing the HTML serialization. But
>> what new features are driven by business needs? And how do we balance a
>> desire for new features against the costs of supporting them? There is
>> value in a stable spec, and I don't want to spend the rest of my life on
>> EPUB 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10…
>>
>> By chance, I ran across the original EPUB 3 Charter (
>> http://idpf.org/epub/30/wg-charter) this morning. Written in 2010, it
>> described fourteen goals for what turned out to be EPUB 3.0. Nine years
>> later, which of these goals have we met? What new goals would we add?
>>
>> 3. What should we do about all the EPUB satellite specs? The IDPF
>> published nearly a dozen specs, which have largely not been implemented by
>> reading systems or used by content authors. Should some of these be
>> revived? Should some of these be abandoned?
>>
>> Thanks,
>>
>> Dave
>>
>>
>>
>>
>>
>