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

> [Original Message]
> From: Jukka K. Korpela <jkorpela@cs.tut.fi>
>
> 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.

That is why I used the URI TLA and not the URL TLA  because URI's
are not necessarily network addressable while the subset of URI's
called URL's are 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.

No what I mean is that we would have something like the following,
(to repeat an example I gave earlier):

<dl>
<dt>Snail Mail</dt>
<dd
href="postal://us/29006-1300/Batesburg,SC/351%20Marion%20St./Ernest%20Cline"
>
<l>Ernest Cline</l>
<l>351 Marion St.</l>
<l>Batesburg, SC 29006-1300</l>
</dd>
<dt>E-mail</dt>
<dd href="mailto:ernestcline@mindspring.com">
ernestcline@mindspring.com
</dd>
<dt>Phone</dt>
<dd href="tel:+18035325230">(803)532-5230</dd>
</dl>

From the URI protocols used it is clear that each of the
three <dd>'s contain some form of address info.
The URI is in a machine parsable format while the
content of the element contains what is intended to be
a human readable format of the author's choice.
From the point of view of semantic processing,
the URI can even be seen as a superior method
as it is easier for the machine to categorize the address
info the URI contains than to try and parse the contents of
an <addr> element.

The choice of <dl> was made by the author, altho any other
form of containing structure could have been used, including
possibly a block level address element.

> 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.

Agreed it is somewhat utopic, but once a postal URI existed,
it wouldn't be too difficult for a word processor in some OS's
to tell the OS that it can handle a postal URI, and then when it
received it to call up a letter and/or envelope template
with the machine parsable address data already used to
put the address info in the appropriate places.  It can't be done
now because there is no postal URI and thus no standard way
for a program to tell another I want to send a piece of postal
mail here.

Actually with the proposed expansion of href from <a> to
just about any element in XHTML2, I think it is safe to say
that there is no longer any markup element for links.
Links are indicated by the presence of the href and id
attributes, not by the <a> element which formerly had sole
possession of both functions. The only reason I see for keeping
<a> in XHTML2 is sentiment, not any real need.  If URI's exist for
all types of contact info, then there is no need for an inline
address element either, altho perhaps a block level element
should be retained to indicate a group of related bits of such
info.

Received on Saturday, 6 December 2003 09:04:02 UTC