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

On Sat, 6 Dec 2003, Ernest Cline wrote:

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

The practical difference is that that URLs are real whereas "URI" is a
theoretical generalization. But I had understood the difference so that
URI = URL + URN, the difference being that L = locator, N = name,
so that a URN is supposed to name a thing, instead of specifying how to
locate it. This does not imply a distinction between network addressable
and non-addressable, just between (relative) explicit addressing and
naming. If the URI concept is to be extended to cover everything that is
in some way addressable and nameable, well, that's an interesting idea,
but what about seeing some actual use of URNs on the Web first?

My point is that postal addresses, for example, should not be wiped away
from HTML markup just because it is possible, or imaginable, to define a
URI scheme for them.

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

Does that really define the meaning of the term "Snail Mail"? Maybe, in
some way, in a universe where a single Snail Mail address exists.

Regarding the href, that's an interesting idea, but that's really external
to HTML, and I have yet to figure out what the possible uses could be.
After all, clients should not assume anything about it - any relationship
to the semantics of the HTML document, such as specifying someone's Snail
Mail address. And the content is just a sequence of lines.

> From the URI protocols used it is clear that each of the
> three <dd>'s contain some form of address info.

Maybe, but that's external to HTML, and we cannot know which address info
except, perhaps, via human reasoning and guessing. What's the use of
knowing that some sequence of lines of characters is a postal address?
The client could display it as a set of lines, as it would anyway
when the <l> markup is used, and perhaps formatted as a bordered block or
something, and although the author probably wants to use some special
formatting of his own, it's useful to have some default formatting for
addresses. But the client _cannot_ know that the content of <dd> is a
postal address! It can only know, and only by knowing the meaning of the
currently hypothetical postal: URL, that the element is a _reference_ to a
postal addess.

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

And that would become a _big_ problem.

Consider, for example, user agents that communicate with the user via
speech synthesis and keyboard input only. At present, if the link texts
(contents of <a href="...">...</a> elements) are well-written, as they
should, the user can use a "links reading mode" to get an idea of what
links there are, or to proceed from one link to another by tabbing, or to
request for an alphabetic list of all links, then relatively quickly find
the link he's interested in. Much of this works on modern visual browsers
as well.

Now, if there are no link elements, on the grounds that any element can
be a link, the situation suddenly becomes perplexed. There's no convenient
way of listing the link texts when a "link" can be an arbitrary element,
perhaps covering half of the document.

Traditionally, links are indicated as links by the use of "link colors",
varying by the state of the link, and by underlining or, for images that
are links, by a colored border. Moreover, the shape of the pointer
(often misleadingly called "cursor") may change as the pointer
moves over the element or away from it. Authors  often see much of this as
a problem rather than a solution, but as we think of the proposed
"everything can be a link" idea, it should become evident how problematic
the link concept is if links lack concise but informative link texts that
can be used to identify the links and that can be indicated as links
visually (or aurally, e.g. by switching the tone of voice, or somewhat
naively by uttering "link" before the text).

The link concept needs a clarification and simplification, not a
theoretical generalization. Since XHTML 2.0 is to be incompatible with any
predecessors, it might just as well adopt the _natural_ name for a link
element and a natural attribute name:
<link ref="...">...</link>
with inline contents only.

If it some day becomes feasible to use links that refer to postal
addresses, this could be handled fine with such link constructs.
You would write
<link ref="postal:...">My postal address</link>:
followed by a presentation of the address, maybe using an <address>
element, maybe not.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Sunday, 7 December 2003 06:26:54 UTC