Re: EPUB Rec track (Was Re: [minutes] 2019-10-01)

Let me add two more variables to the equation, continuing along the lines of Jeff's scenario (2).

I have heard that the current EPUB 3.2 document would need a strong editorial re-write or even re-structuring, without touching the technical content. If this is indeed correct, then it may make sense to publish this re-written EPUB 3.2 as a Rec, that would then be a starting point to 3.4, 3.5, etc. By doing so, it would be easier to track changes later. Of course, if this is not the plan, i.e., any change would start directly with the current document, then this factor goes away.

Another point: Jeff said:

> If we believe that in three years there is enough meaningful content for  an EPUB 3.5, then I would not advocate taking EPUB 3.2 to REC. 

I wonder whether a more incremental model would not be a better option, i.e., not to wait three years with a big set of changes but, rather, publish new releases relatively often (say, every 12-18 months) even with only a few new technical features. Some sort of a more agile model, not unlike what is happening in the HTML land.

Ivan

> On 3 Oct 2019, at 02:36, Jeff Jaffe <jeff@w3.org> wrote:
> 
> 
> 
> On 10/2/2019 6:10 PM, Dave Cramer wrote:
>> On Wed, Oct 2, 2019 at 12:56 PM Garth Conboy <garth@google.com <mailto:garth@google.com>> wrote:
>> And... jumping the gun...
>> 
>> Given your two scenarios, Jeff, I'd tend to lean toward #2.  :-)
>> 
>> Jeff, do you think work on #2 should happen in the CG or in a WG? Or CG first and then WG?
> For those on the thread who forgot what #2 is, let me re-produce it here:
> 
> 2. Let's assume that we collectively believe that there are additional meaningful enhancements for EPUB that we expect to deliver in the next three years.  These could be sourced from several directions: (a) Sequential arts (manga) requirements, (b) some level of interop with Kindle, (c) bringing in some of the audiobooks content into the core EPUB spec, (d) bringing in some early Web Publications content, (e) natural evolution of the core EPUB 3.0 spec which was already approved 8 years ago.
> 
> If we believe that in three years there is enough meaningful content for 
> an EPUB 3.5, then I would not advocate taking EPUB 3.2 to REC.  I would
> 
> prefer to put our energies into the new function.
> 
> .....
> 
> to which Garth said - yes let's work on that, and Dave said that the CG is developing some proposals.
> 
> .....
> 
> Now comes Dave's question do we do that work in a CG or in a WG.
> 
> W3C's general approach to such questions is that the work should be incubated in a CG and standardized in a WG.
> 
> When the work is still exploratory (incubation phase) it is too expensive to put it in a WG.  Teams will experiment rapidly with different approaches; make many changes; and won't want the overhead of doing that in a WG.
> 
> But CGs lack the rigor of WGs.  The work is not as well known, it will not get the testing; horizontal review; level of patent protection; and the imprimatur of the membership (AC) and Director.    So when the work reaches a greater maturity level it should be transitioned to the REC track.
> 
> A roadmap provides an expectation of which new capability will be ready technically or needed by the marketplace on what schedule.  One (or several) Community Group(s) could "hang out a shingle" and immediately start working on some subset of the workscope.  The Business Group could use the roadmap and assess when the work should start transitioning to the REC track.
> 
> I don't know the roadmap so I can't answer the question directly.  If some of the work is already mature/needed we could start a WG tomorrow.  If it all matures in two years we could plan to start a new WG in two years.  More likely, the work matures at different paces.  The BG proposes a charter (some months from now) outlining the expected roadmap.  Depending on how many distinct "traunches" of function are involved - there could be a single EPUB 3.5 deliverable proposed, or incremental 3.3, 3.4, etc. deliverables - there could be different deliverables identified in such a charter.
> 
> HTH
> 
>> 
>> Dave


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