Subject: [Xml-sg-cmt] What to focus on for our first meeting this year?

From: Robert Sparks <[email-masked]>
Date: Wed, 6 Jan 2021 14:44:14 -0600

We will be meeting in just under two weeks.

At the end our last discussion, we said we'd first tackle what the RPC 
should focus on wrt using the v3 grammar.

Our output is expected to guide how the RPC spends its time, and inform 
RSOC's efforts in determining the structure of the next SLA between the 
LLC and the RPC.

I've been thinking about how we can make progress on that and I'd like 
to try making a slight change to how we've been talking about this so far.

Providing guidance to the RPC will be an ongoing effort - there's a 
notion of "done" (that is, the guidance is complete) that's expected for 
informing the SLA that I think is unrealistic to attain. It's tempting 
to conflate this with having the next update to the grammar document 
published, but that is really a different set of decisions. Even during 
periods where we might have a frozen grammar, guidance on how to work 
within it will be an ongoing concern.

So, I think we need to work to get the RPC, RSOC and other parties with 
interest comfortable with what the RPC's _principles_ on spending time 
on are for the next year or so. It would be realistic to set an SLA 
based on that, with the expectation that the SLA should be revisited as 
we get more experience.

The specific questions in front of us can the RPC refine those principles.

One large point from recent conversations I'd like to highlight:

One time consuming activity identified has been experimenting to see if 
the RPC can get the author's desired output by trying different grammar 
representations, or deciding that not matching their desired output (or 
provided input, particularly in .txt form) is ok.

The intent of the design team was that the grammar not determine layout 
in any given format. It captures semantics. The renderers transform 
those semantics into layout. Consequently, effort put into changing the 
xml to get a particular bit of indentation in the txt output, for 
example, is risky. The renders can, and I argue _will_, change their 
behavior later, and re-rendering will produce something that doesn't 
reflect such efforts.

I recognize that we've strayed already into specifying layout metrics 
within the document with the added "indent" attributes. We'll be 
reviewing later whether we keep those. (I think we will). I expect we'll 
have to make other pragmatic decisions going forward about other places 
where we allow specifying parameters that are intended only for the 
renderer's use.

But focusing on the time the RPC spends experimenting to get a 
particular output: I suggest that such time be minimized. Only go as far 
as to say "this can't be easily done" and move on, even if the rendering 
is not aesthetically as nice as the RPC or the authors want. Focus on 
capturing the semantics so that future renderers can do a reasonable 
thing. Pass requests for "better" to the tools team, publish with what 
you have, and move on. I make this suggestion because, as I note 
earlier, longer effort is likely wasted - the changes seen in the output 
as the renderers work today may not be the same as they work later.

In other words, as a _principle_, the RPC shoudn't be trying different 
workarounds to affect how the output looks document by document. If the 
formatters aren't making it easy for frequently desired things to 
happen, that should be reported, and time should be spent getting more 
documents out. Specifically, this means accepting publication of some 
things that might not be as aesthetically pleasing as wanted.

If that's an unpalatable, or even unacceptable, suggestion, (or if you 
think my view is just incorrect) we need to work through that first 
before any of the other guidance we might provide can have any lasting 
value.

To make sure I'm not misunderstood - the time the RPC spent over the 
last several months exploring and helping invent such workarounds was 
absolutely appropriate, necessary, and very useful. But I think we're at 
the point of diminishing returns in the publication flow, and that the 
time spent doing such things should taper to a minimum.

RjS

---

From: "John R Levine" <[email-masked]>
Date: 8 Jan 2021 15:25:17 -0500

> RSOC's efforts in determining the structure of the next SLA between the LLC 
> and the RPC.

Having talked to RSOC members and the RPC, I'd like us to redirect our 
efforts somewhat.  We have an interim SLA, and the main thing that needs 
to happen is to nail down the final v3 grammar so we can update the 799x 
RFCs.  I think the RSOC also agrees we can update the XML in published 
RFCs to match the grammar, so long as the text doesn't change.

I hope this group is the core of the people to do this.  If not, who is?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 8 Jan 2021 15:45:18 -0500

On Wed, 6 Jan 2021, Robert Sparks wrote:
> The intent of the design team was that the grammar not determine layout in 
> any given format. It captures semantics. The renderers transform those 
> semantics into layout. Consequently, effort put into changing the xml to get 
> a particular bit of indentation in the txt output, for example, is risky. The 
> renders can, and I argue _will_, change their behavior later, and 
> re-rendering will produce something that doesn't reflect such efforts.

