Re: Link-5: Extended Contextual Links

I suspect this is an application-specific question, but it may help to say 
what the current JUMBO does with your example.  (Note I haven't actually
typed it up, but I have no reason to believe that it wouldn't behave as below).
I know this is a long posting, but I've spent a long time hacking from the 
spec and I'd like to know I'm one th right lines :-)

In message <3.0.32.19970518112836.00b18a30@pop.intergate.bc.ca> Tim Bray writes:
> We have a problem as to what's a resource and what isn't.  I am mostly
> responsible for this; I dreamed up a cute example of what I claimed
> to be an XML xlink and showed it to lots of audiences... a lot of people
> like it, but in retrospect it turns out not to be right.
> First, here's the example:
> 
> <!DOCTYPE test [ 

These both default to SHOW="REPLACE"  ACTUATE="USER", right?

>  <!ATTLIST X XML-LINK #FIXED "EXTENDED">  
>  <!ATTLIST L XML-LINK #FIXED "LOCATOR">
> ]>
> 

There is no containing element - I'll assume this is all in a <TEST>
element and that this has content model (#PCDATA|X)*

> Faced with a tight situation, Sakata found a 

JUMBO would represent this (by default) as a TOC tree with 

TEST
	Faced with a tight situation...
	X
		English Translation
		Illustration
		Course Notes
		tesuji

[Note.  JUMBO guesses a 'reasonable' title for the element in the tree,
from:
	TITLE (I assume that your example means TITLE rather than LABEL :-)
else
	The first 30 characters of #PCDATA content
else
	The GI
]
All the elements would have a default behaviour of ACTUATE="USER" 
SHOW="NEW" in JUMBO if they were not XML-LINKs.  IOW if any node is clicked
it will try to display itself somehow.  For the #PCDATA it would bring up
a window with the story in.   The default display of X will be a tree unless
otherwise determined by X.class or a stylesheet (not yet implemented).

Since the elements below are all links they will have non-default behaviours
as follows:

> <X>
> <L ROLE="EG" LABEL="English translation"
>    SHOW="NEW" HREF="/cgi-bin/xlate?term=tesuji" />

Clicking on EG will try to create a new XML tree out of the TEI pointer and
display it in a new window.  The return value of the cgi-script is not defined
and is presumably an XML Element in some (unknown?) DTD.  For example, I have
developed the Virtual HyperGlossary technology using XML and it would be 
quite reasonable to use VHG as a resource to answer *this* query.  I think
that addressing into other resources is something that is poorly defined
at present and will need addressing.  Since in the above example 
?term= is not defined in XML, you take your chances on what comes back.
JUMBO deals with this if it can understand the MIME types in a table and
if it has DTDs which cover those applications.

> <L ROLE="PIC" LABEL="Illustration"
>    SHOW="EMBED"
>    HREF="pix.xml#DESCENDENT(*,FIG,CAPTION,TESUJI)" />
                          ^   ^
Here the syntax is not the same as in my spec.  (I imagine the first is a 
typo).  The second could read either:
(ALL,FIG,CAPTION,TESUJI)
or
(1,FIG,CAPTION,TESUJI)

The first will probably throw JUMBO because if there are 50 pictures of
tesuji it won't know how to mamage them.  The second will be placed in a 
special JUMBOTOC area where things are EMBEDded.  At present each new EMBED
overrides the last one, but this is mainly a tearful matter of hacking 
the awful Java AWT.  A hypercard system would be simple-ish to implement.
A click on PIC will retrieve  a FIG element (or null) from pix.xml and
will try to display it in the EMBED space.  If the FIG has a NOTATION that
JUMBO  does not understand, or if it doesn't have a NOTATION at all, JUMBO
will probably throw a wobbly.  This is why I keep hammering on about
defining the TYPE of the thing that comes back from a search :-)

> <L ROLE="CourseNotes" LABEL="Course Notes"
>    HREF="notes.xml#ID(def-Tesuji)..DITTO,NEXT(3,P)" />

JUMBO does not implement '..' for reasons previously noted.  If it *did*,
it wouldn't know that the resultant element*S* were to be displayed as 
text and you would get a tree of little bits of #PCDATA and markup.  This
is a limitation of JUMBO, which is not a text-oriented tool, but it 
highlights the need to have an *automatic* switch between tree and stream
modes of rendering.  

> <L ROLE="ToMove" LABEL="Jump to move in game record"
>    SHOW="REPLACE" HREF="game.xml#Move127" />tesuji</X>.

On clicking, JUMBO would replace the *whole of the TOC* by the object
defined at Move127.  If that were an unknown GI it would default to a 
tree-based representation.  If there were (say) a MOVE.class written in
java, then the string:
	HREF="game.xml#Move127(1,MOVE)"
would call the MOVE.display(Graphics g) routine and paint the whole
of the screen space (previously occupied by TEST) with whatever picture
of Moves were possible.  In essence my use of the MOVE in the query is my 
own trick  for imposing strong typing - and I think it could be usefully 
considered in XML-LINK.

