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 --
