Re: Classes Considered Harmful

> Classes are sometimes harmful.  Not always.  Let's try not
> to make too sweeping of generalities here; as an example,
> it would be very hard to use CSS with XHTML if the general
> belief is that "classes are harmful." [...]

Yes, and perhaps I should have been more clear. My point was that
@class as implemented makes it incredibly easy for one to violate XML
GL 2.7, i.e. "don't overload element semantics". If the content is an
NMTOKEN, they also have the added disadvantage that they don't have
global referrability. When you add that decentralization, possibly in
the form of a QName, you can easily see why @class is a hack.

But because it's a hack, it provides a good interim solution to
languages such as XHTML 1.0, which don't have extension mechansisms,
per se. But I know that. And you know that I know that. What I'm
asking for is not some religious classes are evil, stay away from
classes" thing as a law for all developers to follow, but simply a
guideline that asks people to be careful in choosing extensibility
mechanisms, that they make them as accessible as possible, allowing
people to properly define the semantics of the extensions that they're
creating. NMTOKENs in classes DO NOT let you do that, unless you use
some convoluted XPath expression, which no one in their right mind is
going to design for. QNames help, but then they underline the
overloading of semantics problem.

So I think that @class can and *should* be considered "harmful", but I
accept your caveat that they provide an interim solution.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Sunday, 8 July 2001 10:29:09 UTC