[
Lists Home |
Date Index |
Thread Index
]
To Simon:
First of all: I have been working a lot the past two years, so I have
missed much of what has been going on in the XML community. I am aware
that there has been quite a lot of controversy over linking in XHTML
2.0, and elsewhere, but I do not know all that much about the
particulars.
Second: I am trying to catch up, but so far this discussion has been
rather unproductive. I am interested in understanding your views and the
reasoning behind them, but not interested enough to put up with
abrasiveness and abuse from you. Therefore, if you can't reply without
being uncivil, please don't answer at all. We'll just can this
discussion, and hope we can avoid anything similar in the future.
On Sun, 2004-01-25 at 04:59, Simon St.Laurent wrote:
> henrik.martensson@bostream.nu (Henrik Martensson) writes:
> >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:
>
> As far as the vocabulary structure, there is pretty much no difference.
> There is, however, a large hassle between XLink XHTML 2.0's proposed
> "href anywhere", which is one of the smarter (and simpler) things I've
> seen.
Could please you go into a little more detail about this conflict?
I understand that to allow any element to be a link element, as proposed
in XHTML 2.0, it is necessary to allow the href attribute to be implied.
The XLink spec is admittedly a little bit fuzzy on the subject, but in
Appendix B there is the following declaration of a href:
xlink:href CDATA #IMPLIED
This means you can put an XLink href on any element when designing a
vocabulary, just as you can in XHTML 2.0.
Of course, you will still get in trouble if you want to have more than
one locator attribute on the same element, as in your img example.
However, that is hardly a life or death issue, no matter what ones
initial position on the issue.
Giving up multiple locators in favour of generic link processing seems a
good tradeoff, provided of course that the generic system delivers what
it is supposed to.
I actually did run into this problem about a year and a half ago. Then,
I chose the multiple locator on a single element solution. I have never
been quite happy with it though. Whether I would have been happier with
Extended XLink is one of the things I am trying to find out.
A very similar problem is coming up in another project I am working on,
which is one reason I am interested in your views on XLink.
I am a bit wary of using multiple locators on the same element because
Java classes will be generated from the schema, and I am not convinced
that making one object responsible for several links is a hot idea. I
prefer to keep the classes small, simple, and focused on a single task.
>
> >><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.
>
> I'd like the people who actually use the vocabulary to have the easiest
> possible time using it - that the vocabulary actually makes sense in its
> own context.
Agreed, but users rarely see any link attributes, they deal with
creating editing and otherwise managing link information through GUIs
that hide the underlying system. As long as the supported functionality
remains the same, you can replace the underlying linking system without
changing a thing in the user interface.
I do understand your point of view. My clients are usually large
corporations, and they frequently use terminology that is odd to an
outside observer. The problem isn't that they use special terms, it is
that they frequently use very common terms, that they assign a different
meaning to than the generally accepted. Also, language is a problem.
While corporate standards usually dictate XML vocabularies in English
(and only English), relatively few of the users are native English
speakers.
Buidling a vocabulary that makes sense to the users is therefore often
quite a challenge. In that respect at least, linking is actually fairly
easy, because the user sees only the name of the linking element, and
not even that, necessarily.
<snip>
>
> >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.
>
> No, but HTML is by far the most widely used form of hypertext out there,
> both in terms of authors and in terms of users. XLink's failure to cope
> with that reality - and the past hopes of the W3C TAG that they could
> impose XLink on XHTML - make the story both amusing and depressing.
I am aware that the XHTML working group chose another linking model, and
in that respect XLink failed. However, I do not know precisely why they
chose another link model. That they were unhappy with XLink is obvious.
(Remember, when it comes to knowing about what has been discussed in the
XML community, I might as well have been stuffed in a sealed box for two
years.)
>From what I have heard, some very respected people in the community were
extremely unhappy with the decisions made by the XHTML working group,
but I do not know whether this is accurate, which people were involved,
or the precise nature of the argument.
>
> >> 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.
>
> At this point I am more than tired of people on xml-dev demanding
> examples when the structure and aims of a specification are being
> questioned.
Well, try a logical chain of reasoning then. If I understand you
correctly, your argument about XLink goes something like this:
Premise 1: XLink is a generic linking system
Premise 2: Generic linking systems are bad
Conclusion: XLink is bad
That is, leaving aside issues with the particular implementation of
XLink, it is mainly the idea of creating generic linking systems itself
that you do not agree with. For example, HyTime, though the
implementation is different, is a bad idea for the same reasons that
XLink are.
Premise 2 is the interesting one: why are generic linking systems bad.
This is where I am beginning to loose track of your argument. You could
be saying:
Premise 1: We do not know enough about linking to create a linking
system that works for all cases
Premise 2: A generic linking system that covers all cases would be
enourmously complex
Premise 3: We can't predict the more far reaching implications of
creating a generic linking system
Conclusion: Generic linking systems are bad
However, I am not certain that is your point at all. If I were, we would
not be having this discussion, partly because there are valid counter
arguments that can be made, partly because none of it would have a
bearing on the project where I am now considering the use of XLink.
> I've already handed a brick (wrapped in a Christmas ribbon)
> to one person who kept asking for concrete. I find the (X)HTML cases
> clear enough, though apparently they fail to convince some group of
> people with whom I have little in common.
You are correct. The XHTML case was perfectly clear. It also failed to
convince me, and others. Even though I have found myself agreeing with
your views in other threads more often than not, we probably do have
very little in common.
>
> In general, I find the XLink approach to be much like the Pompidou
> Centre. Interesting in that it exposes all that infrastructure, but not
> a pattern I wish to follow in my own vocabulary design - and something I
> can't see encouraging as best practice even in those cases where it
> could work.
I haven't seen your work, so I can't judge the relative merits of it vs.
XLink. I am certainly interested though.
>
> I don't mind working with pointy brackets, which I see as somewhat akin
> to visible mortise-and-tenon joints, but working on collections of
> exposed URIs or unreliable defaulted attributes feels like poor
> craftsmanship.
I take it then that your designs do not expose collections of URIs, and
you do not rely on default attribute values.
A little bit of common ground: we both agree that default attribute
values are a bit dangerous. In some contexts they can be quite useful
though, so I don't write them off altogether. And of course, though
XLink uses some fixed values, there are no default ones. (At least not
in the sense that "if I haven't explicitly chosen something else, this
value is it".)
As for collections of exposed URIs, I am probably misunderstanding you
again:
Yes, Extended XLink has collections of URIs. It is hard to do multiended
links without using multiple locators. (Unless you are suggesting that
the same URI should be mapped differently depending on processing
context.) Yes, the URIs are exposed, otherwise one would not be able to
use them.
I would be interested in seeing your take on a multiended link that has
no collection of exposed URIs. The XHTML 2.0 img element does not
qualify, I believe, because, well, it does have a collection of
attributes, and their values are exposed.
>
> >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.
>
> No, you wish to talk me out and 'solve' my problems. Thanks, but no
> thanks. I've been through this set of hoops too many times with too
> many people with the same attitude.
No, I don't for a moment think I can solve your problems. Nor am I
interested in changing your opinions. I am trying to reexamine my own
opinions. As far as attitude goes, I am trying desperately to remain
civil. I am also trying to keep an open mind about your opinions.
I am trying to gather information to help me solve my problems.
Specifically, whether to use XLink or not in a project I am working on,
and, if not XLink, what would a better link design look like.
<snip>
> I find XLink's use of namespaces a poor choice for clean vocabulary
> design, it's structures both limiting and underspecified, and the claims
To a certain extent I agree with you here. For example, the way
embedding is specified, isn't much help in figuring out a generically
usable processing model.
On the other hand, XInclude does define such a processing model, and it
doesn't help much. For example, it does not specify which XInclude
elements to process when. At least when I read the spec last, it was
pretty much an all or nothing affair. You either processed all XInclude
elements, or none of them.
Also, XInclude locks an element name, visible for all to see, which is
worse than having specific attribute names, which are easier to hide
away.
Though XLink falls short of being perfect here, it is usable. (No, I'm
not implying that XInclude is unusable, or bad. I am saying that XLink
is a wee bit more flexible when it comes to embedding XML fragments.)
> about automated link harvesting boldy overstated. That you appear to
> like these things does lead me to question your judgment more generally.
So, you make quick judgements about people from faulty or incomplete
assumptions. This is not a point in your favour.
It is not necessarily a question of me liking or disliking XLink. I know
XLink, so does everyone on the development team I am working with, at
least to some extent. Most have worked with XLink for years. There is a
great deal to be won by having common ideas about how to implement
links, and how to process them.
If I understand you correctly, you are saying that the advantages of
having such common ground is outweighed by the disadvantages of the
implementation. To accept that on your say so, without making questions
as to your reasoning, would be poor judgement indeed.
>
> I doubt that you recognize these things as problems, and you're welcome
> to go on spreading the XLink gospel. You're not obligated to see as
> problems the things I see as problems. I will, however, suggest that
> they are real problems.
I am still trying to find out what those problems really are, if they
are as great as you say, and if they have a bearing on the work I do.
I know I can implement the system I work on with XLink without having to
make any serious tradeoffs, right now. If you are right, there could be
such consequences in the future. It might not be possible, or
unnecessarily difficult, to expand the system in certain directions.
Also, making the wrong choices now, could seriously affect performance
in ways that do not become apparent until it is to late, or at least
very difficult, to fix.
I wish to guard against this as well as I can.
<snip>
/Henrik
|
