Re: [xml-dev] The Goals of XML at 25, and the one thing that XML nowneed

[Peter Flynn <peter@silmaril.ie>]

On 20/07/2021 07:43, Rick Jelliffe wrote:
[...]
> XML is now at a much worse stage than where SGML was in 1995: 
> standardized, adopted, stable, fit for purpose, but essentially
> solving the problems of the 1980s in a 1970s kind of way.

I think it's in a much better state. The problems of the 1980s (and
90s) included a lack of understanding of markup, unwillingness of text
owners to adopt an unproven technology, hostility of developers and
programmers towards markup because it wasn't programming, and a host of
others including the lack of standardised character suites, monstrously
expensive software and slow machines.* Most of them are gone (a little
residual hostility-out-of-ignorance remains). But XML solves the
problems that publishers had, now that the original software and
hardware problems are no longer an issue (you have rightly highlighted a
bunch of new ones, but that's not XML's fault :-)

* Much of the blame heaped on hardware is, I feel, misplaced. Certainly
the software I used then, including the PAT database, Omnimark, sgmls,
and TeX, beat the socks off anything else at the time, and still do.

> IMHO, parallel-parseability is meets a constant demand and is a good
> goal, and inplace parsing is a low-hanging fruit on this.
In the publishing field they are nice-to-know, and possibly useful, but
not if they break the model of markup irreconcilably.

> By parallel-parseability I suppose I mean non-modal or random-access 
> parsing: that you should be able start at any point in a document
> and figure out whether you are in tagging or data by parsing forward
> until the next milestone delimiter (i.e. > or ;) which then tells you
> what you started in.
Non-modal would probably be a more descriptive term than
parallel-parseability, as in many cases there wouldn't necessarily be
anything to be parallel to. This is largely the situation I described in
my work on editors, where an author request (mouse/key click) for a new
(eg) section would require the software to work out where to go from the
current cursor location to get to the next or pervious place where a
section was a valid insertion. I assumed at the time that this was a
problem not outside the scope of programmers to solve
(https://cora.ucc.ie/bitstream/handle/10468/1690/Human-Interfaces-to-Structured-Documents.pdf#page=278)

> Dan, Peter, Arjun, Mukul, Gavin ... gosh, so many voices from my past!  

Scary...same faces discussing the same stuff :-)

Peter