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
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
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
> 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
> 2. How to bind addresses to links
> 2.A direct only
> 2.B Indirect only
> 2.C Direct and indirect
> 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
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
> 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
> 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
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
> 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?