[
Lists Home |
Date Index |
Thread Index
]
On Sat, 2004-01-24 at 15:40, Simon St.Laurent wrote:
<snip>
>
> I find that for a large class of links it works very badly. In
> particular, it seems utterly incapable of working with HTML's structures
> - something that was once a goal but disappeared. In terms of practical
> application, that largely kills it.
Please give a practical example of the problems with the structures of
XHTML. (I assume you meant XHTML, and not HTML.) BTW, I did read the
src/href example:
><img src="thumbnail.jpg" href="fullpicture.jpg" />
It was done in a way that makes it necessary to write special linking
code that works only for XHTML, even though the same linking problem
crops up in most XML formats for authoring human readable documents. Not
a good way to solve the problem, unless you are a consultant and want to
charge over and over again for doing the same thing.
You could do this:
<img xmlns:e="http://iwillpatentthis.org/link/embed/onload";
xmlns:t="http://iwillpatentthis.org/link/traverse/onclick";
e:src="thumbnail.jpg"
t:href="fullpicture.jpg" />
This would be pretty close to what you suggested, with the added benefit
that the links can now be processed by generic link processing software,
even if the attribute names are changed. However, I suspect that you
would not like this solution. I don't, though my reasons may be a little
different from yours.
Even if it were true that XLink would not be practical for use with
HTML, that would be no reason to kill it. HTML itself isn't very useful
for authoring structured information. Nobody has suggested killing it
off because of that. Err, let me rephrase: nobody will succeed killing
it off because of that.
<digression>
I wonder if the idea of a namespace for things that you intend to patent
is patentable. If so, remember that I have first dibs on the idea. ;-)
</digression>
>
> >XLink does not have to work for everything. It just has to work for
> >enough types of links to make it advantageous to share code. It does
> >that.
>
> Perhaps, for the subset of cases where the above criteria apply.
>
> >I have worked on implementing XLink systems at Ericsson, NDC, Volvo,
> >Scania and other companies. The linking systems work very well. I have
> >also been able to reuse enough code to make it worthwhile to develop
> >it.
>
> That's basically like telling me "but W3C XML Schema works for my cases,
> so how dare you complain about its failings?"
No, that is not what I am saying. I am saying that your argument:
a. is contrary to my personal experience with XLink
b. would be more convincing if you provided examples
It is very obvious that you have strong feelings about XLink, just as I
do. I would be very interested in learning about particular instances
where using XLink got you or someone else into trouble. This would, I
hope, enable me to understand your views a bit better.
I am not saying that you should not criticize XLink. On the contrary, we
should always view XML recommendations with a critical eye, just as we
should everything else with a critical eye, except spouses. If we don't,
we can't improve anything, ever. I do say that while you make your
feelings perfectly clear, it is less clear, to me at least, what they
are based on. That is why I ask for examples. I want to understand your
point of view.
>
> >The biggest problems I run into are not with XLink per se, it is with a
> >poor understanding of the concepts of linking. That must be dealt with
> >no matter what linking system you want to implement.
>
> Thanks, but I think I understand linking pretty well after 15 years in a
> wide variety of different situations. The problems are not merely with
> the users.
What users? The users rarely need to know what link system is under it
all. You don't need to know MIF to make a cross-reference in FrameMaker.
You should not, and do not, need to know about XLink to make a cross
reference in RML. (RML being an otherwise uninteresting markup language
that does use XLink.)
I was discussing developers and managers.
>
> >XLink certainly isn't perfect, but from a technical point of view it
> >accomplishes pretty much what it sets out to do. One could certainly
> >argue that it could be done better, but as far as I know, to date it
> >hasn't.
>
> As long as you take a narrow view of requirements, it's easy to achieve
> them. XLink sort of vaguely mostly does this except for losing HTML
> along the way, but that doesn't account for the costs it imposes either.
Again, please show me an example of a commonly occuring linking problem
that XLink addresses poorly. Then show how using XLink would impose
extra costs beyond those you would get with a link system specially
built to handle the task.
>
> >> I'd rather see gatekeepers doing this work than trusting it to kings
> >> and councils.
> >
> >I find this appealing, but the gatekeepers are at it now, and they are
> >making a mess of it.
>
> Which gatekeepers are you talking about?
The people directly in charge of choosing, designing and implementing
links in XML applications in corporations big and small, various W3C
committees, and other bodies that develop XML vocabularies.
I thought that was what you meant. Then again, I probably misunderstood
you. Which gatekeepers did you mean?
>
> >If initiative is defined as writing the same boring implementations for
> >cross-references and subdocuments over and over again, then you are
> >right.
>
> I'd prefer to define initiative as crafting solutions that fit
> particular problems well. If you'd prefer to automate things and
> thereby avoid thinking about them, I think you have some deep problems
> that may well please your employers but produce enormous brittleness in
> the longer term.
I see now. I have a different opinion than you, so obviously I must have
"some deep problems". I will of course call my clients and warn them
that you have discovered that my link designs are brittle. It is
embarrassing to think of all the effort we spent on review boards,
independently working reviewers, and so forth. We should have saved our
money and just called you.
Thank you for pointing my problems out, it was very helpful. Really
strengthens your argument.
If it bothers you to automate things in order to avoid thinking about
them, then I wonder why you are interested in XML at all, or computers
for that matter. The reason for defining XML vocabularies is to be able
to automate things easily. The reason for automating things is to be
able to avoid thinking about them. (Well, there are other reasons too,
of course.)
Note that this is not the same thing as avoiding thinking altogether.
Automation just frees up brain power, so that we can think about
something else.
>
> >In every SGML/XML project I've been in the past five years, the same
> >linking problems have always cropped up. Every time I have to sit
> >through the same discussions, and use the same arguments and
> >counterarguments. XLink makes it possible to write a piece of software
> >that solves the problems, point to it and say "we'll use that!". Then
> >you can move on to more interesting things.
> >
> >I agree that XLink does not solve every linking problem. However, I
> >think that the main problem isn't that XLink is bad, but that the
> >concept of linking itself is poorly understood.
> >
> >Given the complexity of the problem, and the low level of understanding
> >generally, XLink does a remarkably good job.
>
> As noted above, I disagree with this assessment on every point.
Strangely, I am not bothered by this. However, I can't resist pointing
out that you have just disagreed with both of the following statements:
* XLink does not solve every linking problem
* XLink does a remarkably good job
> Fortunately, it doesn't matter much, as XLink seems unlikely ever to
> escape from the niches where it has found a home.
Sadly, you are probably right. XLink will probably never be very
popular, regardless of its qualities. Whether something really is good
or bad matters much less than the perception of it.
/Henrik
|
