Subject: [xml2rfc-dev] --table-borders

From: Miek Gieben <[email-masked]>
Date: Tue, 25 Jan 2022 10:26:33 +0100

Hello,

xml2rfc has gained a --table-borders flag, which changes how tables are rendered (in text,
didn't check the html). There is another way of changing how a document looks and that is
the indexInclude attribute in the <rfc> tag.

I think/feel that any option that changes the look of the document should be included in
the rfc tag? Or that we default to only one way of doing things. I.e. indexInclude only
works when there are <iref>s so why not make it always true? This might involve more
discussion for table borders...

Regards,

/Miek

--
Miek Gieben

---

From: Kesara Rathnayake <[email-masked]>
Date: Wed, 26 Jan 2022 17:48:39 +1300

> discussion for table borders...

--table-borders flag only has visible differences in text mode [1].
Shall we stick with one border style for text outputs and get rid of 
this flag?

   --Kesara

[1] 
https://trac.ietf.org/trac/xml2rfc/browser/trunk/cli/tests/valid/manpage.txt#L4159

> Regards,
> 
> /Miek
> 
> -- 
> Miek Gieben
> 
> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev
> 

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Thu, 27 Jan 2022 10:38:11 +1300

> On 26/01/2022, at 5:48 PM, Kesara Rathnayake <[email-masked]> wrote:
> 
> 
> 
> Shall we stick with one border style for text outputs and get rid of this flag?

Personally speaking, I agree with Miek that all formatting should be controlled within the document and not externally in the tool.  So yes, it should go and if the functionality is needed then it should be a new language feature.

Jay

> 
>  --Kesara
> 
> [1] https://trac.ietf.org/trac/xml2rfc/browser/trunk/cli/tests/valid/manpage.txt#L4159
> 
>> Regards,
>> /Miek
>> -- 
>> Miek Gieben

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Jan 2022 15:55:18 -0600

> Personally speaking, I agree with Miek that all formatting should be controlled within the document and not externally in the tool.  So yes, it should go and if the functionality is needed then it…

That was an anti-goal of the 779* design work, which intended to have 
the xml capture the semantics of the document, and not provide layout 
instructions. If we do as you suggest, that's a big shift in 
requirements on the vocabulary, and pushes for much more frequent 
vocabulary version changes does it not?

There will also be (and have been) arguments about including _anything_ 
in the vocabulary that would influence the behavior of only one of the 
renderers.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Jan 2022 23:41:43 +0100

On 26. Jan 2022, at 22:38, Jay Daley <[email-masked]> wrote:
> 
> Personally speaking, I agree with Miek that all formatting should be controlled within the document and not externally in the tool.  

+1.

> So yes, it should go and if the functionality is needed then it should be a new language feature.

Somebody wanted the —table-borders feature, or it wouldn’t have been implemented.
It would be interesting to find out for what document, but since the information is not in the documents, that may be hard to reconstruct.

Do we know if any RFCs are rendered with that feature?

What does the feature look like?  Too lazy to look it up/try it out at the moment.

Anyway, having a global flag on a document that changes formatting for all tables in that document is unspeakable.
Of course, it works for trivial documents that have only one kind of table in it.

Yes, information of this kind needs to be kept with the individual elements of the document that receive the alternate formatting.
Of course, we already have attributes for similar cases in the grammar, e.g. dl/@spacing (and, one could argue, dl/@newline), ol/@indent, ... — I didn’t try to make an encyclopedic list, but the ideology of semantic markup falls a bit short when one-size-fits-all formatting doesn’t quite work.

The fact that, without Henrik, we have grammar ossification, means that we probably can’t fix anything before we get a v3.1.
Let’s not forget to put these things in when it finally comes to that.

By the way, “tweaks" like this were one of the original motivations for having processing instructions in SGML…

Grüße, Carsten

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Jan 2022 16:48:08 -0600

> Somebody wanted the —table-borders feature, or it wouldn’t have been implemented.
The RPC asked Henrik to implement it as an experiment for a document, 
and it ended up not being used.
> Do we know if any RFCs are rendered with that feature?
None have.
> Anyway, having a global flag on a document that changes formatting for all tables in that document is unspeakable.
Yes, that's why it wasn't used, ultimately.
> Let’s not forget to put these things in when it finally comes to that.

Well, it's not the lack of Henrik that has the grammar stuck - we 
_could_ start making changes, but the team put together by RSOC to 
figure out where the grammar should be going decided we should nail down 
the next grammar before moving the ball under the decision of what the 
next grammar should be.

I'm personally in the camp that the grammar should be allowed to change 
early and change often, with good versioning, but I'm very much in the 
minority.

---

From: Jay Daley <[email-masked]>
Date: Thu, 27 Jan 2022 11:52:38 +1300

Double response:

> On 27/01/2022, at 10:55 AM, Robert Sparks <[email-masked]> wrote:
> 
> 
> That was an anti-goal of the 779* design work, which intended to have the xml capture the semantics of the document, and not provide layout instructions. If we do as you suggest, that's a big shift in requirements on the vocabulary, and pushes for much more frequent vocabulary version changes does it not?

We have features such as the newline attribute in the <dl> element that appear to be layout only and Carsten has listed some others below.

> 
> There will also be (and have been) arguments about including _anything_ in the vocabulary that would influence the behavior of only one of the renderers.

We already have that with the type="svg" attribute of the <artwork> element, which is arguably has a much bigger impact than a table border.

> On 27/01/2022, at 11:41 AM, Carsten Bormann <[email-masked]> wrote:
> 

We have the XML and Style Guide Change Management Team https://mailarchive.ietf.org/arch/browse/xml-sg-cmt/

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Jan 2022 07:40:14 +0100

Am 26.01.2022 um 23:52 schrieb Jay Daley:
> ...

That is true, but we really tried to minimize the number of knobs.

*If* we want to provide some control over table styling, a single binary
switch won't be that helpful. Note that we had many more in V2.

> We already have that with the type="svg" attribute of the <artwork> element, which is arguably has a much bigger impact than a table border.

I don't think this falls into the same category.

>>> So yes, it should go and if the functionality is needed then it should be a new language feature.

At least we shouldn't get us into a situation where there's extra
metadata needed to create the RFC TXT versions (thus all of these should
be the same).

>...
 > ...

It would be awesome if the visibility of this would be greater. I really
would like to be able to at least *subscribe* to this mailing list so
that I see what's currently discussed.

Just in this month I see a re-opening of an issue (<postal>) which was
supposed to be closed with consensus many months ago, and a discussion
about referenceGroup titles that's related to a vocabulary ticket I
opened over five years ago.

Best regards, Julian

---

From: Alice Russo <[email-masked]>
Date: Fri, 28 Jan 2022 11:22:49 -0800

> On Jan 26, 2022, at 2:48 PM, Robert Sparks <[email-masked]> wrote:
> 
> The RPC asked Henrik to implement it as an experiment for a document, and it ended up not being used.

To clarify, I submitted this ticket (https://trac.ietf.org/trac/xml2rfc/ticket/527), and -- in addition to the corresponding fix -- the table-borders option was created. IIRC, the RPC did not ask for the feature. 

As noted, it has never been used for producing an RFC.

Thanks,
Alice

---

From: Robert Sparks <[email-masked]>
Date: Fri, 28 Jan 2022 13:38:40 -0600

> To clarify, I submitted this ticket (https://trac.ietf.org/trac/xml2rfc/ticket/527), and -- in addition to the corresponding fix -- the table-borders option was created. IIRC, the RPC did not ask f…
Thanks for the clarification and apologies for my misrepresentation.