Re: [xml2rfc-dev] <artset> feedback

Julian Reschke <julian.reschke@gmx.de> Sat, 11 May 2019 09:14 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: xml2rfc-dev@ietfa.amsl.com
Delivered-To: xml2rfc-dev@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4F120125 for <xml2rfc-dev@ietfa.amsl.com>; Sat, 11 May 2019 02:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpCFjLUPlsMl for <xml2rfc-dev@ietfa.amsl.com>; Sat, 11 May 2019 02:14:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC576120103 for <xml2rfc-dev@ietf.org>; Sat, 11 May 2019 02:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557566056; bh=9BDjjjSVGhsvpwmfyMIO8z+n2jqFTRQzrBdFP543Ksk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=FayepZDfBSbX10QYOmpiMZIILG6EAnb5uLNBvk9fPoQXeLbL004scuK9zKzop+iCS fHSEkQqyKBO6f3PwbUh8w1uPO66EGS8/axK2ygIWYDTXurYjNQdVfnDL322OFHvvd5 GDHcBRBd0MKuwEZsjDzmWIvziCnlbQuSNFb/kXn8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([84.171.150.128]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdWO8-1h4YLc0OjM-00PNuF; Sat, 11 May 2019 11:14:16 +0200
To: Henrik Levkowetz <henrik@levkowetz.com>, XML Developer List <xml2rfc-dev@ietf.org>
References: <eb78385f-9ac0-01e8-8b4a-572d8890c1a1@greenbytes.de> <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <e8791b44-738a-9ebe-946e-4b02a6635dc2@levkowetz.com> <df6742ec-d60b-0835-ad87-a297531a2771@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <fe699579-d33f-44ca-9d14-f3d99223392b@gmx.de> <a8b0cca7-4bfd-df14-c30e-fdf8bedcab90@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <ee4721b2-0add-c8ea-bd31-c2087afcbad8@levkowetz.com> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <c834e11f-640f-fb97-062b-02ed0f114953@levkowetz.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de>
Date: Sat, 11 May 2019 11:14:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <c834e11f-640f-fb97-062b-02ed0f114953@levkowetz.com>
Content-Type: multipart/mixed; boundary="------------9B4F2D92D270A8A279112E3E"
Content-Language: en-US
X-Provags-ID: V03:K1:S46Sdy/tQYp714cGt/ACBMu5fZV6Rmz6r6miF7bXe+M1zJpq6j+ QiF0Dev51dXj5RkatobMVIx65OzjYPrux5o5t8JAMwyDwwiJ3ACXlahED4IpRG2fRy4NBHX zRAnkysUhh/+bLa8IbD7ogjdUfCLtzCnQnqdsjS0Nq5x6ZI3TSpY0uGvEuUWRDpFZIxNk6b gx+rRNN6iTM+76BsZKP5w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:464JaaauJzQ=:AD+32LokvkVC0jon3EULZp RLJHhzd9nGZ40hntrhUYUZuHXEe13+ZFaBa0LR1dKL4VHEFhz4it68nBkygryOBQsACd6R0d0 z6ctU7D42oHEgD3au0pVr3EijWXwNwgs8dQ0VfIf8n8zyBeqmJZH+UFpOzmf/ThBBuWhIceVy wh3QDsGjCJmD5qDCEBifDVgUfhctZOFIejDOxzySni6tSLblz7nodRit3kq9tSv7w0S8cq9QJ p7UkkEpGHDvQ/ALxVY5kqtlqRsirld/xK7qR+i4ZenjkZXu5WG8gsb2jG/XZNxEsExZdwzyFB zvZNAG2IZ279+iFIjYiyxUH2K/X/G+lFgtbKblg+fhIo5bn7k7y8ZaWS3DMsFN6I4twf+B7/E gsvEFuPVyO3DUbFrgjO9xkk+iD/eFOayOXt+yu1amb/gO1nkPcabr71+SssxpZcDijFzGhvpV T4LVdz3t+Ilgz/mg4Jcf6VyR8OaVIrIGyN2ZwPIhst9z5uJGoh+NQAZidySSIQjMNgzVK40d3 jcijnSxEDQaqFZI72yUjom3OLuF57uvui96LrjXEAIrIafpfEIbI0U+4+O2c3y6o8LO1GrQSl fkZh7gPsRFzHX+epOknKy9U+ZVkMm1ktEh2lunZHvPuZkqc55J0j4QyqIfki5BvzXkmhECm0j /Q3BzgUYTwizc0nfOd2zPvs9MTdcIyBY+E1V5WIeK0ROAmt9cbfP8Qf5RvyBgxezpa2GJbCCx IZhTsE1anPcDCGF2GvbVxk7Cc13z5Y2NcLd08uiEu2N5V5qmdg/chzJ79gL6oeN9tN0rAa65n 2PFhTWYYfF8/8lCIbvLnQIqtn1Kd2iYZeBYD7rW7Jg5AT/TefqyVVUHxGpR2mTN5+YLOxUGtn sgqwJmglqFSyC1HbdoC0PxmOPF/nP9KZi9sy9vCr8e2rQenok+ntqwe/NGKAq0LDvWRGKoI2j SOIJiW8/jHF5rBpH/BxJhZtVr9aeLRgc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/DNjEo9JekdMoz6IfoaFIZz0O9cY>
Subject: Re: [xml2rfc-dev] <artset> feedback
X-BeenThere: xml2rfc-dev@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." <xml2rfc-dev.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc-dev/>
List-Post: <mailto:xml2rfc-dev@ietf.org>
List-Help: <mailto:xml2rfc-dev-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc-dev>, <mailto:xml2rfc-dev-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 May 2019 09:14:35 -0000

On 10.05.2019 19:17, Henrik Levkowetz wrote:
> ...
>>>> If by "v2" you refer to the spec, the answer is over here:
>>>> <https://greenbytes.de/tech/webdav/rfc7749.html#element.artwork>.
>>>
>>> No, Julian.  That is not the _spec_ for v2.  That is a retroactive
>>> best-effort attempt at describing what v2 tools did, and very useful
>>> as such.  If there is a _spec_ for the vocabulary before RFC 7991, it
>>> would be RFC 2629.
>>
>> No. The abstract says:
>>
>> "Version 2 represents the state of the vocabulary (as implemented by
>> several tools and as used by the RFC Editor) around 2014."
>
> As an analysis of the state of things, yes.  As a specification, no.
>
> What I was attempting to say in the comment above, put in different
> words, was that we've not had any _specification_ between 2629 and 7991.

