Re: Clean-up SVG2 spec

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.

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

Received on Wednesday, 21 May 2014 08:27:41 UTC