Re: DTD/XSLT mods: link and jump

[David Crossley <cr...@indexgeo.com.au>]

Here is my summary of the current situation with the
link and jump and fork elements, of various discussion
on the forrest-dev list, and of any outstanding issues.
I am not saying that i know anything about this, rather
trying to summarise it to keep the decision process moving.

----------------------------------------------------
Current situation
-----------------
http://www.krysalis.org/forrest/document-v11.html
demonstrates the behaviour. Here is just the text ...
----
<link href="faq.html">
Use this to *link* to another document. As per normal, this
will open the new document in the same browser window.

<link href="#section">
Use this to *link* to the named anchor in the current document.

<link href="contrib.html#cvshowto">
Use this to *link* to another document and go to the named anchor.
This will open the new document in the same browser window.

<jump href="contrib.html">
Use this to *jump* to another document and optionally go to a
<jump href="contrib.html#cvshowto">
named *anchor* within that document. This will open the new
document in the same browser window. So what is the difference
between link and jump? The jump behaves differently, in that
it will replace any frames in the current window.
This is the equivalent of <a ... target="_top">

<fork href="faq.html">
Use this to *fork* your webbrowser to another document. This
will open the document in a new, unnamed browser window.
This is the equivalent of <a ... target="_blank">
----

I gather that the reason for having separate elements,
rather than just the link element, was to implement the
behaviour using a stylesheet to add target="_top|_blank".

Another reason may have been to provide high-level tags
so that authors could directly use the various link-type
behaviours.

----------------------------------------------------
Summary of forrest-dev discussion
---------------------------------
<quote who="Nicola Ken Barozzi" ref="1">
As the use of the old DTD showed us, link clones are
at best confusing, and not well understood. This happens
because we have different tags with the same meaning,
but different behaviour.
</quote>

The discussion seemed to point to having only one element
... <link> ... with various attributes.

The consensus was to not have an "anchor" attribute,
but rather use the conventional # in the href.

So ...

<link href="..."
 [external="true|false"]
 [target="..."]
 [role="..."]
 [title="..."]
/>

where ...
href = the URL, which may include an optional named anchor using #
external = define whether it is out-of-context (default false)
target = named window or frame, e.g. _blank or _top
role = (already in DTD, what is its purpose?)
title = (already in DTD, what is its purpose?)

----------------------------------------------------
Other issues
------------
* The demo document-v11.html needs to provide clear examples
and guidance about what situations the various possible
link attributes should be used. [3]

* There are some other link attributes that were in the
document-v10.dtd which are dropped from document-v11.dtd
These were to do with XLink. Was this drop intentional?

* I became a little rushed towards the end of this summary.
The discussion was in various threads, and i started to get
lost.

-------------
References:
[1] http://marc.theaimsgroup.com/?l=forrest-dev&m=102205960400385
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=102205550129667
[3] http://marc.theaimsgroup.com/?l=forrest-dev&m=102313254519092

Re: DTD/XSLT mods: link and jump

[Stefano Mazzocchi <st...@apache.org>]

