> I don't have such a rosy recollection of the Link Process Definition
> (LPD) facility. Back in the day, we used it exactly once, and the LPDs
> were dropped as soon as we could replace them with proper software.
Fair point, and I wasn't advertising LPD so much as pointing out that
ArchForms seem redundant in the presence of (explicit) LPDs (in the
greater context of arguing about the pointlessness of namespaces
insofar as these achieve only trivial syntactic/schema composition
when the hard part is integration into a rendering pipeline).
That said ...
> 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
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 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
smells like having grave decidability issues from a language design
PoV :)
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
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.
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.
So I don't know which processing system you used at the time, but I
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.
> 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.
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php