Anchors Aweigh

Jon Bosak wrote:

> ...what we seem to be left with is a clear reason to define
> a contextual link mechanism for general Internet use in our first link
> specification document and a possible case to be made for defining an
> independent link mechanism for intranets that we may want to put in a
> first link specification document or may want to defer for a later
> version.
> 
> Is that right?

We need independent links for link management in a multihub hypermedia 
system where a hub language is any handled type that is hyperlink
capable (multimedia).  E.g,  an Illustrated Parts Breakdown and the
supporting 
graphic sequence (called a Figure, but multiple sheets) contain 
bi-directional content relationships which are more easily managed 
with independent links.  We do it now with clinks.  Hard to maintain.

IMO&D, independent links are address records; clinks are controls 
with local address records.  Confusion starts there.  
Self-awareness is not a good metaphor.  Some contributions form 
the object-oriented community would help here (Derek?  Gavin?)

HyTime, TEI, FPI, URN, I don't care:  ease of management of n-way links
is 
what is needed.  What would really help this discussion more than 
abstractions on linking would be set of IDLs for an XML handler.
Define the XML handler public services.

For object oriented programmers to build what we 
say we want, we have to tell them how much the XML spec 
defines the behavior of the system that handles it?
What services do we want from that .dll?  What is 
the XML handler interface to the framework?



Location resolution is a framework feature.  It's a protocol issue.

Protocol implementation is a system implementation.  Engineers 

know this and so demand that a proposal for a protocol always 

be backed up with the code that runs it.  Fact of life these days.



o  Will XML hyperlinks be designed ad hoc?  I have mine, you have yours, 

etc.  That is the current situation with respect to SGML hypertext 

systems. We all have hyperlinks.



o  Are we to define minimum interoperability of hyperlink types?  



o  Are we defining types of hyperlinks 

which are extensible semantically (attribute, GI, whatever) 



o  Are we to develop a set of element types which are 
XML hyperlinks? (i hope not but it's the easiest punt)



Given: If XML wants to define hyperlinks, XML has to provide an

implementation of the protocols required to support the 
hyperlinks or ensure the hyperlinks fit within the constraints 
of existing protocols.



OTH, hyperlinks are not locators.  Do we have to design a protocol?
Do we need a stateless or a stateful protocol?  Both?



WWW Today: URL with sub-file target parameters (e.g, #targetname, string 

du jour) or URL as address type for semantic, e.g, object, img, 
thingieDuJour).  For comparison, here is a VRML anchor:

Anchor {
	eventIn  MFNode addChildren #tree operations
	eventIn  MFNode removeChildren
	exposedField  MFNode children 
	exposedField  SFString children [ ] #geometry, materials, lights, etc.
	exposedField  SFString description "" #displayed text
	exposedField  MFString parameter [] #value-pairs, eg, frame targets
	exposedField  MFString url [] #get this, target, move-to-viewpoint
	field		  bboxCenter 0 0 0 #local space origin
	field		  bboxSize -1 -1 -1 #max size local space
}

  

We use a similar mechanism in IDE/AS where the link has goodies such as 

targetname (file), system handler (who gets this), system arguments 

(commands and command parameters (byte offsets, pixel positions, 

named objects) all used in the DDE dance).    

In some cases, (e.g., graphics) all documents of that content 
type are being handled by a single system (e.g., ImageMaster).  
Look's like a helper app but not really.  It is actually a peer 
in the sense that it also handles a hub-capable data type  
where a hub-capable type has hyperlinks.

Hub:  any notation that is hyperlink capable.

How does XML represent hyperlinking services to the 
other notation handlers?  Other hubs?
Could we just say, object handlers?

o  Is this an XML-definable content relationship?

o  Is this a Java or Active-X interface?

Services of objects are defined by the framework.
Are we offering an abstraction of that?

One way to look at this is to ask, for n-way links 
what is as the minimal service set available to all 
hubs in the system?

o  What are the services of the objects of the framework 
in which XML handlers operate?

o  What are the services of the XML handler?

o  What are the requirements of the XML user that must 
be implemented in the XML handler services?

Requirement:  easier management of linked relations
(e.g, independent links)

Requirement:  declare relations among content types 
without needing to know the handler type at the 
hyperlink or at least, where that is prioritized 
and/or negotiated (e.g, location ladders)

Uni-directional links are hard to build and maintain 
for some content types.  For example,
the relationships between an IPB and the figure 
sequence to illustrate it are bi-directional. 
We end up coding every link twice in a domain whose
range is bounded by topic, task, part, script, etc.  
On a good day, twice the maintenance, twice the 
headaches.

The relationships to the procedures which use the 
IPB/graphic are indexed to the key numbers of the 
IPB/graphic where the key number names the 
relationship by local unique id (number list), 
not logical name.  

From any content node in this system, there 
may be collections of nodes which support this with 
topics (description, task-direction, policy, e-mail, 
task recording (e.g, collaborative)).

o  An XML hyperlink designer might want a way to validate a 
   referenced content type.



o  An XML hyperlink designer might want to say, in this IPB, this 

   table always has a set of view types (graphic primitives in CGM, 

   camera positions in VRML, bitmaps in whatever), or in this 
   procedure, a collection is returned by a query whose parameters
   are output conditions of the last procedure



o  An XML hyperlink author might want to say, here is a list of

   URLs, (priority, aggregate, etc.)


XML has to be able to support all of that because 
XML users need all of that.  XML has to support 
not just the Web, but what the Web is becoming:
a business for authoring to the street in 
one straight no-nonsense publishing path.

When books emerged, it was not from academic 
struggle or desire.  It was when certain merchants found 
it necessary to smuggle records in carts of linen  
across borders.  Then the academics and the merchants 
had all the books they could have ever wanted.

len bullard
dec 25, 1996

Received on Thursday, 26 December 1996 01:27:51 UTC