David Crossley wrote:
> 
> Here is my summary of the current situation with the
> link and jump and fork elements, of various discussion
> on the forrest-dev list, and of any outstanding issues.
> I am not saying that i know anything about this, rather
> trying to summarise it to keep the decision process moving.
> 
> ----------------------------------------------------
> Current situation
> -----------------
> http://www.krysalis.org/forrest/document-v11.html
> demonstrates the behaviour. Here is just the text ...
> ----
> <link href="faq.html">
> Use this to *link* to another document. As per normal, this
> will open the new document in the same browser window.
> 
> <link href="#section">
> Use this to *link* to the named anchor in the current document.
> 
> <link href="contrib.html#cvshowto">
> Use this to *link* to another document and go to the named anchor.
> This will open the new document in the same browser window.
> 
> <jump href="contrib.html">
> Use this to *jump* to another document and optionally go to a
> <jump href="contrib.html#cvshowto">
> named *anchor* within that document. This will open the new
> document in the same browser window. So what is the difference
> between link and jump? The jump behaves differently, in that
> it will replace any frames in the current window.
> This is the equivalent of <a ... target="_top">
> 
> <fork href="faq.html">
> Use this to *fork* your webbrowser to another document. This
> will open the document in a new, unnamed browser window.
> This is the equivalent of <a ... target="_blank">
> ----
> 
> I gather that the reason for having separate elements,
> rather than just the link element, was to implement the
> behaviour using a stylesheet to add target="_top|_blank".
> 
> Another reason may have been to provide high-level tags
> so that authors could directly use the various link-type
> behaviours.
> 
> ----------------------------------------------------
> Summary of forrest-dev discussion
> ---------------------------------
> <quote who="Nicola Ken Barozzi" ref="1">
> As the use of the old DTD showed us, link clones are
> at best confusing, and not well understood. This happens
> because we have different tags with the same meaning,
> but different behaviour.
> </quote>
> 
> The discussion seemed to point to having only one element
> ... <link> ... with various attributes.
> 
> The consensus was to not have an "anchor" attribute,
> but rather use the conventional # in the href.
> 
> So ...
> 
> <link href="..."
>  [external="true|false"]
>  [target="..."]
>  [role="..."]
>  [title="..."]
> />
> 
> where ...
> href = the URL, which may include an optional named anchor using #
> external = define whether it is out-of-context (default false)
> target = named window or frame, e.g. _blank or _top
> role = (already in DTD, what is its purpose?)
> title = (already in DTD, what is its purpose?)
> 
> ----------------------------------------------------
> Other issues
> ------------
> * The demo document-v11.html needs to provide clear examples
> and guidance about what situations the various possible
> link attributes should be used. [3]
> 
> * There are some other link attributes that were in the
> document-v10.dtd which are dropped from document-v11.dtd
> These were to do with XLink. Was this drop intentional?
> 
> * I became a little rushed towards the end of this summary.
> The discussion was in various threads, and i started to get
> lost.

As the original author of the Document DTD, I think I need to finally
take some time and jump in this discussion.

At some point, the idea was to use XLink. Unfortunately, XLink is
complex, heavy, hard-core namespace oriented (which is generally a good
thing, but since we still use DTDs, this is a real PITA)

For this reason, I decided to "extend" the hyperlink notion of HTML into
a more semantically meaningful markup. I identified three different
behaviors, each became a different tag

 - link -> replaces the view containing the link with the linked
resource
 - jump -> replaces the entire viewport with the linked resource
 - fork -> creates another viewport with the linked resource

all these identify a 'starting point' of an hyperlink action.

Then, noting that the presence of the A/@name and A/@href change the
meaning of the element itself, I identified this as a markup design
mistake. This lead me to conclude that I needed a different element for
the 'ending point' of a hyperlink action. I identified only one:

 - anchor -> identifies an intra-document ending point (every URI has an
implicit empty anchor at the beginning of itself)

At some point, I came up with the notion of 'soft linking' and 'hard
linking'. This is the reason why there is the 'role' attribute.
Currently is not used. But, for example, it could be used to identify a
different "way" to interpret the link itself (for example, allowing
link-map resolutions, etc.)

[the 'title' attribute is useful for tooltips and visual onmouseover
helps]

                              - o -

This said, after some thinking, I'm willing to reconsider those three
different link starting points because they mix concerns: the document
author doesn't know, nor should, if the hyperlink will be executed in a
fragmented viewport or if it makes sense to clear up the viewport (think
about navigation provided by frames).

The same could be said for forking the viewport. It is *not* the author
concern to determine *how* a particular hyperlink 'type' must be
translated in the appropriate hyperlinking behavior.

So, for this reason, one solution could be to flat out the hyperlink
elements to

<link href="..."
  [type="..."]
  [role="..."]
  [title="..."]
/>

and 

<anchor name="..."/>

One for the starting point, one for the end point.

At this point, the 'contract' is moved over to the definitions of
'roles' and 'types'. 

Note that both are required because they are independent, for example

 <link href="urn:apache-home-page"
       type="external"
       role="linkmap"/>

or 

 <link href="http://www.apache.org/"
       type="external"
       role="as-is"/>

NOTE: the type and role names are just an example, I'm not proposing to
use those.

Or, we can decide to make everything implicit and have Forrest associate
the linking behavior based on the URI only.

So, 

 <link href="urn:linkmap:apache-home-page"/>
 <link href="http://www.apache.org"/>
 <link href="index.html"/>
 <link href="#welcome"/>

the only problem with this approach is that the document author lacks
the ability to indicate that a particular link must 'fork' the viewport.
But this might not be a problem since usability guidelines state
normally against forking the viewport in any circumstance.

What do you think?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------