Re: XHTML 2.0: Suggestion for <addr/> and <blockaddr/> to replace <address/>

On Fri, 5 Dec 2003, Ernest Cline wrote:

> As I've said before, I think what is really needed is a URI for postal
> addresses.

Maybe, but that's something orthogonal to the question of address markup.

The syntax and use of URLs (well, URIs, to use the more confusing TLA)
is not well suited for presenting longish information. But it could be
done, using "/" as a separator corresponding to newline, etc. The question
arises whether postal addresses actually indicate _network addressable_

But in any case, that's a different issue.

> Assuming they go forward and develop a postal URI, then the
> fact that an element refers to an email address, a telephone
> number, or a postal address could be inferred from the
> presence of a URI of the appropriate protocol in the href
> attribute with no need for an XHTML element to indicate
> a single point of contact.  Thus an inline address element
> would be totally unneeded.

I can't see it that way. URLs are just addresses, and they are meant to be
used in references like href attributes, not as something visible (though
we often need, or think we need, to write them down and type them).
Do you mean that an HTML document should contain, perhaps in an <address>
element, postal and other URLs, instead of actual postal addresses,
E-mail addresses, and so on? Presumably so that they would be
_rendered_ as readable addresses, not as URLs. That would mean that you
effectively delegate to URL syntax the job of working as markup.

Even if we postulate, somewhat utopistically at present, that a
postal URL could be a real, working URL (so that I could click on a link
with a postal URL and thereby initiate sending something via postal
delivery), this is something to be kept separate from actual postal
addresses and their markup. Just as we keep http URLs as tools for
creating hypertext links, not as markup for links.

Jukka "Yucca" Korpela,

Received on Saturday, 6 December 2003 06:10:28 UTC