Re: [xml2rfc] Tables in XML V3 - A downgrade

[Anders Rundgren <[e-mail]>]

On 2019-09-14 10:17, Julian Reschke wrote:
> On 14.09.2019 08:03, Anders Rundgren wrote:
>> Hi Julian,
>>
>> On 2019-09-14 07:25, Julian Reschke wrote:
>>> On 14.09.2019 07:08, Anders Rundgren wrote:
>>>> On 2019-09-13 18:45, Julian Reschke wrote:
>>>>> On 13.09.2019 17:25, Anders Rundgren wrote:
>>>>>> ...
>>>>>> Well, RFC 7997 only talks about Unicode in author-provided data
>>>>>> which is
>>>>>> not the case here.
>>>>>> The same goes for bullets lists.
>>>>>> ...
>>>>>
>>>>> I think we need to look at the role of the plain text output in the
>>>>> future. The original plan was to make it as bare as possible, not even
>>>>> paginated. Not sure why we deviated from that.
>>>>
>>>> Paginated RfcMarkup is rather reducing readability and browsers can
>>>> print fairly well these days.
>>>
>>> Print plain text?
>>
>> I just thought that pagination was intended for that purpose.
>> If not pagination has no purpose.
> 
> With all due respect, it's pretty easy to make absolute statements like
> these.

Pardon me.

> 
> The current plan was agreed upon after long mailing list discussions,
> many years ago. It's a compromise, yes.

I'm sure about it.

> 
> People in fact do like pagination, even when not printing (I don't
> belong to that group).

OK.

> It was very hard to get to where we are right
> now, where pagination is just a service for certain output formats
> (originally planned for PDF only), not something inherent in the
> canonical RFC format.
> 
> That said, I still don't understand what you're referring to when you
> say "Paginated RfcMarkup is rather reducing readability and browsers can
> print fairly well these days."

Well, having code examples and tables interspersed with pagination
information is not everybody's cup of tea :-)

Unpaginated Web pages print fairly well these days.  I believe there
even is a way to paginate specifically for printing.


> 
>>>> RfcMarkup seems to be the current standard for communicating RFC.
>>>>
>>>> Making HTML the standard probably requires more work and PIs.  XHTML is
>>>> deprecated.
>>>
>>> The "standard" is XML, in that the XML document is normative. HTML will
>>> be generated from it.
>>
>> Sure, XML is the standard for creating RFC, I was rather referring
>> to links to published RFCs used everywhere.
>>
>> HTML is currently NOT generated for V3 submissions.
> 
> I'm sure it's planned. And yes, I agree that it should happen ASAP.
> 
>>> I don't get your point about PIs, nor the one about XHTML.
>>
>>
>> Since you as an author would like your precious text to be rendered
>> as good as possible, I guess that SVG would not be a part of RfcMarkup
>> making "line-art" variants a necessity.
> 
> I do not necessarily agree that I would always supply line art as well.
> 
>> PIs could be used to keep the XML intact.
> 
> I still don't get that.

Maybe there is something I have misunderstood.

The idea is simply that there would be a single master document (in XML) that would conditionally produce different output depending on directives given by the author.

Since the transition to new formats always take long time, PIs could ease that.
> 
>> XHTML is a deprecated W3C standard currently used by RFCs.  It is not
>> a problem but switching to HTML5 is preferable.
> 
> "currently used by RFCs" where?

In RfcMarkup and HTML RFCs.

Cheers,
Anders

> 
>> ...
> 
> Best regards, Julian
>