Re: [xml-dev] Re: LPDs

[Tony Graham <tgraham@antenna.co.jp>]

Sorry for the late reply, but we're already about 29 years too late to
revert to using LPDs.

On 25/07/2021 20:56, Marcus Reichardt wrote:
...
> > LPDs could add attributes to elements based on the element's
> > context, yes.  This works well enough in the two-level toy example
> > in the SGML Handbook, but if you need more context, you end up with
> > an explosion of LPDs for the different contexts.
> Link attributes you specify in link rules (of implicit link
> processes) work exactly like CSS properties in that they're
> associating item-value pairs with elements in a context-dependent
> way, and interpretation depends on "the application" to which the
> SGML parser is "linked", hence "link process". The difference being
> that link
We didn't have this mythic 'application' that could reach back into the
parser and cause the parser to change its parsed output.  The parsers
that I saw were all command-line tools.

> attributes reuse existing markup concepts (attribute list 
> declarations) rather than adding ad-hoc value spaces, microsyntax,
> and redundancy to an already crowded space of concepts. The other 
> difference being, of course, that you don't have selector
> expressions but need to encode a state automaton by hand using
> #USELINK and #POSTLINK.
>
> This latter feature can be an advantage or disadvantage. In the case 
> of the classic example given in The SGML Handbook, I would've
> thought having the ability to toggle state for recto/verso pages is
> rather advantageous compared to proliferation of microsyntax a la CSS
The LPD examples invent several microsyntaxes.

> which for paged media has either the :left/:right pseudo-selectors,
> or alternatively the more general form :nth-child(2n+1), which
> however is unsupported for paged media to the best of my knowledge
> (and also
https://www.antenna.co.jp/AHF/help/en/ahf-css6.html#css3-pseudo-clssses

> smells like having grave decidability issues from a language design 
> PoV :)
I don't know what you mean by 'decidability' here, but that's probably
tangential to the discussion.

> If OTOH you're talking realistic modelling of flow layout, then SGML 
> LINK at least makes an effort to capture the use case of supplying 
> parameters to separate measuring/rendering phases through explicit 
> link pipelining in a footnote on p 106:
>
>      for example, a formatter might process part of a document to
>      generate galleys, then process part of the generated galleys,
>      then go back to producing galleys again.  An application could
>      even use information gained during the page production process
>      to re-do some of the earlier galley processing
This is not dissimilar to how AH Formatter works, but describing this
for a 'chain of processes' that each use LPDs and generate a 'result
document type' implies that the formatter can cause one of the earlier
processes to rewind and reparse part of its input to generate different
results through all the intermediate processes.  You might view this as
proto-XProc, but it's not something that we had circa 1992.

(Not quite the same, but you can make decisions based on the formatted
output from within XSLT: https://github.com/pplcg/XSLTExtensions)

> In any case, since "the application" (the formatter) interprets link 
> attributes, its usability is entirely up to the chosen link
> attribute vocabulary; SGML LINK merely acts as a mechanism to supply
> parameters based on the same declaration syntax that's already used
> for regular markup attributes.
Yes, but it doesn't provide fine-grained enough parameters.

Here's three template rules that just happened to be in a currently open
buffer:

<xsl:template
    match="hi[@rend eq 'all-small-caps']">
  <fo:inline font-variant="all-small-caps" letter-spacing="0.05em">
    <xsl:apply-templates />
  </fo:inline>
</xsl:template>

<xsl:template
    match="hi[@rend eq 'small-caps']">
  <fo:inline xsl:use-attribute-sets="small-caps">
    <xsl:apply-templates />
  </fo:inline>
</xsl:template>

<!-- The foreign words in the table in 'Etymology' are not in
     italics. -->
<xsl:template match="foreign[empty(ancestor::table)]">
  <fo:inline font-style="italic">
    <xsl:apply-templates />
  </fo:inline>
</xsl:template>

The SGML Handbook invents a microsyntax for evaluating attribute values,
but the LPD mechanism as defined can't do the evaluation for you.
However, the 'application' is allowed to evaluate added attributes
before they're added to influence which set of added attributes gets
added to the result.  Let's just say that's beyond my experience of
using an SGML parser.

I don't want to think about how you'd write LPDs such that <foreign> at
any level in a table generates a different attribute value (or no
attribute at all).  You might be able to do it with #USELINK and a web
of entities to specify the parts that you want to keep, but it wouldn't
be nearly as succinct as "foreign[empty(ancestor::table)]".

> Now if you have too many contexts to propagate into child elements, 
> then this would appear to be a problem of the chosen markup
> vocabulary (akin to using HTML divs for each and everything) since
> link rules are primarily selected by matching element names.
If you have recursive sections, a la DocBook's <section> [1], then you
need myriad link rules to have the correct attributes added to each
level of section title.

> So I don't know which processing system you used at the time, but I
The Mark-It parser for validation, then various in-house tools for
processing the SGML.  At the time of using LPDs, we might have been
using the Integrated Chameleon Architecture (ICA) [2] to transform the
SGML into something else.  It might have been for use with AGFA/Xerox
CAPS, but IIRC, we were probably using troff at that point.  Both LPDs
and ICA were short-lived, and they were superseded by Perl and later
Scheme and we eventually used TeX for formatting.

At this point, I can't tell you whether or not Mark-It implemented all
of LPDs or just a subset.

> can say I've got personal experience with CSS Paged Media, IBM 
> VS/SCRIPT/GML/DCF for mass printing (and also FOP, though not nearly 
> as much as you guys :) and I can say that IBM's phone-book sized AIX 
> documentation from about 1991, produced using IBM's SGML-based IdDoc
> I believe, is among the best printed operating system manuals I've
> ever read.
I don't see how that relates to LPDs.

The appearance of the printed output has more to do with the imagination
of the designer, the features of the formatter, and (for us here) the
richness of the markup than it does with whether or not LPDs were used.

> > The utility of putting style information as part of the validation
> > never made sense to me either.
> There's no validation in the XML sense going on here; SGML LINK
> merely reuses regular attribute list declaration syntax for link
> attributes.
Sorry, at the time of validation.  As above, we were using the Mark-It
parser.  It could output the parsed SGML as SGML, including defaulted
attributes (and LPD attributes). (If you validated its SGML output, you
got the attributes back into their original sequence, which was useful
when diffing files or viewing changes in RCS.)  After that, the DTD
wasn't needed again, and we processed the files as 'well-formed SGML'
(not that we called it that then). (We later moved to sgmls then
nsgmls and worked with the ESIS.)

I do wonder why I react so badly to LPDs after all these years while I
don't have a problem with an <?xml-stylesheet?> PI in a document.  I
think it's that, in my experience, LPDs didn't do enough to be useful.

Regards,


Tony Graham.
--
Senior Architect
XML Division
Antenna House, Inc.
----
Skerries, Ireland
tgraham@antenna.co.jp


[1] https://tdg.docbook.org/tdg/5.1/section.html
[2] http://xml.coverpages.org/ica2.html