Having been around this barn a few times when I was writing books, this is 
an insoluble problem.  No set of tags can capture the semantics of a 
document enough to typeset it attractively.  When I was doing Dummies 
books, we had a very simple style and a very complete set of tags, but 
there was still a department hand-adjusting the layout on pages.

On the other hand, I completely agree that tweaking the tags to make one 
rendering look good is fragile and not a good use of people's time.  We 
gave up and added explicitly indented paragraphs after the RPC faked 
thousands of them using unnumbered lists.  I think that if you look at the 
places where the unnumbered lists and now indented paragraphs appear, a 
lot of them could plausibly have semantic tags such as TOC entries (which 
I'd say really are unnumbered lists), but many others just look better 
with the text indented with no obvious semantics.

I don't think we can commpletely forbid layout tags but I do agree we 
should limit them, and we should definitely avoid trying to make 
specific formats look nice.  PDFs are a particular point of uglitude but 
when I asked the RPC a few days ago, they said they think the issues are 
all that they just look ugly, not misleading.

Regards,

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Jan 2021 12:16:30 -0600

On 1/8/21 2:25 PM, John R Levine wrote:
>> Our output is expected to guide how the RPC spends its time, and 
>> inform RSOC's efforts in determining the structure of the next SLA 
>> between the LLC and the RPC.
>
> efforts somewhat.  We have an interim SLA, and the main thing that 
> needs to happen is to nail down the final v3 grammar so we can update 
> the 799x RFCs.

So how do we prepare for Monday?

Shall we start by going trough Henrik's implementation draft in order, 
or do you want to prioritize discussion of the changes?

I'd still like to have a github issue tracker for this that's likely to 
live longer than the bis effort - unless you have a place to create a 
new repo for it in mind, I'll create a new one.

> I think the RSOC also agrees we can update the XML in published RFCs 
> to match the grammar, so long as the text doesn't change.
That's a separate discussion - I'm not sure the cmt has a stake in it, 
but as an individual, I'd advise reconsidering. Doing this without 
author review (the equivalent of an auth48) will trigger appeals. Doing 
it _with_ an auth48 stage will have other consequences.
> I hope this group is the core of the people to do this.  If not, who is?
At the moment we've been created to evaluate and manage changes to the 
grammar and style guide. We are the correct group to go through the 
changes in Henrik's draft and the other things marked (new) when you ask 
xml2rfc to emit its current grammar.

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2021 13:47:09 -0500

On Wed, 13 Jan 2021, Robert Sparks wrote:
>> efforts somewhat.  We have an interim SLA, and the main thing that needs to 
>> happen is to nail down the final v3 grammar so we can update the 799x RFCs.
>
> Shall we start by going trough Henrik's implementation draft in order, or do 
> you want to prioritize discussion of the changes?

I'd like to start by being sure we have a complete list of changes to 
look at.

Also, I think we should revisit the RFC 7998 point that says that the 
preptool fills in all the defaults in case the defaults change.  As far as 
I know, the defaults haven't changed and this bloats the final XML.  Also, 
for <t> in our published RFCs we now have 23,000 <t> tags with no indent 
attribute, and 11,000 <t indent="0">.  One of those has to be wrong.

> I'd still like to have a github issue tracker for this that's likely to live 
> longer than the bis effort - unless you have a place to create a new repo for 
> it in mind, I'll create a new one.

Sure, go ahead.

>> I think the RSOC also agrees we can update the XML in published RFCs to 
>> match the grammar, so long as the text doesn't change.
> That's a separate discussion - I'm not sure the cmt has a stake in it, but as 
> an individual, I'd advise reconsidering. Doing this without author review 
> (the equivalent of an auth48) will trigger appeals. Doing it _with_ an auth48 
> stage will have other consequences.

I plan to socialize it and see who objects, and how serious their 
objections are, keeping in mind that their text won't change.  For an 
archival series I think it is important to have a well defined grammar and 
documents that match the grammar.

Finally, I think we should invite Julian Reschke to join this group since 
he knows way more about XML than I do and has been working with me on 
7991bis.

Regards,

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Jan 2021 20:12:17 +0100

On 2021-01-13 19:47, John R Levine wrote:
> I know, the defaults haven't changed and this bloats the final XML.

Not filling in the defaults results in the published XML file not being
standalone any more -- information outside of the published XML (the schema
at the time of publication) is needed in order to render the xml correctly.

My understanding is that this goes directly against the intention in having
the published XML be the authoritative source.

>  Also, 

Unfortunately, Julian doesn't do discussion and consensus work well.  He
doesn't listen to reasonable arguments; he cannot be made to see the point
of view of anybody but himself; he can only be overruled.  I had to stop
discussing the changes proposed in my implementation notes draft on the
mailing list because it was never possible to find common ground with Julian.

His refusal to agree to anything but his own initial positions probably
delayed the implementation work by as much as 6 months filled with frustration
and despair.

	Henrik

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2021 14:14:27 -0500

> the published XML be the authoritative source.

I'm assuming the final v3 schema is fixed, so there aren't multiple 
schemas to choose from.

> mailing list because it was never possible to find common ground with Julian.

I have no trouble working with Julian.  It's up to you whether you want to 
be part of this process.

Regards,

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Jan 2021 13:25:32 -0600

> I'm assuming the final v3 schema is fixed, so there aren't multiple 

That is a fundamental assumption and I don't think it's tenable.

We are, for example, discussing adding the ability to express math.

The _near_ future will bring us more changes that we will feel are 
necessary.

The schema will be a thing that evolves, and it should be allowed to 
evolve in something less than big cliffs decades apart.

The idea that we can have a static schema that will endure for a period 
of years is, in my opinion, a fallacy.

> I have no trouble working with Julian.  It's up to you whether you 
> want to be part of this process. 
>
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2021 14:28:28 -0500

>> I'm assuming the final v3 schema is fixed, so there aren't multiple schemas 
>> to choose from.
>
> The _near_ future will bring us more changes that we will feel are necessary.
>
> The schema will be a thing that evolves, and it should be allowed to evolve 
> in something less than big cliffs decades apart.
>
> The idea that we can have a static schema that will endure for a period of 
> years is, in my opinion, a fallacy.

Well, OK.  But are we likely to add anything that changes the defaults? 
If we add math, that's going to be new elements added to the schema.

Still thinking about 20,000 <t> with no defaults and 10,000 with.

Regards,

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Jan 2021 20:35:39 +0100

> I have no trouble working with Julian.  It's up to you whether you want to 

My take from this is that what you're really saying here is that 1) you are
the one who decides on the membership of Xml-sg-cmt, and 2) you would like
to not have to deal with me on the Xml-sg-cmt, and if pulling Julian in
forces me out, then that's just fine?

	Henrik

