🚀 go-pugleaf

Darrell Raymond <drraymon@watdragon.uwaterloo.ca> writes:
|
|     I like Dan's distinction between structural and formatting markup,
|   but I propose we avoid assuming that:
|
|   >Structural markup is an abstraction of formatting markup.
|
|     The reason is that some presentational effects are not related to
|   structure, but are just there because they are pretty or whatever.
|   For example, indenting second and following paragraphs might be
|   considered to be purely presentational, and with no structural
|   relevance.

This is an interesting point.  There are certainly a large number of
presentational devices which are not tied to the particular element
type, but that does not mean they have no structural relevance.  The
example you gave, for instance, relies on a sequence of like elements,
paragraphs, and a description of the presentational features, as in: a
common style for all paragraphs, with minor variations for the first
paragraph in a sequence of paragraphs.  This doesn't make it a different
form of paragraph, of course, but we treat the location of the paragraph
in the element hierarchy as one of the attributes of the paragraph, and
this is largely, if not completely, implicit in general.  This
particular case can, however, easily be expressed in SGML with the
POSTLINK feature of link type declarations.

The separation of information (i.e. structure of) and presentation is
the field which SGML really masters, and the field which it grew out
from.

I think the above quoted line is perfectly valid.  Structural markup is
an abstraction over formatting markup, with the understanding that we
have to have _some_ presentation for a given element, but it could be
_any_ presentation, and if the presentation only changes in degree, as
opposed to nature, we can easily subsume such variations in the
definition of a single element type.  This process is very close to the
process of concept-formation in philosophy, and the fields share the
problem of universals, which dates back at least three millenia.  It
would be pretentious if we assumed that SGML could solve it, but SGML
may be able to contribute to the problem, in it's own context.

Sometimes presentation is an inherent property of the element to the
degree that it requires a different element type.  Sometimes it's a
property of the element, but not enough to require distinction from all
other element types, and it would be an attribute.  Sometimes it would
be deemed inessential to the structural properties of the element and
its role in the document would be relegated to link attributes for a
particular processing.  SGML allows us three levels of abstraction from
presentational qualities, and this is one more than any other system I
know of.  It also poses interesting questions for where the line should
be drawn between the three, and especially the two former.  Religious
wars are fought over how many levels are sufficient.  Some extremists
believe that one level is enough (only elements), and I've heard rumours
to the effect that they worked on the OED a UWaterloo.  Darrell?

|     Eliot says in a followup message that there is a many-to-one
|   relationship between presentation and structure; I'm suggesting
|   that the relationship is actually many-to-many, and that the
|   derivation of presentation from structure is not mandatory, but
|   simply common.

I disagree with this statement.  Derivation of presentation from
structure must take into account implicit attributes such as the
location in the hierarchy, if not only for such things as paragraphs in
long quotations and footnotes, which get a different presentation than
paragraphs in a chapter element, say.  This cannot be inherent to the
element itself, but would be linked to it by a processing application,
depending on several factors.  This means that the implicit relations
"precedes", "succeeds", "contains", and "is contained by" (as well as
several others proposed by the DSSSL working group) take an active part
in the derivation of presentation from structure.  The reason is that
these were the aspects that we were willing to temporarily disregard
when we made the abstraction from presentational qualities, and they
need to be re-introduced when we concretize our abstractions, i.e.
present the element in/on some medium.

Even if presentation is so distant to our thinking that it no longer
matters, we should not disregard these factors and claim that structural
markup itself is sufficient.  This also means that any element structure
in which recursive elements are allowed is not context-free, but imposes
on the parser and/or the application a requirement that they know where
in the element structure they are at any given time.  I'm sure some will
find this very uncomfortable, though.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.