[rfc-i] SVG/A specification.

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 24 January 2020 04:07 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost []) by rfc-editor.org (Postfix) with ESMTP id 28DA5F406F7 for <rfc-interest@rfc-editor.org>; Thu, 23 Jan 2020 20:07:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -1.395
X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from rfc-editor.org ([]) by localhost (rfcpa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ETum1dVtSW_f for <rfc-interest@rfc-editor.org>; Thu, 23 Jan 2020 20:07:57 -0800 (PST)
Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com []) by rfc-editor.org (Postfix) with ESMTPS id 15DFAF406F5 for <rfc-interest@rfc-editor.org>; Thu, 23 Jan 2020 20:07:57 -0800 (PST)
Received: by mail-ot1-f53.google.com with SMTP id r27so446741otc.8 for <rfc-interest@rfc-editor.org>; Thu, 23 Jan 2020 20:08:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gGc/rVZRQmd2LTUMMoCWe19pTP5GLcblm1AicVCrFQs=; b=l1kqFV2bSfOYvuVm9Xb/wGFK7UpczVU0wdpFxu4Q7GWjfx+xpxDRl5LC4cxFNHigDA AjvHQL04aCmUfIetXRtW6/cWvHzX/2UVSCGaPjmslcXd4w8AM6aV3kPXhpMOWvRN22Z5 EHp+T3KIjOgon+zqwILtixZ4CRxwgh0JUsUlOXnOwLx4NgdR/zAdODE7n41QLkZ5eFSM gGS8pjdZN0igWxpWVCyuTz/oZb0yu0rU8VctnR3xZuCj2M3QDCV9O9NJd3nkLbwxCi4j B00V2Z/tbuBCaZEBfSb1tz7688QKcz6aFrRd8FStidSshGzFes4WYgO+SHdM5jcB4ZpF mCwQ==
X-Gm-Message-State: APjAAAVdPnAg0cHknk0t6RClSZTHaFqCj4WkGMKj+Gwxjl0cTc+Gleom iTx9HIxChJNYDgQZSk8IhfARCr60mMKljHhuyL1F2Tuatv4=
X-Google-Smtp-Source: APXvYqzL1TQYZmzrVMoC9fmUQUzkG7R0wTl9dygFhXJHMe81i+8qnRTovH3mA8RSwzfAVE07V9pKC1RVwYPDzEdR8t0=
X-Received: by 2002:a9d:7c8a:: with SMTP id q10mr1244141otn.124.1579838886456; Thu, 23 Jan 2020 20:08:06 -0800 (PST)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 23 Jan 2020 23:07:55 -0500
Message-ID: <CAMm+LwhRoycA5Dn-SmhTWGizRcxe5i_9nGPbcs=6MYkfGS4SWQ@mail.gmail.com>
To: RFC Interest <rfc-interest@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000a1314c059cdae748"
Subject: [rfc-i] SVG/A specification.
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2020 04:07:58 -0000

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


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


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.


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


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.


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

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).