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

Phillip Hallam-Baker <> Fri, 24 January 2020 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A03EDF40729 for <>; Fri, 24 Jan 2020 09:46:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SURBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zzpay5cSZ3tC for <>; Fri, 24 Jan 2020 09:46:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 55BF5F4071C for <>; Fri, 24 Jan 2020 09:46:46 -0800 (PST)
Received: by with SMTP id p8so2393259oth.10 for <>; Fri, 24 Jan 2020 09:46:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+PPcYcZ69rAPLTRW3tIWNQww1s/u2ecHGDKp/t/STzU=; b=Wd7NSBz47eXujjdTA/3eC0gcAUt4dCeeoEg4SN1TdxwyRMNz7aoJSX7O6KvvRD9xzY M1EE7YqdfsCmKDY14KtIZRuHZH2HSo/N+xDWmc1ydemKMkX16To5TBbvOTGMwZlU2yjj +RsbpAi23r331hezGOJxAzD2pFWWmhfFFbNbYOGlyQ9QgdJfG5AK6FliYm6W2xnWsoWa xRfpFfiiv0qpNGAA9I/dm/dzFPTqREJpHFsxWJ+g2glJpbfw3Ob10aDvb5S653589V7M ImcSg3/Fbjgcdvp0jAQoLQBfotDiyE3D5QpZpME46OxQVhic1ulawIPAAtu7DTSBW1od KOsA==
X-Gm-Message-State: APjAAAV2G/IUDvEPNazXLjzdLYn+pdHNN3l9/RqYBTUb3GGb45gc19DV 7gtYQb7PJcrCdh9le4vhVx+UJf6j+zNgevujIAg=
X-Google-Smtp-Source: APXvYqxzLGEHIct7MwXT3SjYdGrS30qAxlD5JOPVhh7WAtnUQo9tWXA/2B9atIch1rhOb9svyeAOVXCtC/keVExY6A8=
X-Received: by 2002:a9d:729c:: with SMTP id t28mr599743otj.66.1579888016554; Fri, 24 Jan 2020 09:46:56 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Fri, 24 Jan 2020 12:46:45 -0500
Message-ID: <>
To: Leonard Rosenthol <>
Cc: RFC Interest <>
Content-Type: multipart/alternative; boundary="00000000000002fe40059ce6589c"
Subject: Re: [rfc-i] SVG/A specification.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jan 2020 17:46:47 -0000

On Fri, Jan 24, 2020 at 10:21 AM Leonard Rosenthol <>

> 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).
> Oh good point! Given that I am probably the person who has detested
Javascript longer than any other human being (I was at W3C when Netscape
faxed us the spec and was the first to try it there), nobody seems to have
thought it needed mentioning.

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

It presents a problem for validation and for the aggregation of XML2RFC +
SVG* to on XML document. Basically, it means that the validator has to
understand the style sheet language.

Since the output language is XML2RFC which prohibits style, it seems
simplest to simply flatten all this out.

But the original reason for this was not actually the archival part but the
accessibility part. It is much easier to restrict attributes to a limited
palette of colors if there is a single means of expressing them.

>    - If a diagram uses symbols from a different font, the specific glyphs
>    used can be imported as SVG fonts.
> 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.

So the only way to make this happen would be to expand the SVG Font
definitions inside the diagrams. Which isn't going to happen. Pity.