[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] ArchForms and LPDs
- From: Marcus Reichardt <u123724@gmail.com>
- To: "Liam R. E. Quin" <liam@fromoldbooks.org>
- Date: Mon, 26 Jul 2021 14:46:34 +0200
On 7/25/21, Liam R. E. Quin <liam@fromoldbooks.org> wrote:
> 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.
>
Well, talking about putting the car before the horse, then, I guess ;)
When SGML software vendors "hate" the complexity, they had no good
case to offer software for SGML to begin with, had they? It's not like
SGML is there to appease software vendors after all. That said, SGML
may have been complex by 1986 standards, but it pales in comparison to
the "web stack" of today.
> In-place parsing isn't going to fly in a world with XInclude, nor for
> that matter with NFC normalization.
What's that world of XInclude you're speaking about ;) If anything, I
had assumed XInclude, due to its unintended interaction with schema
validation [1], was on its way out.
[1]: <https://stackoverflow.com/questions/1098116/xinclude-schema-namespace-validation>
> 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.
Idk, XML software is also F/OSS. The problem with HTML5/WHATWG seems
to be that not only did hixie hate XML but SGML and URLs as well, or
anything else not invented by WHATWG for that matter. And it shows in
the HTML5 spec [2] as well as in WHATWG's tooling to produce the HTML
and other specs. I recommend [3] for a laugh where they move away from
HTML as markup language for their own fscking spec and need to
retrofit one old Pascal program of hixies to collect and manage links
to definitions or something. Not that they ever embraced an
HTML-centric workflow even though they portray it as an authoring
format in the spec text, as can be seen from the source text beginning
like this [4]:
<!DOCTYPE html> <!-- Note: This file is NOT HTML, it's a
proprietary language that is then post-processed into HTML. -->
<html lang="en-US-x-hixie">
...
[2]: <https://archive.xmlprague.cz/2016/files/xmlprague-2016-proceedings.pdf>
[3]: <https://github.com/whatwg/html/pull/5694>
[4]: <https://raw.githubusercontent.com/whatwg/html/main/source>
>
> 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.
>
What would such a thing look like though? We're talking about
attempting to unify a grammar formalism describing information
serialization for hypertext as a tree grammar with regular content
models on the one hand and co-inductive datatypes and equational
theories of a lousely-typed programming language that doesn't even
have integral numbers or dates as datatype on the other.
I guess you're after a broadly applicable schema mechanism for
enterprise integration (and so am I, having done many EE projects for
a living). Personally, I've always liked the pragmatic approach of SDO
(part of Service Data Architecture spec'd by OASIS and OSOA before
that) which uses XSD but allows optional annotations/custom attributes
(like sdo:sequence="false" eg to represent that an xsd:sequence should
be presented "record"-like/with access to "fields" (subelements or
attributes) by name in a mostly sane polyglot data access API. A
simple expression language (eg "record.field.subfield.memberarray[3]")
with implicit data conversion is also provided. For the longest time
I've recommended XSD due to it's robustness, broad applicability, and
mindshare, but today I'm not so sure a future generation will carry
XSD forward.
[5]: <http://www.oasis-opencsa.org/sdo>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
