[wbs] response to 'Call for Review: Scalable Vector Graphics (SVG) Working Group Charter'

The following answers have been successfully submitted to 'Call for Review:
Scalable Vector Graphics (SVG) Working Group Charter' (Advisory Committee)
for Vivliostyle Inc. by Florian Rivoal.


The reviewer's organization suggests changes to this Charter, and only
supports the proposal if the changes are adopted [Formal Objection].

Additional comments about the proposal:
   This charter has the explicit goal of tightening the scope in order to
get SVG2 to REC. Getting things to REC is valuable, so I support that.

However, it order to do that, the charter orphans a number of documents,
and does so without saying what is expected to become of them or how the
documents from other WGs that depend on them are expected to manage that
dependency. Just to take one example,
https://www.w3.org/TR/svg-integration/ is left out of scope, and is not
given a new home. However, a CSS specification I co-edit,
https://www.w3.org/TR/css-ui-3/, is in CR and normatively depends on it. In
order to progress out of CR, will I need to remove that dependency? Will
some other group take over and push svg-integration along TR? I suspect
many of the other dropped deliverables will raise similar problems.

Also, the proposed charter says:

> Features removed from the specification, and new proposed features,
> may be published as Working Group Notes or incubated further
> in a Community Group or other appropriate venue.

I presume that Working Group notes are intended for "Features removed from
the specification", not for new proposed features, since the WG would not
be chartered with working on new features. That the charter is silent on
the possible addition of other deliverables at a later point seems to
confirm this point. Not identifying which alternate venue is appropriate
seems problematic to me. Not only because people wishing to make
suggestions will be confused about where to make them, but maybe more
importantly because people wishing to monitor, evaluate and respond to such
suggestions will have no way of knowing where to listen. If we expect every
little suggestion for SVG to first have to assemble a community of its own,
we are significantly raising the difficulty of participating. If we mean
that it should all go to the WICG, we should be explicit about that, both
so that we can during this charter discussion decide whether we agree with
that, and if we do agree, so that there's an official answer to the
question of where forward looking proposals for SVG should happen.

These two problems need to be addressed.

Beyond that, this cutting off most deliverables and rejection of any work
on new features make it pretty clear that this is intended as extraordinary
measures to respond to a crisis (SVG2 failing to reach REC in a timely
manner).

However, SVG2 is an enormous specification, and the charter gives an
expected completion date of Q3 2017. SVG2 reached CR for the first time
only this September. If we're less than a year away from REC, I have a hard
time seeing what the crisis is, and what justifies the strict reduction in
scope (and its side effects). More likely, the Q3 2017 estimate is
unrealistic. For a specification that size, I suspect merely cutting out
every feature that wasn't already in SVG1.1 would probably take longer,
especially if you take into account the time to assemble a test suite to
account for the normative changes in the existing features. If SVG 1.1
Third Edition is what we're after, we should be clear about that.

Maybe I am missing something that makes this target date achievable, but as
it is, it seems to me this charter is set up for failure.

Based on my understanding of the situation, I suggest:

* Putting a realistic date on SVG2 REC. Not a date by which we wished we
were done, but a date by which we expect to be done. If the realistic date
is "never" due to the lack of anybody writing tests, say so, and then work
on getting that changed.

* Saying that features dropped form SVG2 for the purpose of achieving REC
in a timely manner should be *either* turned into notes if the WG judges
that there is insufficient interest for meaningful progress or into Editors
Draft when there is. For these EDs, I would favor CSS-like small modules
evolving independently rather than a monolithic SVG3, to avoid repeating
the same problem a few years down the road.

* Reinstating the dropped deliverables and re-opening the scope to new
features propositions, albeit being extremely clear that the priority is
not on these items.

* Staffing the group (Chairs & team contacts) with people on a clear
mandate to prioritize getting SVG2 to REC over other work.


The reviewer's organization intends to participate in these groups:
   - Scalable Vector Graphics (SVG) Working Group

The reviewer's organization:
   - intends to review drafts as they are published and send comments.
   - intends to develop products based on this work.
   - intends to apply this technology in our operations.


Comments about the deliverables:
   My organization develops an HTML/CSS/SVG/MathML/... layout engine, used
to power pdf generation as well as in-browser pagination and advanced
typography. SVG is not the primary focus of our work, but is an important
part of the whole. As such, we have a stake in the evolution of the
technology, intend to occasionally participate in the development of its
specifications, and support them in our products.


Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/svg-2016/ until 2016-12-23.

 Regards,

 The Automatic WBS Mailer

Received on Thursday, 15 December 2016 09:03:39 UTC