Re: [xml2rfc-dev] <artset> feedback

[Julian Reschke <[e-mail]>]

On 11.05.2019 12:15, Henrik Levkowetz wrote:
> ...
>
> 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 the HTTP specification is a description, not a specification?

/me shakes head

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

As far as I recall, quote-title was introduced while 7749 was in the
works, and we consciously limited it to what was implemented when the
work started.

We did indeed look at quote-title, found that the name was inconsistent
with the remainder of the vocabulary, and picked quoteTitle instead (in
7791).

I still don't understand why you just don't fix it in your
implementation according to the spec.

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

Good catch. So the TCL code did something weird here (also not what it
said it does in
<http://svn.tools.ietf.org/svn/tools/xml2rfc/archive/README.html#anchor10>)

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

That's nice but I don't think it's sufficient.

This simply is and had been valid input, and there is no reason not to
support it in v3. Well, except to justify the introduction of <artset> :-)

Best regards, Julian