[
Lists Home |
Date Index |
Thread Index
]
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.
|
