--On Thursday, October 29, 2020 10:48 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 10/29/20 6:04 AM, Julian Reschke wrote:
>
>>> At the I-D stage page numbers are useful because people send
>>> diffs and you need to context to get to the right place in
>>> the .xml.
>>
>> How do page numbers help with the XML? Aren't section and
>> paragraph numbers much better for that?
>
> Given that none of section, paragraph, or page numbers appear
> in the XML, I don't see how any of them helps with that
> problem. But it is a real problem.
Actually, Keith, some of us manage to put comments in the XML
that make relevant material easy to find. Sometimes those
comments might actually be section or other numbers, others
might be convenient terms for searching, a function that short
names for sections (the same names that might be used for
anchors) may also serve.
See below.
> (IMO, XML is a horrible format for document authoring/editing.
> It optimizes for all of the wrong things and imposes a
> considerable burden on writing and maintaining drafts,
> especially for newcomers.)
Well, first of all, while I acquired it long ago (IIR, before
there was an IETF), I still believe that generic markup is an
acquired taste. For my particular taste, relatively purely
generic forms are better than hybrids, but that is also a matter
of taste-- and a different discussion. So, of course, are
format markup, various flavors of assisted or unassisted WYSIWYG
editors (with or without subsequent machine translation to XML),
and writing I-Ds in advanced plain text editors of the vi or
emacs persuasions.
Of those options, the format markup is the only one that is
probably unsuitable if we are trying to support availability of
multiple output formats as long as the RFC Editor is willing to
accept plain text input (and even that might be ok if the plain
text output is produced first). IMO at least, we should be
pleased that we have multiple input arrangements and sets of
tools available so that, if you (or I or someone else) doesn't
like one option, they can chose another and get on with the
IETF's substantive technical work. That seems to me to be, to
partially paraphrase Warren, far more productive than
conversations about how one method is better and more virtuous
than another and hence that people who prefer something else
should Feel Bad about it.
What Warren didn't say but someone probably should is that
--using the two of us and this particular case as an example--
if you felt that my life would be immeasurably improved if I
switched away from XML, I'd be quite interested in understanding
why. But let's do that off-list because that discussion would
necessarily draw on our long friendship and knowledge of each
other's backgrounds and history. The same discussion would
likely be irrelevant to others.
As others have pointed out, this is not really related to the
current thread, but there is one way in which it is. IMO, the
fundamental issue about choices of input formats and tools is
nearly the same as the fundamental issue about choices of output
formats. A discussion among people who prefer to work with
plain text (sometimes or always) about what the details of that
format should be is useful. A discussion between then and
people who believe the format is obsolete or backward or
destructive and that people should feel bad using it is much
less likely to be useful in sorting details of the plain text
form.
And when people can't even discuss such a format without use of
metaphors whose intent seems to be to be demeaning of the format
and to make those who use it feel bad ("dead trees versions"
comes to mind regardless of the merits of the associated
comments) then not only does it not help with constructive
suggestions or moving toward consensus, but leads to wondering,
given our supposed policies, where the SAA team is. At the same
time, their intervention is unlikely to move the conversation in
constructive directions.
Jay, I copied you explicitly on this because, while I'll try to
find time in the next few days to go through your survey, I want
to make an observation after looking at the first page, one that
relates critically to the comments above: at least IMO, the best
interests of the Internet and the IETF are going to be best
served by being as inclusive as possible, including inclusive of
people with different backgrounds, habits, and consequent
preferences about tools and ways of working. If we say that we
ran a survey and the vast majority prefer method A or B and
hence we are going to concentrate our energy and resources
there, we need to understand that people who prefer method C or
D (or who have attitudes toward A and B more negative than those
Keith expresses above about XML) are as likely to drop out and
go elsewhere than to learn, and become enthused about, A or B.
And that situation could be even worse if there is only an A and
no B. Were this or other things to leave an IETF that was a
wonderful place for people with one type of history, work
styles, and preferences to do their work but with everyone else
shut out, its opinions and consensus would not be worth much
consideration by the wider world and it would basically not be
worth the resources to keep it going. No one issue or decision
is likely to produce that outcome, but, again IMO, it is more
important to concentrate on preserving diversity along those
dimensions (not just demographic ones) rather than asking
questions about the preferences of those who happen to be active
now and assuming the answers tell us where we should be going.
Certainly there are resource and common-sense limits on how far
we can or should go but caution about doing a survey and then
going with majority opinions or practices would seem to be in
order if only because, almost by definition, you aren't going to
hear from those who have walked away.
best,
john