---

From: Robert Sparks <[email-masked]>
Date: Wed, 13 Jan 2021 13:40:57 -0600

On 1/13/21 1:28 PM, John R Levine wrote:
>> The idea that we can have a static schema that will endure for a 
>> period of years is, in my opinion, a fallacy.
>

I think the right question is more whether we are likely to decide that 
any of the other defaults are something we want to change? I think we 
would have to carefully review the grammar and think hard about each 
such place. I am not comfortable with a handwave that nothing would 
change, even in the short run.

> If we add math, that's going to be new elements added to the schema.
And arguably (I think Julian would agree here), a new schema _version_.
> Still thinking about 20,000 <t> with no defaults and 10,000 with.

And remember that bad cases make bad law.

We've crossed the line (necessarily as you point out) where we've let 
formatting instructions enter the grammar. _Those_ things, if we get 
more of them, are the most likely to have default changes going forward.

I'm personally comfortable with making not including indent=0 a 
well-known exception, at least in the short run. Anyone building a 
formatter will quickly figure out what to do with that. But it is 
_messy_ from an archival point of view.

The argument from long ago, which maybe should come up again, is having 
a more granualar statement of what version of the grammar was used in 
the xml and an archive (long term archival quality) of what those 
versions are.

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2021 20:13:17 -0500

On Wed, 13 Jan 2021, Robert Sparks wrote:
> I think the right question is more whether we are likely to decide that any 
> of the other defaults are something we want to change? I think we would have 
> to carefully review the grammar and think hard about each such place. I am 
> not comfortable with a handwave that nothing would change, even in the short 
> run.

That makes sense, to look and see if there are defaults that don't look 
like they're permanently correct.

> And arguably (I think Julian would agree here), a new schema _version_.

Dunno, I'll ask him.

Regards,