Re: Link-4: Extended Linking Group Indirection

In message <3.0.32.19970518112140.00b18a30@pop.intergate.bc.ca> Tim Bray writes:
> The last section of the spec discusses Extended Linking Groups.  These
> are the magic glue that makes indirect links and hypertext-i-fying
> readonly documents possible.  

I assume that this request is about additional XML-LINK syntax or semantics
which may be added to XLG.  At present XLG (I assume this means GROUP and
DOCUMENT) is trivial to implement at application level because the syntax
does not require any behaviour.  So DOCUMENT and GROUP elements don't
'do' anything unless they have attributes from LOCATOR (which they aren't
#REQUIREd to have).  

> 
> Suppose I read a doc, and it's got an XLG, which causes me to read another,

At present JUMBO will not 'cause one XLG to read another' unless there are
additional attributes such as ACTUATE.  If the cause comes from
application-dependent attributes, then we have to leave those to the 
application.

So my paraphrase of the question might be:

'If a DOCUMENT and/or a group contains an ACTUATE="AUTO" attribute, should
any constraints be placed on that?'  

If this isn't what is intended, then (at least for me) the spec needs 
redrafting :-).  I'll assume that that is what is meant.

> and it has an XLG too, that is different?  Do I go on following the XLG
> chain forever?  HyTime, whose BOS concept is related, has a BOSlength
> or some such parameter.  Things we could do in XML include:
> 
> 1. Saying nothing, and let processors work it out

This is default JUMBO behaviour in the absence of attributes.  In the 
presence of attributes, JUMBO follows each one in the order it finds it.
If this makes JUMBO roam cyberspace, then the documents need reauthoring.

> 2. Saying that XLG's should only be followed one step
> 3. Saying that XLG's should be followed for two steps.  Huh?  This actually
>    makes some sense - you could have N docs each having a single-entry
>    XLG pointing at the N+1th doc, which works as a hub document.

I don't like 2 and 3 at all.  I see XLG being used to create quite deep
hierarchies with no reason to limit the depth.  I already have an application
which requires 2 steps - with ACTUATE="AUTO" set.  I can see XLGs being used
for trees, linked lists, tables, etc.

> 4. Defining an XML-XLG-COUNT attribute that says how many steps 
>    the doc author thinks a processor should chain out, in order to
>    build the appropriate set of links.

I wouldn't argue against this, although I suspect this is more a stylesheet
issue.  For example, JUMBO has a createTOC(int depth) routine for display 
which limits the display of the tree.  The document is only one of 
several places where the value might be reasonably settable.  

If you want to avoid infinite trees or loops, etc., then a good application
should probably have a check and switch determining this.  Since we 
must remember that the target of the DOCUMENT may not be under the control
of the author of GROUP, it's impossible to say on any day how large the 
tree is.

	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:34 UTC