xml-dev - RE: XLink transformations

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

It is and I've said before that the issue with 
hyperlinking back to the Hytime drafts was not 
being able to tell if a behavior is associated 
with a hyperlink.  We had some *contentious* 
debates in the XML interest group over this. 

We know by observation an <a href="" goes somewhere, but without 
the implementation, we don't know how.  The 
user doesn't always need to know, but the 
author does, so hyperlinks and address 
resolution are intertwined as a practical 
matter no matter whose implementation or 
theory is invoked.  We sprinkle the "fairy 
dust of objects"  because as magic goes, 
it produces repeatable results.  There are 
other kinds of magic.  "Where do you want 
to go today?" but the repeatability is at issue.

As time goes on, I'm not convinced the 
case for hyperlinks is worse than the case 
for any markup element:  is it

1.  A data object.  A structure (say, struct) 
with declared data (see Horowitz and Sanhni: 
Fundamentals of Data Structures).  Implementation 
independent but unreliable.

2.  A class.   Includes the methods.  Reliable 
but implementation dependent.

3.  Neither or both depending on context.  This 
is the "choose the form of the Destructor" problem. 
Careful what pops into your head because the 
results may be "sticky".

In HyTime, the answer was that the best one 
could do was abstract the types of hyperlinks 
depending on the type of addressing and that 
dependent on the context of the location.  In that 
sense, it is a data object.  However, on the 
bold move to XML, a lot of otherwise reasonable 
people became convinced that elements are classes 
and that made the JavaHeads happy.  It is unfortunately, 
not of necessity true but it is in practicality, useful.  

IMO: Read the contracts.  

If the element contract is only declaring a relationship, 
it is a data object.  If it declares a means or 
description of its resolution (the semantic), it is a 
class.  Note that without such *contentious* specs 
such as HTML Components, it is pretty difficult to 
build over this reliably and reusably.  To quote 
Dr Goldfarb, "eventually, somewhere a bit must 
change state".  HTCs and binary components do provide 
a means to build and are simple enough to teach 
to the less well-trained.  I like them for practical 
reasons but I understand the problems of univerality 
of asp:myThing namespace.  On the other hand, schedules 
and budgets delimit results.

There is only so far declarative systems get one 
before a function is needed and at that point, 
the reliability of interoperation becomes statistical.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]

Hyperlinking has always been something of a hydra, and I'm afraid that the
delays on XLink have left it a sleepy hydra.  On the other hand, the spec's
a lot better than it was....