Re: Relationship types

At 4:48 PM 1/24/97, Len Bullard wrote:
As a co-author of the committee draft of the TEI pointer syntax, I'll risk
a few comments here.

>I have been studying the TEI extended pointers.  It includes
>a type attribute which appears to be used when the author
>wants to declare something (e.g, type=navigator).  It
>also appears this could be used should the author decides
>to include state management hints.
The intent was to allow the binding of rendering styles to links based on
their semantic type (ie. the indirection that we need).

Of course yo can out anything you want in a CDATA field, but we need not
define a method for link-semantics hacking any more than we need to have a
Rainbow-DTD equivalent to make XML rendering plausible.

>  Lou's document is
>quite clear and easy to grasp.   This is BabyHyTime and
>something like that is a very good place to start with XML 1.0.
>I think it should be expressed as an architecture, but it might be just
>as easy to make a parameter entity and get the same effect.

You mean a fixed element type? Heaven forfend. The TEI attribute value
syntax should be adopted, _not_ element types.

>So which chicken or egg came first:  reftype or targtype?
>Just reading this, it looks like the authors went out
>of their way to use HyTime concepts but change the
>names to protect something or another.  Reftype has
>been around since Caps asked for it to use in 87269.

We went out of our way to use standard terms that the hypertext field had
been using for 2 decades prior (actually, since we already knew about that
work, we avoided going out of our ways). HyTime was something of which we
were relatively unaware, mostly because there was, at that time, no
intelligible explanation of HyTime (which was in draft).

At a late point in development we did rationalize the semantics to match
HyTime where we discovered a few pointless an inessential differences. We
did not choose to use the de novo HyTime terminology that had prevented us
from understanding the standard for years previously.

>I'm still not sure how one would specify chained traversal
>to prevent goto/label where not safe, but I've not had
>the document for very long.  What I wanted in MID was a
>sequence of locations one could point to using a nameloc
>and implying that identifier order was strict, but I
>was overruled on that one.  I thought it easier to
>say, "here is a list of id/locations.  Traverse in
>sequence".  So we used the chain element type and
>containment instead of indirection.

I don't know if I understand what you're aksing for. But if I do, I think
you would just make a multi-ended link or a link group and leave it to the
application or stylesheet to specify parallel or sequential display. There
are no pre-wired rendering semantics anywhere in the TEI.

>Regardless of how folks like it, scripts in declarative
>markup are now a way of life and will not go away.  As long
>as something like a script node can be declared by XML
>applications who wish to use the approach, fine.  I do
>not subscribe to the SGML Way on this issue.  Too hard
>on performance, and frankly, silly.  Nothing in SGML
>except Charles' promise says it can't be used to
>create a scripting language, and in fact, it has
>been done several times.  Slow ones, to be sure.

I refuse to recreate Hypercard in Java. You don't seem to be winning this
argument to hard-wire presentation semantics, but if you do, I hope I won't
be the only one arguing that XML linking is best ignored. You can embed
scripts in declarative markup to your bady-designed system's, rewire it
twice-a-decade,  heart's content, but there is no reason for XML to
encourage data obsolescence for links, when it is trying to save people
from it in their documents.

You're right though, there are no new arguments in this debate. Let's see
what the editors propose.


    But let's make sure my posiiton is completely clear. I _do_ agree with
the need for an easy start-up for linking "out of the box". However, I
think that that is best handled by well-publicized beginner DTD/stylesheet
pairs. I think that these should be some kind of (HTML++)++ -- i.e.
workable HTML, entended with extra power inherited from superior underlying
semantics, and, unlike HTML, tailorable and extendable as to both behavior
and structure due to the presence of DTDs and stylesheets.

>In any event, a normative list is not needed.  Examples
>will do just fine.

   That's good. Since I've seen no support for a normative list of
linktypes, we probably don't need to mention this again.

   -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Saturday, 25 January 1997 17:10:45 UTC