[whatwg] Should <address> be more general-purpose?

Benjamin Hawkes-Lewis and Simon Pieters are having a discussion that I 
understand (at last... at least, sort of, or at least ... I think I do) . 
The discussion concerns the meaning of the word "address" and the tag 
<address>. How much of the meaning of the word should reflect (for good or 
for ill) in the <tag>.

I gather there may be ... for want of a better word ... "context" here: 
things like what the proposed use of <address> was and historical arguments 
and worst case scenarios and cost benefit analyses and best practices and 
schema, rubrics and editorial policy. Accordingly, via any of said 
contextual precedents, my remarks may be summarily (and, I hope, smugly) 
ignored.

address as in:
       (1) : my address is 914 Chamomile Row, Herbtown, General Nostalgia 
3.14159
       (2) : http://www.nobodyhere.com/justme/me.here
       (3): 192.168.1.1
       (4): Dept. of Departmental Subdivisions, Universe of Indivisibles, 
Academia

lucubration -- case #
    (1)  is sort of like a unique locator within some physical space
        -- often used to contact a person or corporation; sometimes used to 
verify an identity
    (2) is a URL/URI. is a unique identifier within the Internet
        --  generally used to retrieve information, usage cases can become 
complex
    (3) is sort of like (2) except for oddities.
    (4) -- used to verify identity (for purposes of certainty in 
attribution), or to contact a person.

Example (2) is handled in various ways in HTML -- usually, I think, as the 
value of an attribute (or object property):
        : href=url
        : src=url
        : location=url
    *  : value=url -- (the "value" attribute is just a string and has no 
interpretive semantics)
We may imagine, with little difficulty, a schema (perpetrating a minimum of 
linguistic injustice) that handles these cases.

The others: (1) (3) and (4), on first glance, would seem to require some 
sort of semantic tag living outside HTML but rather in some OWL-like space.
But then, what does "address" really mean in this modern era?

The term "address" probably has taken on a host of specialized meanings 
(within the technological realm) that are slightly different than the above 
uses -- some technology induced; others not.

To what extent can those who define "standards" allow themselves to be 
influenced by "meanings" that humans bring with them? Should the humans 
learn to abide by the standards, or should the standards adapt to extant 
human usage (all bolluxed as it seems to be) ?

Let's look at one of the simplest uses of "address": use case (1)
        a unique locator within some physical space --  (1) : my address is 
914 Chamomile Row, Herbtown, General Nostalgia 3.14159

Lots of relativity surrounds the way we provide unique locators in physical 
space. Google Maps give us two obvious, but correlated, ways: street address 
and (x.y) pairs of the form (latitude, longitude). Both rely on technology.

Street addresses only exist in places for which postal authorities have 
already consented on a system of unique identifiers. Latitude longitude 
pairs work well for areas that have been mapped (or have good cell phone 
reception). Lots of places on earth remain indeterminate: Mines, jungles, 
and the places where aircraft and submarines go. UPS probably does not 
deliver in the Mariana Trench.

So suppose we step away from the technology for a moment and ask, what do we 
mean by an address?
        : what is your address?   ==  translate ==    : how may I contact 
you?
        : what is your address?   ==  translate ==    : how may I trust you?

How does that differ from
        : what is Marilyn's address?  ==  translate ==   : how may I contact 
her?
        : what is Marilyn's address?  ==  translate ==   : how may I trust 
her?

In the second case "how may I trust her" coming from a third party is quite 
different than "how may I trust you" coming from the second person.

What humans (including those who invent internets)  mean by "address" can be 
pretty complicated. If we, who invent internets, were to pretend that we 
know better what an "address" is than those who for several centuries have 
used, defined, and inhabited "addresses" then we will have made a new 
language that humans will not only refuse to learn, but which they will be 
compelled, by sheer moral indignation, to refuse to learn.

In experimental psychology in the US in the 1950's behaviorism was rampant. 
Folks were fond of making "operational definitions".  The classic example 
was B.F. Skinner defining "thinking" as its behavioral correlate: movements 
of the vocal chords (which often accompanied people's unvocalized rehearsal 
of thoughts they might later speak). The movements were measurable; the 
thoughts were not.

Some reviled the attempt to reduce "thought" to the "thought-related 
behavior" which happened, at time t, to be measurable by technology 
Tech(t) -- If, for two times t and s, if t>s, then the "modern" sense of 
progress would imply that Tech(t) is "better than" Tech(s). The 
epistemological conundrums were rather fun for the philosophers of the 
1960's, who made good sport of it in their journals. Nevertheless, the 
psychologists still got more money from NSF. The AI researchers got to laugh 
loudest, but they still have to pay for their music downloads.

 dpd
> Simon Pieters wrote:
>
>> Do UAs need to know the scope of the <address>? What could they do
>> with this information? (If it is important, then we could use a class 
>> name
>> or a new attribute for this IMHO.)
>
> Using <address> in this way has been difficult since it's hard for
> agents to infer document structure from current tag soup (I'm currently
> grappling with the mess in my Hypertextuality extension where I'm trying
> to find the relevant permalink for articles and posts). With it's
> heading parsing rules and <article> element, (X)HTML5 should at least
> make this easier for documents explicitly authored to its specification.
>
> That there should be a way of expressing the scope of contact
> information is more important than the more technical question of
> whether it's in an attribute or element or registered class name.
> Obviously specifying an element or attribute is preferable, as then UAs
> would be substantially more likely to do something with it.
>
>> <address> has been around forever. Yet no UA has done anything useful 
>> with
>> its semantics as far as I know. That suggests to me that the use-case is
>> not a real-world one.
>
> I tend to think the relationship between "real-world" utility and HTML
> elements is mostly the other way round. Elements become widely useful
> because user agents happen to make use of them (or, more often, invent
> them in the first place, q.v. canvas); agent developers don't
> necessarily recognize the utility of new elements in external
> specifications, however. In fact, individual developers are often
> entirely unaware of their very existence.
>
>> Isn't it better to make <address> more general so that its semantics
>> is more like how most authors use it so that it becomes a convenient
>> styling hook for authors?
>
> [snip]
>
>> I don't think it's a good idea to invent a new element when the use-case
>> is so weak that most authors don't bother using it and no UA have
>> implemented anything useful with it. I'd rather drop <address> 
>> altogether.
>
> I don't follow. You seem to be asserting both that "most authors" misuse
> <address> to mean any contact info /and/ that "most authors" have no use
> for an element like <contactinfo> that is actually for "any contact
> info".
>
> With regards to the practical utility of <address>, I think this is
> bound up with the whole matter of the web's highly immature techniques
> and technologies of citation. The age of print took a while to sought
> out it's techniques and technologies too. The fact that it took such
> time does not mean that there was no use-case for citation.
>
> An <author> element might kill several of these birds with one stone.
>
> --
> Benjamin Hawkes-Lewis
>
>
>

Received on Tuesday, 27 February 2007 19:42:58 UTC