Re: [xml-dev] ArchForms and LPDs

["Liam R. E. Quin" <liam@fromoldbooks.org>]

On Sun, 2021-07-25 at 12:00 -0400, Arjun Ray wrote:
> 
> si  As a matter of fact,
> I don't know of any further TCs to ISO 8879 after the WebSGML TC in
> 1996, despite the official 5-year cycle for such reviews.  So a lot
> of this discussion is ultimately of archaeological value only...

If there were i never heard about them.  Software vendors in the SGML 
world mostly hated the complexity and were eager to see WebSGML. Atone
point minimization was responsible for (an estimate done at the time,
but based on some logging and monitoring) soe 80% of our supports costs
for Author/Edtor at SoftQuad. Of course, once you loaded a  document
and exported it back out, the minimization was all gone.

The biggest shift in moving from SGML  to  XML (for those of us who did
it) was, i think, a different view of the markup. SGML was essentially
a macro text-processing language. XML was a document interchange
format.

This is why XSD is important - you get type annotations on the parse
tree so e.g. a database can store floating point numbers as native
floats and process them massively faster. And unlike RNG, XSD
guarantees determinism, so you know which element will get which type.


Internal text entities for Unicode? Probably you're in the 0.01% of
users. Just insert the characters. Speed of parsing?  If that's a real
issue these days (and i know it is for some organizations), consider
server-side parsing with EXI.

In-place parsing isn't going to fly in a world with XInclude, nor for
that matter with NFC normalization.

If we have problems with XML, for the most part they are historical -
people who were forced to the the XML DOM in a junior job and now their
foreheads are caved in from all the head-banging. Sometimes a few lines
of XQuery can replace hundreds of lines of DOM code. People who learned
to hate XML: Ian Hickson (hixie) when he was editing HTML 5 described
himself as being allergic to any spec with an X in its name. Part of
that is the "enterprise/corporate" feel that is thught negative by the
open source Web crowd. There are many more examples.

Personally i'd be mre interested in a mini-xsd language that also was
useful for JSON, and had both XML and JSON syntax, than an attempt to
redo XML for a market that doesn't want it.


XML is already more complex than is useful. But we're stuck with it.
That needn't  be a problem, though. Go read the ASCII spec and tell me
exactly when SOH and SYN must be used and why.  Actually don't, because
i know what they are :-) but the point is, even though there is still
an archway over the North-East door into the cathedral, it's been
bricked up for centuries and no-one uses it. 

MicroXML was an attempt to make a subset, but it's too small and also
is incompatible, so you can't just use it with XML parsers and have the
rest of the stack work unchanged [1]. So why bother with it? It died,
as far as i can tell.

If there's a way forward it's neither in re-inventing lower layers no
in mourning the past. It's finding new use cases for what we have, and
new ways of working that have clear benefits for large groups of people
who know who they are and how this can help them.

(but it can still be fun to listen in to the conversation - thanks!)

Best,

Liam


[1] microXML doesn't do attribute normalization


-- 
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org