xml-dev - Re: Defining Behavior Was: Back to XObjects was XLink

[Ralph Ferris <ralph@fsc.fujitsu.com>]

At 09:49 AM 11/12/98 -0000, Mike Kay wrote:
>
>And this reflects a lingering concern I have about XLink,
>which is that it is putting display-time behaviour into the
>XML document rather than into the stylesheet. I'm not
>convinced that XLink is defining relationships at a high
>enough level of abstraction, and I'd prefer to see work on
>interactive behaviour happen in the XSL world.

A long standing issue, still under discussion. In HyBrick, behavior depends
on a *combination* of DTD and stylesheet information. This follows from the
use of DSSSL-online, which defines "make link" and "make external graphic"
procedures. 

In the original demo version of HyBrick (which was not publically
distributed) the "make link" procedure was used to create the equivalent of
HTML A-type elements. In the current release, it has been adapted for the
locators in xml:link-type elements, except that the HTTP sub-system isn't
currently enabled for link-type elements, so links only work with the local
file system. The "make external graphic" procedure was (and is) used to
create the equivalent of HTML IMG-type elements. 

The element types themselves of course have to be declared in the DTD, and
their attributes assigned the proper declared values. Note that the "make
link" and "make external graphic" procedures also require that the
attribute values be declared. Of course, the attribute declared values in
the DTD and stylesheet *should* match. The several people I've talked to
about this have all stated that enforcing this match is an "application"
level issue.

Another factor to be aware of though is that the "document groups" defined
in the current XLink draft affect link "visibility" - which can have a
subtle - and confusing - influence on behavior. I would call this another
aspect to the "high enough level of abstraction" that you referred to.
Current HTML users are used to a "go to" model of linking. Hypertext
experts have always known that we can do better. The issue is, pre-Web
hypertext systems where built, whatever the ultimate aspirations of their
designers, as *closed* systems. Even in a closed system, applying even
what's currently defined in the XLink/XPointer specs can get interesting.
Applying these concepts to the open environment of the Web is going to get
even more interesting. That's why it's important for more people to start
experimenting with HyBrick, so they can get more insight into these issues
first hand.

>
>In particular, I am really uncomfortable with the one-to-one
>mapping of stored XML documents to "units of display". I
>think the presentation facilities (stylesheets and hyperlink
>browsing) should be independent of the granularity of
>storage.

>
>To put things another way, if I'm going to have to
>pre-process my corpus by splitting it into lots of linked
>page-sized chunks to make it browsable, I might as well
>render those chunks in HTML while I'm about it.

Agreed. In particular, with XPointer you should be able to retrieve
"fragments" rather than having to retrieve entire documents. This day will
come.


Best regards,

Ralph E. Ferris
Fujitsu Software Corporation





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)