Re: [xml2rfc-dev] <artset> feedback

[Henrik Levkowetz <[e-mail]>]

On 2019-05-11 11:14, Julian Reschke wrote:
> 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????

I think it's a matter of an understanding of words.  A specification is
what's written before you build something, it is a controlling document.

If the software comes first, and is the controlling factor, what you write
is a description.  You can't put something into the description that
differs from what the already built software does, and then turn around
and say that the software doesn't conform.  So it's not a specification
of what the software should do, it's a description of what the software
is already doing.

If you intend to build a new instance of the software, then you can say
that the description of the old software is to be the specification of the
new instance.  Then you've elevated it to the controlling document for the
new instance.  But it's still just a description of the old instance, not
the specification for it.

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

You have the errata, of course, and there are a few things I've mentioned
to you in email over the years.  I can go and dig in old emails.

Oh, I recall one; xml2rfc already had 'quote-title', but you didn't mention
that in RFC 7749; as a result, RFC 7991 introduced 'quoteTitle'.

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

The goal was to describe the vocabulary, and that's what you did, to some
extent.

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

I believed you did, but I may have found that on my own.  Apologies.

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

Ok, so when producing HTML output, the TCL code included both the external
graphics pointed at by the "src" attribute _and_ the <artwork> text content.

(There's another discrepancy for you, by the way.)

I'll adjust the v2v3 converter to produce <artset> in the v3 output when it
comes across both "src" content and inline content in the v2 input.


	Henrik