NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/text/sgml/1350

Text File | 1993-01-24 | 5.4 KB | 101 lines

Path: sparky!uunet!ralvm13.VNET.IBM.COM
From: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 24 Jan 93 12:09:17 EST
Newsgroups: comp.text.sgml
Subject: Re: on "full support" for LINK
Disclaimer: This posting represents the poster's views, not those of IBM
News-Software: UReply 3.1
References: <[e-mail]> <[e-mail]> <[e-mail]>
            <[e-mail]>
Lines: 88

I've spent some time discussing LINK with Dr. Goldfarb, mostly in
the context of how LINK compares to what DSSSL is trying to do and
the general problem of DTD-to-DTD mapping, which Michael has very
nicely outlined.  To my mind, LINK is immediately useful as nothing
more than a *standard* (if not optimal) way to completely separate
presentation information from an SGML document instance by providing
an indirect connection between application-specific "style specifications"
and the document instance.  (I am not convinced it can do more and won't
try to argue it is up to it at this time.)

For example, in the InfoMaster Architecture, we have defined for all
elements the comment attribute STYLE=.  The value of style is
an application-specific value for determining the presentation of
an element.  Since STYLE= is, by definition, presentation information,
it would be best to keep it out of the document instance altogether
(but for obvious practical reasons, we can't mandate that). LINK provides
a standard mechanism for supporting keeping STYLE= out of the instance.
Assuming you have an
editor that lets you define presentation styles quickly and easily
for elements, the editor would generate the necessary link rules
to associate the presentation information with the element instances.
(I assume an editor because 1) the technology is there and 2) it's
probably not practical to ask authors to hand code LINK rules.)
The presentation specification would be, presumably, proprietary
(or at least application specific, even if that application is DSSSL
or FOSI), but the association mechanism would be standardized, and
*not* proprietary.  I have no hope of interchanging presentation
information between different applications without a standard
assocation mechanism.  Having a standard mechanism for association
doesn't necessarily get me very far, because the presentation
specification itself must be standardized, but I can't do it *at all*
without first having an interchangable assocation.

There are other possible association mechanisms one could use,
but they will all, by definition, be application specific *because
they are not defined by ISO 8879*, even if they are themselves
defined in a standard.

The main problem with LINK seems to be how an application knows
which link rule to apply at a given time.  This is the state
problem Erik and Micheal allude to.  In order to know which
link rule to select, an application must define and manage
the states that will determine the selection.

One solution Dr. Goldfarb suggested to me
would be to use SGML-based query specifications as the
determiners, rather than rely on application-specfic states.
If define that link rules can contain an attribute, say LocSpec=,
that contains a query in some query language that defines
where it applies, an application can examine each choice in
a link specification and use the one whose query is satisfied
(or perhaps, whose query is first satisfied, using the order
of specification in the link rule).  This approach could
be officially standardized by either adding it to some revision
of ISO 8879 or to the DSSSL standard.  The appeal of this
approach to me is that it provides a robust and generic association
mechanism between a document instance and a style specification,
defined using existing standard constructs (e.g., LINK) and
SGML query methods that are well defined.  If you use the
HyQ query language as the query language, you can reasonably assume
that any conforming HyTime system (including print-only document
processors that support HyTime hyperlinks) will implement HyQ.
In addition, The DSSSL effort has, at a minimum, crisply defined the
semantics needed to do complete SGML queries, even if they haven't
settled on a concrete syntax for expressing the queries themselves,
and we can therefore be assured that anything we want to do with a
query, we can.  DSSSL and ISO 8879 overlap at LINK, so it seems
reasonable to me to codify that overlap explicitly in one standard
or the other.

There are more complex uses of LINK that are, in my mind, less
compelling (for example, USELINK within a document instance
is highly problematic if you want to eschew sequential processing
of elements).  But the basic utility of LINK as a means of
associating presentation specifications with elements in
document instances is, in my opinion, highly compelling.  While
it doesn't solve the entire problem of generic style specification
(which may well be unsolveable in a generic way), it frees me from
having to use any given application's method of association, which
today translates to any given vendor's method.  If one of the
chief benefits of SGML is vendor independence, why should I then
compromise it immediately?

Eliot Kimber                      Internet:  [e-mail]
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: [phone]
IBM Corporation
Research Triangle Park, NC 27709