HyTime architectural forms
Newsgroup: comp.text.sgml
Subject: Re: HyTime architectural forms
From: "W. Eliot Kimber"
Date: 1997/05/02
----------------------------------------------------------
> Can someone explain to me, like if I was four years old, what
architectural
> forms
> means in HyTime?
At their simplest, "architectural forms" are simply a way to define a
general element type or attribute list that you then define your own
element types or attributes in terms of.
The term "form" is used in the sense of a form used in casting: the form
determines the overall shape of the thing, but once it's cast, it might be
modified in a variety of ways--think of casting a plaster figurine that you
then paint to your liking. The term "architectural" is in the sense of an
architecture as a plan or framework that guides the building of things.
Thus "architectural forms" in SGML are guides to building more-specialized
document types.
The act of defining architectural forms (such as the forms in the HyTime
architecture) serves to capture and document the "semantics" of the forms:
what they represent, how they are intended to be used, what processing they
require or imply, what the constraints on their use are (how wild can you
get in your modification of things pulled ("derived") from the forms).
Once captured, this design can be re-used for each new DTD that is similar
to the architecture in some way. The definition of an architecture, like
that of a normal document type, is both formal, through SGML element and
attribute list declarations, and informal, through human-understandable
documentation that explains what the forms are and do. In other words, an
architecture--a set of architectural forms--is a general-purpose document
type design intended to be used as the base for more specialized document
type designs.
For example, most documents have hyperlinks of some sort in them. It would
be useful to define a general set of rules for hyperlinks and then "re-use"
those rules for specific kinds of hyperlinks in your documents. The
general set of rules are an "architectural form". Programs can be written
that understand these general rules and can apply them to elements in
documents without knowing anything more about those elements than that they
are derived from the form. In other words, HyTime defines a simple
architectural form for hyperlinks called "clink" (contextual link). All
HyTime-aware processors know how to make clinks work (Panorma is an example
of such a processor). If you create a document type with a hyperlink
element, called whatever you like (say "CrossRef"), and indicate that it is
a kind of HyTime clink, Panorama will be able to make the link active and
do the processing HyTime says should be done for clinks, without you having
to do anything more.
The mechanism by which you indicate that the CrossRef is a kind of clink is
to put an attribute on your CrossRef element that tells the HyTime
processor "this element is derived from the HyTime clink form". For
HyTime, this attribute is named "HyTime" (by default). It's value is the
name of the form you are mapping your element type to:
<!ATTLIST CrossRef
HyTime NAME #FIXED "clink" -- CrossRef is derived from HyTime clink
form --
linkend IDREF #REQUIRED -- HyTime says use this attribute name
for
refering to the
target of the link. You can change
this name to
something else if you want. --
>
A HyTime-aware tool, such as Panorama, will look for a "HyTime" attribute
on each element. Finding that the CrossRef element has a HyTime attribute
and that it's value is "clink", Panorama says "I know what to do with
clinks" and does it (i.e., makes the CrossRef selectable and takes you
wherever it points should you click on it). In addition, you may have
specified specific styles for your CrossRef element that reflect its
specific purpose, over and above being a clink, in your document.
There is no magic to architectural forms and architectures: as others in
this thread have pointed out, it's just a simple mapping from your DTD to
some pre-defined semantics. Achitectures simply provide a formal mechanism
that is both standardized and machine validatable (because meta-DTDs are
synatically the same as normal DTDs, SGML processors can validate documents
against meta-DTDs just as they can against normal DTDs--SP and the SP
family of tools do this, for example). Being standardized, they can be
interchanged with some confidence. Being validatable, they can be checked
and enforced with some authority.
In the original HyTime standard, architectures and the syntactic mechanisms
for using them were not formally defined. With the publication of the
HyTime TC (real soon now, trust me), architectures and the methods for
defining and using them are formally defined independent of the main part
of HyTime (the part that deals with hypermedia specifically). This
definition is the "Architectural Forms Definition Requirements" annex of
the corrected HyTime standard. Look for it soon at an ISO/IEC outlet near
you.
--
W. Eliot Kimber
Highland Consulting, a division of ISOGEN International Corp.,
www.isogen.com