Re: !BEHAVIOR

[Daniel Rivers-Moore:]
> One of the areas I want to look at very seriously is how architectural
> forms can be used to provide different views of data. The core storage
> might be highly data-centric, but document-centric, GUI-centric and
> other-centric views will also be needed. It seems to me that AFs  can be
> a powerful way of achieving this. It seems to me that an architecture (a
> coherent set of architectural forms) might provide just what is needed -
> a means of defining a particular subset of the data, presented in a
> particular way, with particular semantics and behaviour. In short, a
> rich stylesheet++ of the kind we need.

I think Daniel is quite right.  The idea of using attributes to indicate
style is not new.  It is a strong idea that has an unassailable place
in the SGML world, and it has always been there.

The SGML LINK mechanism is designed to allow exactly this: the
after-the-fact pasting of extra attributes and their values onto
elements to indicate their stylistic treatment.  This was the first
style mechanism of SGML, and, although it has been sadly ignored and
neglected, it is a good, simple, and straightforward one for many
applications.

Now consider that a GI is the value of the nameless attribute, and
that every element type has this nameless attribute, whose value
is both #REQUIRED and #FIXED at the name of the element type.

It has always been possible to have a DTD in which the element types
indicate the intended stylistic treatment (a procedural DTD) rather
than the kinds of things they are (generic coding).  It was never the
intent of SGML to prohibit procedural markup, and it cannot be said
that it is always wrong to do so (although it usually is wrong for the
maintained "source code" of valuable, repurposable information).  HTML
is a prime example of a hellaciously useful DTD that has quite a few
baldly procedural element types.  (HTML is a poor choice for the
maintained source of many kinds of information, but it sure is great
for lots of purposes all the same.)

One of the intended uses of DSSSL is to prescribe the transformation
of generically-coded documents into procedurally coded documents that
conform to procedural DTDs.  So, in fact, DSSSL actually envisions
procedural DTDs as being useful for document processing.  And why the
heck not?  If it's helpful to have procedural markup, then would
should be able to use it without shame or guilt.

Now with the notion of inheritable architectures, elements can have
not only GIs, but also "meta-GIs" (<- Martin Bryan's coinage): the GIs
these elements would have had if they had been expressed in the
context of an inherited DTD ("SGML architecture").  These are
attributes like any other attributes.  They can easily be ignored by
any SGML processing application, the more so because they all have the
same name, which is usually the name of the inherited architecture.
Why would it be in any sense "bad form" to use a procedural DTD as an
inherited architecture?  On the contrary, it's good form, and it does
no harm to the genericity of the document.  It's just the addition of
attributes to indicate style, which is something that is expressly
sanctioned by the SGML LINK feature.  It's convenient for viewing the
document in the same way it might be viewed after some simple DSSSL
transformation, while obviating the need for such a tranformation.

As Eliot Kimber is fond of pointing out from time to time, the
addition of architectural attributes (meta-GIs) to existing read-only
documents can be accomplished using SGML's LINK feature.  In
combination with SGML architectures, it's a great way to accomplish
what Daniel proposes.  (You do, of course, have to put the necessary
<!NOTATION...  and <!ATTLIST #NOTATION... in the declaration subset
for each inherited architecture.)

As I myself am fond of pointing out from time to time, if we had had
inheritable architectures (i.e. the second edition of HyTime) when we
were doing the MID architecture for IETMs, we would have done the job
far more modularly, with a distinct inherited architecture for
windowing behaviors, etc.  As far as I'm concerned, windowing
behaviors are as justifiably classified as style parameters as they
are as "essential features of the abstract information conveyed by the
document."

Summary: In my opinion, it is as valid and useful to inherit a
procedural architecture (DTD) as it is to inherit an architecture
which is purely generic.  Inheriting a procedural DTD may not give you
the fine control you can get with DSSSL, but it may be more than
adequate for tons of applications; it's more rigorous and flexible
than lots of other ways of doing it; and it lets you take advantage of
re-usable software modules (engines) written to perform the processing
required by such inherited architectures.


             Steven R. Newcomb   President
         voice +1 716 271 0796   TechnoTeacher, Inc.
           fax +1 716 271 0129   (courier: 23-2 Clover Park,
      Internet: srn@techno.com    Rochester NY 14618)
           FTP: ftp.techno.com   P.O. Box 23795
    WWW: http://www.techno.com   Rochester, NY 14692-3795 USA

Received on Thursday, 12 June 1997 13:02:54 UTC