Note that to 'go back' requires either keeping
a history list or putting XML-link REPLACE in the new object linking back to
where you came from :-).  For this reason, I don't normally replace the TOC
although I started to demo this at SGML97 before it crashed.

> 
> For naive audiences, I walk 'em through the magic of the xpointers
> and the SHOW attributes... always with lots of nodding heads.  Here's
> the problem... is the word 'tesuji' a resource of this link?  In
> other words, should it be highlighted and able to launch traversal
> on a click?

In JUMBO it already does exactly this.  (It has an icon rather than being
highlighted because it's in a tree).

> 
> It *really feels* like it should be a resource.  But according to the

I am not clear what a 'resource' is, but I have taken the view that the
result of following a pointer is either an element or a set of elements
which can be manipualted as the application sees fit.   I would find it
very hard to see any other interpretation.

> current spec, it's not unless I have another locator that says
>  <L ROLE="whatever" Label="whatever" HREF="#HERE,"/>

JUMBO has no need of this in my interpretation.

> 
> What we need to do, I think, is to say either that:
> (1) another locator as described above is required, or
> (2) any content of extended linking elements that is not a locator
>     element is to be treated as a resource.

I don't undertstand this fully.  Leaving aside subadressing, the target
of a locator is either:
	- a non-XML document (e.g. *.txt, *.html).  XML is not required
		to do anything with these, but JUMBO interprets some
		common MIME types and does its best.  (*.txt, *.html,
		*.mol, etc.)
	- an XML document in a different DTD.  I don't know what others
		do but JUMBO will try to get the DTD and parse the new 
		document in its own namespace and display it.  (This
		is why namespaces are so critical).  As you can appreciate
		this is really hairy at present.
	- a WF fragment of an XML document in the current DTD.  This should
		be displayed/processed etc. according to (a) whether it is
		an XML-LINK or (b) whether it isn't.

The last two seem to be the only things we can discuss at present.  If the
target is NOT an XML-LINK, then it is treated as if it were any other 
Element in the document (perhaps with flags to say it came from outerspace).
If it *is* an XML-LINK, then I interpret the rules as follows:

	If it does not contain AUTO, then it is displayed as if it were
part of the current document.  This might be a tree, a stream, a map, an
audio clip or whatever.  If it does contain AUTO (or if the user has
clicked it) then it is immediately processed and is never displayed.
JUMBO already does this.  Here is my example which some of you will
have seen working (rather tweaked)

<CML>

<XLIST TITLE="Assignments">
<XVAR HREF="#ass1" XML-LINK="SIMPLE" TITLE="Assignment 1" SHOW="NEW"/>
<XVAR HREF="#ass2" XML-LINK="SIMPLE" TITLE="Assignment 2" SHOW="NEW"/>
...
</XLIST>

<ASSIGNMENT ID="ass1" ACTUATE="AUTO" XML-LINK="EXTENDED">
<XVAR XML-LINK="LOCATOR" HREF="#peak1" TITLE="peak 1"/>
<XVAR XML-LINK="LOCATOR" HREF="#mol1" TITLE="mol 1"/>
</ASSIGNMENT>
...

</CML>

An assignment is an experimental observation linking a molecule to a 
peak in a spectrum (say).

When the TOC is drawn, the XLIST is displayed with its children (ASSIGNMENTs).
These do nothing until clicked.  When "Assignment 1" is clicked it locates
#ass1 which happens to be an ASSIGNMENT.  This has ACTUATE="AUTO", which
is also inherited by its children (right?).  So the ASSIGNMENT bursts into
life and starts to process its children.  *These* are AUTO XML-LINKs as well 
and therefore locate their targets which they then have to display.  
The result of this is that:
	- the original TOC is unaltered (SHOW="NEW")
	- the ASSIGNMENT is not rendered (or maybe in a NEW window)
	- the targets of the assignment are (separately) rendered in
		NEW windows.

What would happen if the XVAR had SHOW="REPLACE"?  I think 
that the ASSIGNMENT would create its tree in memory, then display its
children in new windows and then replace the TOC display with its own
'display'  Since that 'display' was to launch its own children, I suspect
the result would either be the naked tree, or would be a blank-ish 
window.  But I suspect that that is application-dependent.

Note that processing can take place *even if there is no display screen*.
All JUMBO elements have a routine process() and display(), and so 
a hierarchical structure would be traversed in a determinate order and 
every node would ultimately be processed.

I hope this makes sense and is a reasonable interpretation of the spec.
If anyone wants to use JUMBO to try this out on I'd be happy to oblige.
I *think* the version at:
http://www.vsms.nottingham.ac.uk/vsms/java/jumbo has these 
features implemented, but if not I'll need to get a new version this
week anyway.

Note that JUMBO is not very good at embedding words in text, yet.  In any
case it only honours the HTML dtd.

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

Received on Sunday, 18 May 1997 12:22:43 UTC