Re: Anchors Aweigh

W. Eliot Kimber wrote:
> 
> TEI expresses itself and the interface between a HyTime
> engine and a TEI engine is well defined in terms of the property sets,
> groves, and grove plans both act on.

This is good.  If (for example only), one wants to create the 
object-oriented implementation of these engines would one create:

o  A class(es) of TEI objects including a TEI engine

o  A class(es) of HyTime objects (including property sets)

The idea, I think, is to specify an interface as what 
a programmer thinks of it as: a virtual or real method 
interface.  

No, this is not the XML standard;  it is a way to discuss 
the XML standard for hyperlinking in examples that a 
programmer would find clear.  I plead for help from 
the object programmers on the list.

> Without reference to Tim's original post, I think the issues are:
> 
> 1. What syntax(es) to use for representing addresses?
>    1.A HyTime location addresses (some or all) only (must include
>        URLs as a query notation that must be supported, in addition
>        to being used for entity external identifiers.).

Please note the URL is under revision.  It includes it's own
notion of querying so, does this imply that to the Hytime view, 
a URL is simply a system for querying?  IOW, others are 
possible but any sensible implementor uses the URL.  For the WWW, the
URL 
is the lynchpin.  Also note, at this time, URN definitions 
conflict with URL definitions (per Roy Fielding's post to 
uri.bunyip).  Prepending the prefix appears to be illegal.  
Someone more familiar with theseissues should investigate if 
this has implications for use of URNs and FPIs in XML.

>    1.B TEI locators only

We pick victims.  TEI implementations go on (what there 
are of them), the majority of SGML hypertext implementations 
fall.  It may be the best choice, but it is not without 
consequence.

>    1.C Some combination of 1.A and 1.B

This appears to me to be best.  TEI goes on at 
current pace; other apps have room.  Now, what 
happens to interoperation?

>    1.D Only in style sheets

See below.
 
> 2. How to bind addresses to links
>    2.A direct only
>    2.B Indirect only
>    2.C Direct and indirect

2.C
 
> 3. Whether or not to define links that can be completely independent.

It appears that everyone wants this.  Please advise if that is 
an erroneous assumption.  If so, we assume that it is a goal.

> 4. What syntax to use to represent links (probably separate from
>    addresses).  Here the choices seem to be:

>    4.A  SGML elements of the HyTime model without trickery (ID/IDREF
>         primary addressing method plus indirection)

Pardon if I hash this:  I've not time to review the 
new HyTime work.  If I understand, using 4.a:

Id points to Idref of target.  Target classes may be actual 
nodes (e.g, an element with a valid SGML ID), or to a locator 
which in turn by convention indicates a semantic for locating 
the target (e.g, relloc, dataloc, etc.) and the needed property 
values to be passed to the locator resolver.

>    4.B  SGML elements of the HyTime model with refloc/queryloc
>         stuff to make use of non-HyTime addresses easier for authors.

Ok.  Depending on what is "trickery" this seems to be 4.A.  What 
is the difference?

>    4.C  SGML elements of some other model that can't be reconciled
>         with HyTime (I don't think such a thing can be made, but
>         I won't rule it out).

If no example is presented, take the position it is absurd 
so not worth considering.

>    4.D  Define only in style specifications

4.D contravenes existing widely adopted practice.  "only" is a
non-starter.

I have no opinion that use of stylesheets is "good or bad" for 
defining links.  It does make sense but it is not what the 
user knows.  I agree we should not bind XML to existing practice, 
but neither should we get so advanced we "drop the dancers on their 
posteriors" as we say in the music business when a tune is too 
progressive to work in performance.  There is always a way 
out of the "no win" scenarios.  I also don't believe in 
the Kobayashi Moru.

> 5. What formalism to use in defining links and link types:
>    5.A  Strict requirement of HyTime's linktype/anchor role model
>    5.B  No required model (no need to define link types or anchor
>         roles)
>    5.C  Both 5.A and 5.B (be formal or not, we don't care).  Note this
>         is HyTime as of the TC.

How does an XML application designer inform an XML user that 
an XML element type is a link or an ilink?

>    5.D  Some other model that I'm not aware of

Absurd.
 
> 6. What base behaviors to define for links or link types, if any.

6. is convenient.  If no base behaviors are defined, then XML should 
if only in an informative appendix, show how base behaviors can be
defined and 
used interoperably.  Users of existing systems do understand the 
meaning of <a, etc.  It is convenient to define and share among 
a collection of XML document types, a set of recognizable and 
predictable link types.
 
> 7. How to allow authors or users to define or modify link behaviors,
>    if allowed at all:
>    7.A Style sheets only (e.g., DSSSL language for describing link
>        behavior.
>    7.B Attributes on link elements
>    7.C Some other mechanism

If by an XML author, we mean the traditional author, I think this 
is an application issue.  An XML implementor may choose to forgo 
DSSSL, CSS, whatever, and hardwire behavior in the class methods.
OTH, using such means to modify behaviors is certainly an 
established practice in other web languages such as VRML.

Ralph mentioned the SMSL project in another post.  SMSL is an 
ISO project.  XML is a W3C project.  Should we establish 
scopes that enable these projects to be mutually reinforcing? 
Can we?

len

Received on Saturday, 28 December 1996 15:35:48 UTC