RE: SkunkLink: a skunkworks XML linking proposal

Some discussion:

Hate it or love it, a proposal for a modest 
system designed to grow into a more capable 
system has to understand where the opportunities 
for growth will be.  Do you have a comfort 
level for having done that or do you think that 
simplification (eg, just two common attributes) 
will support growth?

The flaw of Hytime was in trying to fully and 
rigorously specify all linking 
functions in a consistent model which became  
predictably complex.  The flaw of URzeds was in  
using an abstraction to circumscribe but not 
specify all linking functions which is simple 
on the surface but becomes surprisingly complex.
  
In the first example, successful implementations 
carved off a piece and implemented that satisfied that this 
implementation could "grow" into more capable 
systems.  In the second case, endless experimentation 
has been required to discover ways to adapt running 
code based on the simple approach to evermore 
complex requirements including support of named 
abstractions.

So predictable growth at the cost of an unattractive 
standard up front or growth using an attractive 
specfication with unpredictable costs?

BTW:

1.  The common attributes approach has been considered 
before.  That evolved into architectural forms.  Maybe a 
less evolved solution is better.

2.  Users think hyperlinks are controls (complex 
objects).  The TAG et al insist that they are identifiers 
(value properties).  

The software supports the illusion that the users are right.  
Unfortunately, the user and some implementors can't 
understand after that why partitioning the URI won't 
solve all their problems.

len

From: Micah Dubinko [mailto:MDubinko@cardiff.com]

I've spent some time thinking about XLink, HLink, and why hardly anybody
likes either one enough to cough up an implementation.

My impression is that both XLink and HLink miss the 80/20 mark; both cover
an amazingly rich amount of ground for a version 1.0 specification. Nearly
everyone I talk to agrees that smaller, more understandable, more modular
specifications would be better. A smaller specification that leaves room to
grow might be a better approach.

Received on Monday, 6 January 2003 18:11:22 UTC