- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Sat, 6 Dec 2003 13:07:30 +0200 (EET)
- To: www-html@w3.org
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_ resources. 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, http://www.cs.tut.fi/~jkorpela/
Received on Saturday, 6 December 2003 06:10:28 UTC