OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [Fwd: The problems with Xlink for integration langu ages]

[ Lists Home | Date Index | Thread Index ]

> There is another important structural problem with HLink.  It is adopting
> the same conceptual disaster as <OBJECT> - overgeneralization in a single
> element type, a false economy.  It leads to omnium gatherum attribute sets
> with all sorts of interdependencies.  (You'd think people would have
> learned from the INPUT element in HTML!)  It's all very fine to say that
> if the effect attribute is embed and the actuate attribute is onLoad then
> the onSuccess attribute means such-and-such, but without an *exhaustive*
> analysis of the various combinations, the spec is deficient in untangling
> a problem of its own making.  This will result in either a reluctance to
> implement because the bogotic combinations lack definition, or an interop
> problem when the bogotic combinations are read as an invitation to um,
> "embrace and extend".

I agree with the point about object.  I saw a lot of praise for the idea of 
collapsing applet and img into object, but I find the idea a bewildering step 
backwards.  I hear talk that this will reduce the number of tags Web authors 
need to remember.  But I agree with you that remembering all the resulting 
constellation of nuances of object will be a much harder task than remembering 
2 different GIs.  And wait until browser nuances are added to that mix.

As I design vocabularies, a significant difference of semantics in most 
processing of two elements requires a different type names for these elements. 
 By this measure, img and applet undoubtedly deserve separate element types.  
The reductio ad absurdum of the collapse into object is:

<tag role="paragraph">...
<tag role="header">...

Probably a bit too saucy an argument, but I certainly can't see the rational 
argument for the new super-OBJECT tag.

However, I'm trying to follow your extension of this criticism to HLink.  It 
is the hlink element itself that you find an over-stuffed concept, right?  Not 
the elements it describes.

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 - 
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS