[rfc-i] SVG/A specification.

[Phillip Hallam-Baker <[e-mail]>]

I have not gone through every curlicue at this point, but this is the set
of requirements that I see, I am writing them out here to checkpoint the
conversation:

Archival

The RFC series is an archival series that SHOULD remain readable as
technology evolves.

Encapsulation

Published RFCs and Internet Drafts and the XML source files provided to
enable rendering in future formats MUST be presented as a single file with
no necessary external dependencies.

Interoperability

It SHOULD be possible to create RFCs and Internet Drafts using Commercial
Off The Shelf (COTS) applications and their Open Source equivalents.

Accessibility

RFCs and Internet Drafts SHOULD be presented in a format that is compatible
with the use of accessibility aids for blind and visually impaired readers.
In particular, color vision deficiency should not affect the semantics of
the documents.

Professional

RFCs and Internet Drafts SHOULD be presented in a format that meets
contemporary standards for professional publications.
Here is the outline of the SVG/A spec:

SVG is a widely supported format for representing vector graphics.

Instead of defining a new specification that refers to the SVG
specification for semantics (i.e. a profile) SVG/A is specified as a set of
restrictions on the use of SVG.

·       No external content is permitted (stylesheets, fonts)

·       The *stylesheet* element MUST NOT be present.

·       The *id* and *style* attributes MUST NOT be present.

·       The values specified in id attributes MUST be unique in the
compound document

Since the differences between SVG and SVG/A are small, it is much easier to
define SVG/A = SVG-features rather than defining a new schema.

A source SVG file MAY be converted to SVG/A as follows

1.       Parse the source file to create an XML parse tree 'the target'.

2.       Resolve all references to external resources, extract the part(s)
of the document that are referenced in the source document and incorporate
at the appropriate point in the target tree.

3.       Convert all *class* attribute values in the target tree to *style*
attribute values.

4.       Convert all *style* attribute values to the corresponding element
attributes.

5.       (Optional) Apply accessibility transformations/validations

To incorporate a set of SVG/A files 'set of input files' in an XML2RFC
source document requires the further steps of

6.       Detecting all references to document identifiers within the set of
input files.

7.       Determining which identifier values are ambiguous.

8.       Changing the ambiguous identifiers and their referents throughout
the set of input files.

Note that it is not necessary for the translation tool to be complete. It
is acceptable for the tool to reject valid SVG input provided that it does
not produce invalid SVG/A output.

It needs a bunch of wordsmithing and some details of course. But I really
don't think setting out a set of restrictions on SVG is all that
challenging. It is certainly much easier to abandon the SVG-Tiny approach
and move to SVG/A than attempting to fix the SVG-Tiny docs.

At this point, I have been focused on the problem of fixing one SVG file
rather than incorporating multiple SVG files into a single document. I need
to do these as separate passes as my source editing formats are Word/OOXML
and Markdown. I regard XML2RFC as an import/export format only.

Another advantage of my approach is that we can avoid the need to consider
which fonts are 'archival'. If a diagram uses symbols from a different
font, the specific glyphs used can be imported as SVG fonts.

What this means is that we can have high quality math in the documents
without the need for recourse to MathML which Google Chrome doesn't support
(its only 25 years since the first Math extensions to HTML were specified).