That doesn't make any sense. Why do you consider RFC 2629 and 7991 as
specification, but not 7749? In particular given the fact that a large
part of 7991 is a copy if 7749????

>> So this is version 2 of the vocabulary (as spoken in 2014), opposed to
>> v1 (RFC 2629) and v3 (RFC 7991).
>
> It's a retrospective analysis of the vocabulary, yes.  And as you know,
> we've found discrepancies since it was published.  It's not the

Example, please.

> specification.  It's been very useful, but please don't try to represent
> it as something that it isn't.

It is exactly what I am saying. I don't say it is perfect, but the goal
was to specify the vocabulary in use (and implemented), and that's what
we did.

If this wasn't the case, why does it obsolete RFC 2629???

>>>> But if you refer to the v2 impl (Python-based), as opposed to the
>>>> original TCL implementation: I don't know.
>>>
>>> Ok.
>>>
>>>> That RFC was produced with
>>>> the old tool.
>>>
>>> Aha?  So that's HTML from the TCL tool, not from your XSLT processor?
>>
>> The published PDF was generated using rfc2629toFO.xslt. The published
>> text was published my submitting XML to the RFC Editor, and they
>> presumably used the TCL processor to generate nroff.
>
> I'm asking about the HTML you pointed to.

Did I point to HTML?

>> If your question is whether the TCL version processed artwork/@src: yes,
>> it did (when generating HTML). Even for SVG. Try yourself.
>
> I don't have a TCL installation which will let me do that.  Which is why
> I'm asking.

I can't produce an HTML version of RFC 5598 as I don't have the PNG
files. I can run the code an a simple example. See attachments.

Best regards, Julian