[
Lists Home |
Date Index |
Thread Index
]
Uche Ogbuji <uche.ogbuji@fourthought.com> wrote:
|> [HLink] is adopting the same conceptual disaster as <OBJECT> -
|> overgeneralization in a single element type, a false economy.
| It is the hlink element itself that you find an over-stuffed concept,
| right? Not the elements it describes.
Right.
For instance, the 'locator' attribute - which for a while I thought was
the Prince of Denmark in the draft's Hamlet - turns out to be optional!
Well, one reason why it can't be required is that apparently a HLink
element can also be used to describe an arcrole (in the XLink sense), via
an 'arcrole' attribute.
[Before someone says that this is a critique of DTDs for having no way to
express the mutual exclusivity of the locator and the (arcrole,from,to)
attributes, they should heed Joe English's insight from a long time ago:
http://listserv.heanet.ie/cgi-bin/wa?A2=ind9508&L=html-wg&P=R14154 ]
The XLink spec addresses this issue with a usage matrix (Section 4.1).
The fact that 'type' is 'R' across the board there also means that XLink
can be trivially restated in terms of element types corresponding to the
'type' enumeration (as in fact is done in Appendix B), and it can even be
used in this restated form with standard AF-style mapping techniques.
(There could be no *harm* in doing so, only that the W3C has different
ideas about *syntax*.)
AFAICS, if the arcrole stuff were tossed, locator could be made mandatory.
This is useful in that HLink could then be about locators. However, the
bulk of what's been set down so far has to do with behavior. I think that
"effect" and "actuate" are the main players, especially since they have
default values: "replace" and "onRequest". So, what if the HLink spec
defined a set of element types based on behavior, with names like
<replacement>, <embedding>, <submission>, <linkmap> and maybe <arcrole>
(with the locator attribute mandatory for the first four and undefined for
the last). The definitional requirements for each type could be analysed
separately, and only then perhaps the common core drawn into a "virtual"
<hlink> element type?
Basically, I'd like to see more required and fewer optional attributes.
|
