Re: Link-4: Extended Linking Group Indirection

In message <6803@ursus.demon.co.uk> Peter@ursus.demon.co.uk 
(Peter Murray-Rust) awaits enlightenment:
> 
> 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).  

I do hope that others comment on this area, because it's not trivial to
work out what should be implemented.  I've arrived at the present analysis
and would like some feedback.

DOCUMENT and GROUP don't *do* anything and they are purely structuring
elements.  An example (A) is:

<!DOCTYPE FOO [
<!ATTLIST UL XML-LINK CDATA #FIXED "GROUP">
<!ATTLIST LI XML-LINK CDATA #FIXED "DOCUMENT">
]>
<FOO>
<!-- let's forget the whitespace for today -->
<UL>
<LI><A HREF="foo.xml" TITLE="foo"/>
<LI><A HREF="bar.xml" TITLE="bar"/>
</UL>
</FOO>

which says it all.  So what is the point?
	(a) there is a recognised attribute GROUP which can be located
*independently of the application*.
	(b) The children of GROUP have to be DOCUMENT and nothing else 
because the XML book says so.  The parser won't enforce that, and it's up 
to the DTD designer to make sure that GROUP has a content model of 
(DOCUMENT)+ - unless we are altering the parser or building a post-parser.

	So - the post-parser can verify that GROUP has only DOCUMENT children.
Everything after that is application-dependent.  Our contract with the
application is to hand it a well-defined container, but with no XML
semantics for behaviour.  Now let's use EXTENDED and LOCATOR (Example B)

<!DOCTYPE FOO [
<!ATTLIST UL XML-LINK CDATA #FIXED "EXTENDED">
<!ATTLIST LI XML-LINK CDATA #FIXED "LOCATOR">
]>
<FOO>
<UL>
'Twas brillig
<LI><A HREF="foo.xml" TITLE="foo"/>
and the dsssl-goves
<LI><A HREF="bar.xml" TITLE="bar"/>
did gyre...
</UL>
</FOO>

Example A and Example B have certain similarities.  (In fact they are 
identical apart from:
	(a) their handles (GROUP/EXTENDED)
	(b) #PCDATA forbidden in A
	(c) implied ACTUATE="USER" SHOW="REPLACE" in B)

The main difference seems to be that EXTENDED has XML-based display/traversal
semantics and GROUP has not.  Everything in GROUP can be catered for by
EXTENDED, so why have it?  The only answer I can come up with is that 
GROUP is a mechanism for *forbidding* display/traversal of a resource by the
XML default and leaving it to the application whether it wants to.  This
seems unnecessarily complex.  If we don't want to display something, let's
just say so.

I'd come to this conclusion from the other end.  Suppose we have a set of
links like:

<!ATTLIST UL XML-LINK CDATA #FIXED "EXTENDED" SHOW CDATA #FIXED "NEW">

<UL>
<LI><A HREF="#mammal" TITLE="mammal"/>
<LI><A HREF="#fish" TITLE="fish"/>
</UL>
...
<UL ID="mammal">
<LI><A HREF="#eutheria" TITLE="placental animals"/>
<LI><A HREF="#marsupialia" TITLE="marsupials"/>
</LI>
...
<UL ID="eutheria">
<LI><A HREF="#proboscidea" TITLE="jumboids"/>
<LI><A HREF="#primates" TITLE="primates"/>
</UL>
...
<UL ID="primates">
<LI><A HREF="homo_sapiens" "TITLE="humans"/>
<LI><A HREF="gorilla_gorilla_gorilla" TITLE="gorillas"/>
</UL>
...

Now - what happens when I actuate HREF="#mammal"?  JUMBO's answer is to
bring up the default display for a UL/EXTENDED - probably a list box. If I
actuate #eutheria, then I get another list box, and so on.  Ultimately I
get a picture of a human, or whatever.

If I write
<!ATTLIST UL ACTUATE="AUTO">
and click the mammals, I traverse every branch of the hierarchy and get 
several hundred pictures (kangaroos, whales, etc.).  I would probably
like to do this this without displaying all the intermediate list boxes.
BUT these must be traversed in display mode which means SHOW = something.
<PROPOSAL>
A new value NULL should be added to the SHOW model group.  This attribute
would enable all traveral to be carried out, but would not require the
element to be rendered.
</PROPOSAL>
<CONSEQUENCE>
GROUP is now the same as XML-LINK="EXTENDED" SHOW="NULL" (apart from the
#PCDATA, which could be ignored if required).
</CONSEQUENCE>

If this analysis is right, we need a NULL attribute for SHOW and we no longer
need GROUP and DOCUMENT.  If labels are required, then we can either
search for EXTENDED SHOW="NULL" or use ROLE.

	P.


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

Received on Monday, 19 May 1997 19:27:24 UTC