Re: [rfc-i] SVG/A specification.

[Leonard Rosenthol <[e-mail]>]

Since you (assumedly) named this to align with PDF/A (the archival subset of PDF), then since I am the project leader for PDF/A, I think it’s only appropriate for me to weigh in.

Given your definition of archival (which seems fine), I believe that you have not fully thought through all of the requirements necessary to achieve that.


  *   Encapsulation.
     *   Great starting point and your definition aligns well with PDF/A.  However, your implementation does not.  For example, you allow for fonts by reference – which is not permitted in PDF/A (and was, IIRC the first requirement that was ever put into that standard).  All font information *must* be embedded, since is impossible to determine what fonts will be available at any time in the future.   This is especially true for any font/content that uses “special areas” of Unicode such as math.
  *   Accessibility
     *   You aren’t actually doing anything here to address this.  Where are you requirements around associating alt text (at a minimum)?  If you are going to call this out, if nothing else, you need to at least point to WCAG requirements here.  Either that, or I recommend you drop this requirement.

You are also missing a key requirement:


  *   (No) Scripting
     *   Removing any scripts that could change the content in the future was the #2 requirement applied to PDF/A and I would say also needs to be applied to RFC’s.  Not only to prevent content changing but also to prevent an RFC from accessing a remote site when being viewed (which also falls into the “encapsulation” category).


Also, you have some requirements that don’t have anything to do with archival requirements and AFAICT serve no useful purpose.

  *   The stylesheet element MUST NOT be present.
  *   The id and style attributes MUST NOT be present
Why??   As long as everything is internal and does not include scripting – what is wrong with CSS/stylesheets?   Same with the style & id elements?   They are all perfectly valid and archival.


  *   If a diagram uses symbols from a different font, the specific glyphs used can be imported as SVG fonts.

SVG Fonts (https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/SVG_fonts) are not supported by any modern browsers and should not be used.  However it is possible to embed fonts into an HTML/SVG files, conceptually as one does with PDF.


Leonard


From: rfc-interest <[e-mail]> on behalf of Phillip Hallam-Baker <[e-mail]>
Date: Thursday, January 23, 2020 at 11:08 PM
To: "[e-mail]" <[e-mail]>
Subject: [rfc-i] SVG/A specification.

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