W3C home > Mailing lists > Public > www-html-editor@w3.org > July to September 2002

HLink Draft: Magic Attribute Values Considered Harmful

From: Arjun Ray <aray@nyct.net>
Date: Sat, 14 Sep 2002 23:25:51 +0000
To: www-html@w3.org
Cc: www-html-editor@w3.org
Message-ID: <mmg7ouoaoapbda4ogplrnesf3n4kghek7h@4ax.com>


I have posted a comment on the HLink draft to the www-html-editor list:

http://lists.w3.org/Archives/Public/www-html-editor/2002JulSep/0120.html

In it, I question the wisdom of using magic syntax in an attribute value
to force a reinterpretation as a value reference.  It requires that a
magic syntax (the '@' prefix on a name) be recognizable in all the value
domains of the various attributes.

For one thing, AFAIK, the string '@foo' is a perfectly valid relative URI
reference.  (Have I got the new revision of official terminology right?  I
mean what we used to call 'relative URL'.)  So, locator="@href" meaning
something different is introducing a constraint on allowable values, which
in general is a bad idea.

I contend that such bi-modality of attribute values on the basis of a
magic marker of some sort *in the data* is ill-conceived, should be
revised, and indeed can be revised quite easily.  All this needs is HLink
having an attribute dedicated to the purpose of recording the mapping of
names.

I've proposed one scheme, the outline of which is already in the cited
message, so I won't go over it again here.  It suffices to say that the
proposed extra attribute would carry a list of names interpreted in pairs,
matching names of attributes in HLink to attributes in instantiated link
types.

There is another scheme possible, which people who want to retain the
bimodality may prefer.  (One argument is that they can see the relevant
association "directly" - this may even have been the cause of a search for
magic syntax.)  This would be to use an attribute recording which of the
others are in fact not literal but value references.  The magic marker '@'
can also be dispensed with - it becomes unnecessary syntactic clutter that
the application would have to unmunge.

Let's call this attribute 'valueref'.  Its value will be a list of the
names of attributes for which the 'value reference' override apply.  The
examples in 2.3 could now look like this:

1.  The definition of the <a href="..."> element in XHTML: 
       
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="a"
       locator="href"
       effect="replace"
       actuate="onRequest"
       replacement="target"
       valueref="locator replacement"/>
       
2. Defining <img/> in XHTML 
  
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="src"
       effect="embed"
       actuate="onLoad"
       onFailure="warn"
       valueref="locator"/>
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="longdesc"
       effect="new"
       actuate="onRequestSecondary"
       valueref="locator"/>
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="img"
       locator="usemap"
       effect="map"
       actuate="onLoad"
       valueref="locator"/>

3.  Defining <object> in XHTML 
  
<hlink namespace="http://www.w3.org/1999/xhtml"
       element="object"
       locator="data"
       effect="embed"
       actuate="onLoad"
       onFailure="processChildren"
       onSuccess="ignoreChildren"
       valueref="locator"/>
            
5.  Defining redirection: 
  
<hlink namespace="http://www.example.com/markup"
       element="redirect"
       locator="href"
       effect="replace"
       actuate="onLoad"
       valueref="locator"/>

So, now there are two counterproposals that require no magic syntax.

Hmm, did I say I don't like magic syntax?
   
Received on Saturday, 14 September 2002 19:28:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:17:42 GMT