Re: [xml-dev] Please stop writing specifications that cannot be parsed/p

[Marcus Reichardt <u123724@gmail.com>]

> for people using an existing parser via
> a SAX interface, it doesn't matter
> whether the input is SGML or XML.

That's indeed what I was meaning, and if anything, I have to apologize for being so unclear.

> The relatively deep intertwining of
> validation with everything
> else in ISO 8879 makes it hard to write
> even simple tools.

What would those tools be? Aren't XML people usually the first to criticize ad-hoc kindof-XML parsers, and why would you side-step a parser lib you just put a lot of effort into creating, to use a task-specific ad-hoc kindof-XML parser instead?

Cheers,
Marcus Reichardt
sgml.io

> Am 06.06.2023 um 16:44 schrieb C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>:
> 
> 
> Marcus Reichardt <u123724@gmail.com> writes:
> 
>> Also, is it really relevant that you can't use off-the-shelf LALR
>> parser generators for a markup meta language that itself acts as
>> parser generator?
> 
> I'm a little puzzled here.  Were you not claiming, in your earlier mail,
> that writing a parser for XML would be "exactly as complicated" as
> writing a parser for SGML "since the parser lib does the heavy lifting"?
> If it's not relevant, why did you bring it up?
> 
> On re-reading your earlier post, I see now that what you wrote can be
> interpreted as saying only that for people using an existing parser via
> a SAX interface, it doesn't matter whether the input is SGML or XML.
> This is true, and I apologize for my misreading.
> 
> But since you ask, yes I think it's very relevant.  The relatively deep
> intertwining of validation with everything else in ISO 8879 makes it
> hard to write even simple tools.  That (imho) is part of what made the
> Basic SGML profile a non-starter: a parser had to perform validation in
> order even to distinguish data characters from other characters.  If
> 8879 had been designed to be parseable using standard parser generation
> tools (yes, grandchildren, there were such things back then), it's
> possible there would have been a more tractable layering of information.
> 
> Michael
> 
> -- 
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> http://blackmesatech.com