Re: Extension for Boolean attributes

On Wed, 6 Oct 1999, Alex Blewitt wrote:

> In the section describing Boolean attributes (3.3.4.2 in the 19990824
> recommendation) suggests that:

The entirety of Section 3 should be taken in its indicative spirit.  The
mix of SGML terminology, invented jargon ('parameter entity definition'),
formal-sounding prose and "friendly" discussion can be very misleading if
taken as canonical.  (I suppose it's too late for this round to spiff it
up.) 

> > ... their appearance in the start tag of an element implies that the
> > value of the attribute is "true". Their absence implies a value of
> > "false".

As here.  Basically, there's no such thing as a "boolean attribute" (i.e. 
don't take the *terminology* too seriously), only the ability to "hack" a
combination of SGML syntax features to express a boolean *semantic* if
that's what the application wants/needs.  The syntax features are

(a) The value of an attribute can be restricted to come from an explicitly
enumerated set of name tokens.  An example of this is the ALIGN attribute,
declared like this

   <!ATTLIST ...
     ...
     align  (left|center|right|justify)  #IMPLIED
     ... > 

(b) For attributes of this type, a form of minimization known as "name
omission" can be applied in the markup of the document.  Instead of the
full {name}="{token}" syntax for an attribute specification, the *name*,
the '=', and the quotes around the value can all be left out, leaving just
the name token.  Note that this feature means things like <P center> and
<H1 center> are legal syntax - not that the darling wowsers will recognize
this form though!;) 

Putting these two together, if you define a singleton name token group and
then name the attribute identically, you can get the "boolean" effect of
an isolated token not always appearing in a start-tag.  [Well, that's the
theory.  The real story is that HTML's "booleans", like SELECTED, ISMAP,
and so on, got invented and used first.  A DTD to formalize such usage
came much later, at which point it became necessary to invent names for
the attributes identical to these values that people were using in a
"boolean" manner.  Isn't retro-fitting fun?;)]

> For the next level of HTML (4.1?) why not allow boolean values to be
> specified using a Boolean definition of 'true' and 'false'? This would be
> a useful datatype which could be used in other locations as well.

Unfortunately, there's a problem, having to do with SGML esoterica.
Suppose you had a declaration like this

   <!ATTLIST  something
              foo   (true|false)  #IMPLIED
              bar   (true|false)  #IMPLIED
              >

and then a start-tag in the document like this: <something true false>. Is
foo true and bar false, or vice versa?  Well, the SGML standard outlaws
this ambiguity by requiring that every such name token value that can be
applied to a given element type has to be unique, which means you can't
re-use "true" and "false" in such name token groups. [The WebSGML TC has
relaxed this: now, you can reuse name token values, but you can minimize
only if that value is indeed unique.]

> It also allows the representation of future HTML elements which have a
> default value of 'true' 

I think you mean attributes, not elements.

> (rather than the default 'false' that selected et al have)

That's just a matter of using the appropriate definition, and in fact,
whether the presence of a "boolean" attribute in a start-tag should mean
"true" is a *semantic* design decision, usually expressed through an
appropriate name... 

> <anElement>                 <!-- implicitly visible="true" -->
> <anElement visible="false"> <!-- explicitly visible="false">

...as in, how about <anElement notvisible>, corresponding to

    <!ATTLIST anElement
              notvisible  (notvisible)   #IMPLIED
              >

> It would be easier to parse/recognise 'boolean' attributes using this
> mechanism than the selected="selected" that is current, 

I doubt this; rather, I think the only extra twist to the parser is in
recognizing *any* minimized form.  You just have to organize the semantic
treatment properly in the application logic.  (i.e. you don't really have
to fixate on 'visible" as the *name* of your property: it could just as
easily be "notvisible" instead.  Alternately, you can arrange for a logic 
flip in the parser/application interface.)

> and it allows the presence of some default-true values (such as visible)
> to be represented. 

As I hope I've demonstrated, that's not a problem.  There is a problem in
reusing "true" and "false" in name token groups; that will need changes to
the SGML declaration to fix.  (And if they're going to do that, there's a
whole raft of changes that ought to be made, IMHO.)


Arjun

Received on Friday, 8 October 1999 02:32:38 UTC