[
Lists Home |
Date Index |
Thread Index
]
Micah Dubinko wrote:
> I think I understand the idea behind the design of XLink. Here's an example
> of how it breaks down.
Do you know of another example? Honestly, this one totally fails to
convince me. The ability to understand links without knowledge of the
vocabulary seems to me to be of high value. The ability to stuff
embedding and hyperlinking on the same element appears to me to be of
fairly little value. The first reaction I had upon seeing that a few
months back was "what if I want the content there to come from two (or
more) sources instead of one?" Inserting multiple pieces of content into
a single div is something that I tend to do a lot. Having a separate
element for inclusion cuts it better, and avoids hacks such as putting
in two div when your structure calls for one.
SVG has <a>, <image>, and <use> for various linking purposes, and is
adding extended links (http://www.w3.org/TR/SVG12/#extended-links), all
of that using XLink. I am not aware of that causing problems in any
aspect of our vocabulary designing, and feedback from the community has
been extremely positive.
> When combining vocabularies, the chances of something like this happening
> increase exponentially. Refactoring (so that the above construct would use
> two elements), or using complex links often is either not possible or too
> much hassle when you simply want to combine two pre-defined vocabularies.
Can you give an example of combining two vocabularies (say, XHTML2 and
SVG) where the use of XLink would create a clash? There's a lot of
upcoming good thinking to be done in that area, and that's an
interesting angle to look at it from. It would seem to me, on the
contrary, that having a single linking construct would be far better in
compound document situations.
--
Robin Berjon
|
