[
Lists Home |
Date Index |
Thread Index
]
> Uche wrote:
> > So now he has explained clearly (for the first time, I think) why
> > the HTML WG came up with HLink. XLink did not fit well with their
> > test cases, so they specialized their own solution. The problem is
> > that HLink is really no better than XLink. It solves just as limited
> > a set of concerns. I think we've all gained nothig if we just add
> > another linking technology that covers a similar profile of problems
> > as XLink, but with a somewhat different specialization.
> >
> > I got the earlier impression that HLink was generic, and thus
> > somewhat akin to architectural forms. As I've said, I've been
> > warming to this approach since the XHTML/XLink quarrel broke open.
> >
> > So imagine my surprise to read HLink and find that it is no more
> > generic than XLink, and really nothing more than a set of selectors
> > for presentation semantics related to linking. Why didn't you guys
> > just define a new group of CSS selectors? That would have been far
> > more sensible than the compulsive wheel reinvention that I see in
> > HLink.
>
> I agree with Uche that HLink doesn't seem to be situated at the right
> level in the architecture. I don't *quite* agree that CSS would be the
> right way to do it -- I think it would be reasonable for CSS to tackle
> the behavioural aspects of linking, but don't think it's right for
> tackling the semantic "I am a link to a picture" aspect. (I've never
> been particularly comfortable with the way that XLink conflates the
> two.)
I must have been unclear. I was certainly not saying that CSS would be the
right way to do things. My point was rather that if the ambition extends no
further than what is represented in HLink, that one might as well re-use CSS.
I think if I had to design HLink, I would use RDF for the semantics and CSS
for the presentation aspects. I think Micah Dubinko is experimenting with
exactly this. Good man.
> I view AFs as doing #1 -- mapping from one markup language to another.
> As far as I can tell, the XHTML/XLink tension is interesting because
> XHTML needs more than an attribute-value-to-attribute-value mapping
> since each XHTML element can have several attributes describing
> different links -- something that XLink doesn't allow.
Yes. This is why some form of element mapping is important as well
<form href="foo" longdesc="bar">
maps to two nested elements, each with an XLink.
> To illustrate the second option, perhaps we can agree on a set of
> schema adjuncts that we can use to say "this element defines links to
> other resources as follows...". Perhaps it could even look similar to
> HLink:
>
> <element name="xhtml:img">
> <attribute name="src">
> <hlink:hlink effect="embed" actuate="onLoad" />
> <data type="xs:anyURI" />
> </attribute>
> <optional>
> <attribute name="longdesc">
> <hlink:hlink effect="new" actuate="onRequest" />
> <data type="xs:anyURI" />
> </attribute>
> </optional>
> ...
> </element>
>
> though since the effect here it mainly to describe behaviour, my
> personal preference would be to use something along the lines of XML
> Events to describe the actions and reactions to clicks and secondary
> clicks and load events and so on.
Agreed here as well. But I think it could be done using RDF with end-points
to XML events.
As for the schema adjunct idea, one nice thing about HLink is that it can be
expressed in the instance as well as the schema. Schema adjuncts would take
that away, I think.
> I guess that you could view a separate HLink document as being like a
> specialised schema, and the hlink:definition attribute as being like a
> link to that schema. (Hmm... presumably the hlink:definition attribute
> needs its own hlink:hlink element to describe it?) But we already have
> (rather too many) mechanisms for linking from an instance document to
> a process that can assist an application in understanding what to do
> with that document. Plus linking semantics are not (I'd argue) things
> that change from instance document to instance document, so it seems
> tedious to have to assert a link to exactly the same specification
> document in every instance document.
Semantics may be not (though I'm not wholly convinced of that), but behavior
can certianly be so adjusted. And any way you slice it, HLink adds to the
already towering processing pipeline problem.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html
|
