Re: List elements (was: Tree Presented Lists )

On Sun, 22 Jul 2001, William F. Hammond wrote:
> On Fri, 20 Jul 2001 10:40:22 -0700
> Tantek Celik <tantek@cs.stanford.edu> wrote:
> > Daniel Hiester, at 22:19 on Thu, 19 Jul 2001, wrote:

>>> Why is it that we don't simply have an element that means 'list.'
>>> Why was it so important to have the markup parser distinguish the
>>> difference between an ordered and unordered list?

The parser doesn't care except for any validation constraints that
might apply.  The distinction is relevant to the "application", and
exists mainly as an historical artifact.  Even so, the only thing
missing is an extra attribute (to mark the fact of a 'list').

>> [...] I wonder, instead of <ol>, <ul>, <dl> tags, why wasn't there 
>> simply one <list> tag with a type attribute, e.g.
>>
>>  <ol> = <list type='ordered'>
>>  <ul> = <list type='unordered'>
>>  <dl> = <list type='definition'>
>>  <dir> = <list type='directory'>
>>  <menu> = <list type='menu'>
> 
> Using a "type" attribute to distinguish between different kinds of
> lists is more sophisticated than giving each different type of
> list a name.

Actually, it isn't.  Mainly, it's the same thing, and where it isn't,
it isn't as good.  Whether the *name* of the attribute is an explicit
'type' or an implicit 'generic identifier' is six of one and half a
dozen of the other.  (That is, an element type name is morphologically
equivalent to the *value* of an attribute, albeit a distinguished and
thus unnamed one.)  However, unless a 'type' attribute is restricted
to a name token group, SGML offers no other means to *validate* the
value as part of the parsing process.  

> For example, "type" is used this way in the well-known TEI
> document type, http://www.tei-c.org/ .

Note that except for a few cases where name token groups are used,
most of these 'type' attributes are of the 'CDATA #IMPLIED' variety.
When the value of the attribute can be arbitrary (for all practical
purposes), the semantic benefit to an application is by no means
clear.  Exactly how is an application supposed to take advantage of an
unpredictable value?  (Assuming of course, that software works best
when it's designed.)

But there's even more to it.  Object orientation analogies are fraught
with danger here, but a taxonomic similarity is quite fruitful.  In OO
systems, superclasses typically do not have knowledge of - or carry
references to - subclasses; rather, the referential relationship is
usually the other way, with subclass "pointing" to its superclass.  

A 'type' attribute for differentiation is basically 'subclassing' in
this sense, <list subclass='ordered'> vs <list subclass='definition'>
etc., and hence the wrong way to organize the information.  It should
be <ordered superclass='list'> vs <definition superclass='list'> etc.

There is a further benefit to having the 'subclass' as the GI: the
ability to have subclass specific attributes (because attribute sets
are grouped by GI).  Using a type attribute is often not enough: there
may be ancillary information needing more attributes, creating not
only an interdependency - where the values of some attributes become
contingent on the value(s) of others - but also the possibility of
incompatibilities, leading ultimately to excessively "loose" DTD rules
for lack of organizational specificity.  This is a known problem with
HTML's INPUT element type, for instance.

http://groups.google.com/groups?as_umsgid=1dd3itkfikmp6j7os8l2n1h5a3c9qhcc46@4ax.com 

>> Perhaps <ol>, <ul>, <dl> were preferred due to brevity? [...]
> 
> My sense of this is that early HTML may have been influenced in this
> regard by Leslie Lamport's LaTeX, [...]

I believe these cryptic initialisms were borrowed from some DTDs
already in use at CERN in the late 80s - early 90s.  There is also the
"Application Example DTD" in Annex E of ISO 8879 (reproduced in the
SGML Handbook) in which practically all of the historically "old"
element types of HTML can be found.


Arjun

Received on Monday, 23 July 2001 18:13:05 UTC