Re: Clean-up SVG2 spec

On Wed, May 21, 2014 at 1:21 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On May 21, 2014, at 10:26 AM, Charles Lamont <charles@gateho.gotadsl.co.uk>
> wrote:
>
> > There are two related issues here. The first question is about how to
> > write specs. Dirk says "We should remove all redundancy." and David says
> > "Ease of use of a spec by authors is a fundamental concern." More of
> > this in a minute.
>
> I disagree. There is no point in having redundancy to CSS for neither
> implementers nor authors. In fact, the redundancy is in comparison to CSS
> 2.0. Many things have been fixed and continue to be improved. Instead of
> merging all these changes back and significantly increase the spec text to
> cover everything from CSS 2.1 (very soon CSS 2.2), all CSS3 specs and all
> new specs is illogical. Instead we should create a global environment where
> SVG fits in to. CSS does that by creating modules. Pulling all these
> modules back into SVG would increase the size by a magnitude. How can this
> be readable for implementers or authors?


I agree with Dirk that having redundancy makes things more difficult for
editors, authors and implementors.
In addition, if there's a change or addition to a CSS module, someone would
have to change the SVG spec in tandem. This is error prone and will also
make it so the SVG spec gets revised constantly.

Personally, I'd like us to focus on writing a spec for implementors. The
newer spec are designed with precise normative descriptions of the
algorithms and non-normative introductions and examples.
This way, we can spend all our time in the WG on refining the algorithms
and normative text while changes to examples and the introductory text for
authors can be made at any time.


> >
> > The second matter, raised by David, is about the philosophy and history
> > of the SVG specification process. I have always shared his misgivings
> > about devolving a lot of SVG into CSS. There is frequently no logical
> > differentiation between 'style' and 'content' in a graphic work, and
> > dividing one visualisation into two completely different document
> > structures under two different sets of standards does not make the
> > creation or maintenance of an image easier to understand or do. On the
> > other hand I understand the reasons for the split. In any case, it is a
> > fait accompli, and we probably have to live with it, start again from
> > scratch, or wait until someone comes up with the brilliant idea of
> > merging the two streams.
> >
> > So, how does the second question impinge on the first? From the point
> > of view of creating and maintaining the specifications, they should be
> > terse, orthogonal and complete. The spec should be a reference, not a
> > handbook. However, the convenience of the specification's creators is
> > secondary to that of its audience, and the target audience should be as
> > broad as reasonably achievable. The complications arising from needing
> > two systems at once need to be mitigated. The SVG specs need to make it
> > clear what aspects of the image they define, what (kinds of related
> > thing) they do not set out to define, and where to look. They needs to
> > explain why so much of what will be needed is in CSS rather than SVG.
> > Section by section indication would probably be helpful, but a
> > fine-grained cross-reference to each detail would be onerous to
> > maintain and might compromise readability. Diagrams might help.
> >
> > -
> > Charles Lamont
> >
>
>
>