Re: [xml2rfc-dev] <artset> feedback

[Henrik Levkowetz <[e-mail]>]

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

Could you be slightly more specific?  Which document are you talking
about?  

> /me shakes head

Interesting approach to what ought to be a reasonable discussion.

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

So it's a description of the status quo at a particular point in time?

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

You're asking for something that would break existing xml?

The current xml2rfc understands both, and the v2v3 converter converts
quote-title to quoteTitle; if you're asking for more, you're asking for
intentional breakage.

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

Ahh, but I think it is.  Difference of opinion, here.

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

So there's a lot of the vocabulary that is marked deprecated.  I'll just
permit all of that in pure v3 too, then?

I understand that you don't like <artset>.  You've said so repeatedly, and
it looks as if you can't let it go.  I'm fine with you having that opinion.


	Henrik