Re: On XML and $EDITORs (Re: Things that used to be clear (was ...)) "Living Documents") side meeting at IETF105.)

[Nico Williams <[e-mail]>]

On Wed, Jul 10, 2019 at 06:09:00AM -0400, Keith Moore wrote:
> > Office and LibreOffice use XML too, but users don't see it.  That's
> > what I meant by "webby $EDITOR tooling" above: a bloody real UI, a
> > browser UI.
> 
> While that's probably better than editing raw XML, I'm unfavorably
> impressed with UIs for editing XML (and that includes UIs that edit
> HTML and variants thereof).  [...]

When I use LyX to write I-Ds, I never see either the raw .lyx or the raw
.xml that is produced by lyx2rfc.  I do submit the XML lyx2rfc produces,
naturally, but I don't look at it.  Instead I review the rendered
output.

That's what a good $EDITOR for I-Ds and RFCs should be like to use.

>                      [...].   A possibly familiar example of what I'm
> talking about: you're editing a document that is internally
> represented by HTML or XML and trying to delete white space between
> two chunks of text that are at different levels of hierarchy.   All of
> a sudden you've "deleted too much" - the visual difference between
> those two chunks, that reflects the difference in the XML hierarchy,
> disappears.   You weren't trying to collapse the hierarchy, you were
> just trying to get rid of distracting and meaningless white space.  

I've never had this problem with LyX.  That's because it's NOT a WYSIWYG
editor by a WYSIWYM editor, and among other things does not let you add
arbitrary amounts of whitespace accidentally.

Maybe I should make it a point to attend a meeting and hackathon just to
showcase LyX and lyx2rfc live, so y'all believe me...  There's
screenshots in https://github.com/nicowilliams/lyx2rfc and you can find
videos of people using LyX with searches like: https://www.youtube.com/results?search_query=LyX

> Or a similar problem - you /want/ extra white space, say, between
> items in a bulleted list, and the editor keeps trying to optimize out
> that white space because it sees it as superfluous.

LyX keeps you from adding unnecessary whitespace accidentally, but will
let you add it if you really want to (IIRC it's <ctrl><space>).

> At first glance one might assume that the problem is the editor
> implementation.   But you really can't fix it in a WYSIWYG editor
> [...]

That's right, you cannot fix this in a WYSIWYG editor.  WYSIWYG is not
the right tool for this job.

Good thing that LyX is a WYSIWYM editor.  Take a look at screenshots or
videos, or https://www.lyx.org/ and https://en.wikipedia.org/wiki/WYSIWYM...

>               [...]. (of course it's not only XML-ish representations
> that have this problem, but XML-ish representations exacerbate it).
> 
> The fundamental problem is that XML is really a poor representation of
> text.  This is especially true for editing, but not just for editing.
>   Text is not hierarchical.   How do you represent in XML a comment on

LyX does a pretty good job of exposing hierarchy without making the user
deal with TeX/LaTeX/XML/any other internal representation.  It can be
done, because it has been done.

> a particular block of text that, say, overlaps multiple XML elements
> but doesn't completely contain all of them?   [...]

Not sure how to do that in *any* document representation format.  In XML
you could encode the relations in element attributes, but while text can
be hierarchical, it's not _relational_ in a semantic way, so you can't
keep users from screwing up any such relations you choose to try to
represent by moving text around.  Still, I also don't understand why you
couldn't make a comment contain the text it comments on for this
particular use case, or why this particular use case is too important.

>                                      [...]?   In a document which has
> been edited by multiple users, how do you represent in XML the changes
> made by each user?   I'm not saying that it absolutely cannot be done,
> but it's either going to be ugly or it's going to abandon many of the
> properties that made XML appear to be attractive in the first place.

I'm not sure that I care about who made what changes in a collaborative
editor.  If I do care, then I'll prefer a merge-based workflow.  LyX
does have a mode for diff/merge, where you get to review every proposed
edit, and accept (then possibly further edit) or reject it, and LyX does
have version control support.

> > > I understand why we adopted an XML format 20 years ago. That was
> > > better than NROFF, and there was a hope that the whole publishing
> > > industry would standardize on XML. It did not, and now the IETF
> > > has its very own markup language.
> 
> In some sense, nroff really was better.   Probably not better overall,
> [...]

Roff does not represent metadata in any way such that it can be
programmatically extracted, except by convention -- there's no "roff
schema".

> but at least nroff usually wouldn't throw up its hands and completely
> refuse to render a document (within an hour of a deadline) because you
> left out or misspelled some directive.   And in nroff you didn't have
> [...]

roff can error out, or throw warnings and misrender in subtle ways that
you might not see if you miss the warnings.

roff is also a real pain on the eyes.

> the UI problem.    I'm not arguing for a return to nroff.   XML is
> definitely more powerful in some ways, and XSLT is nice.  (I've
> written tools to convert nroff to other representations and it wasn't
> either easy or fun.)  But we went from one obscure and specialized
> text representation to another, and the newer representation is in
> some ways a poorer reflection of the text than the older one.
> 
> Anyway, if we're really going to try to improve our tools, we
> shouldn't naively assume that XML is the right direction for
> underlying representation.   [...]

Perhaps, but any alternative needs to be possible to use in such a way
that we can convert to XML and preserve semantics, or else the
alternative has to be as powerful as XML (which is roughly saying the
same thing).

I would only consider LaTeX as mentioned earlier because a) there are
very good collaborative and non-collaborative web and non-web $EDITORs
for it, and b) it can be used in such a way that one can convert it to
XML while preserving semantics.

Nico
--