[MPEG-OTSPEC] near-term OT spec work

fantasai fantasai.lists at inkedblade.net
Fri Oct 9 04:20:39 CEST 2020

On 10/7/20 12:23 AM, Levantovsky, Vladimir wrote:
> *From:*mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of *
> On Tuesday, October 6, 2020 10:27 PM fantasai wrote”
>> CSSWG conducts its technical work in the public. Both our official and
>> unofficial drafts are public, and the discussions leading to many of the
>> proposals (though not all) and certainly the discussions following up on such
>> proposals are also public. You yourself have participated in the CSSWG, I'm
>> not sure why you consider that "spec progress is inconceivable without work
>> first being done internally".
> Yes, I agree that CSS WG is unique in a way, and the public nature of the WG 
> work is rooted in the very nature of W3C organization, which is much different 
> from ISO and many other organizations I’ve been involved in in the past. 

The public nature of our WG work is a direct result of incremental decisions 
the CSSWG made around 2007 to open up its process under pressure from the 
Mozilla and Opera reps and Invited Experts. At the time, W3C Working Groups 
were closed groups with affiliated open mailing lists for feedback and 
discussion with the public. Official WG discussions happened only on internal 
lists and public drafts were only published periodically.

> However, even in W3C where most of the work is conducted in public, the core 
> proposals for a new activity often come as a result of individual members 
> contributions. 

Often != always. Remember, your assertion was that "spec progress is 
inconceivable without work first being done internally". Quite a few CSS 
proposals were developed from discussions that started with a problem 
statement or a roughly drafted mailing list message.

> While I agree that we do not have a _/shared/_ public working draft of OFF 
> available for ongoing development (the way the work is done in W3C), I do not 
> agree that it precludes us from having a shared understanding of the current 
> state of proposed updates.

For a new feature, the lack of a shared draft is not such a huge impediment. 
Its interaction with the rest of the spec, both technically and editorially, 
has clearly delineated boundaries.

But for the sort of editorial, spec precision, and interop improvements that 
members of this group have also expressed interested in working on, it's very 
hard to manage without a shared draft. Because the individual changes are 
spread throughout the text of the spec, and they often overlay and interact 
with each other. Managing a floating collection of patches against a PDF as 
email attachments on a mailing list is not a usable process for this kind of 
work. CSSWG used to maintain a single page of errata against CSS2 and 
eventually found even that unmanageable and prone to errors.

> Also, ISO mode operandi is very different – the working drafts only exists for 
> a limited period of time when the work item is in its conception stage. Once 
> it becomes an official draft standard (and there are multiple stages the draft 
> standard goes through) – there is _/very/_ rigid process for making changes, 
> where every step is documented.

There's a rigid process to making changes to ISO's own official drafts. But 
there is no official process for how to make changes to work that you are 
preparing to submit to ISO. If you had a shared AHG draft, you could have any 
change process you wanted with it, so long as it was conformant with whatever 
licensing terms you received from its contributors.


More information about the mpeg-otspec mailing list