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

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

It defines the single "snail mail" address for me and the intent
of the <dl> in my example was to define the ways in which I could
be contacted.  In any case, the use of <dl> despite its name
of "definition list" has been associated in HTML with any list
containing binary relationships between a term and text
associated with that term, not just definitions.

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

If one can't assume in this case, then the whole idea of a semantic web
had best be dropped.  There is absolutely nothing that will prevent
authors from, for example, continuing to use <blockquote>
when what they have isn't a quote but they want the indenting effect
commonly given to it.  When it comes to web specs, then to misquote
"Field of Dreams":
  If you specify it, they will misuse it.

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

Granted, authors could do things that aren't intended by the spec,
but is that any different from:

<blockaddr>
I can be reached by e-mail
<addr href="mailto:here@example.com">here</addr>.
</blockaddr>

At least with a URI there is something that a user agent can
unambiguously know is an address, and because
of its structured format, can possibly take some action with.

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

"Are well-written, as they should?"  Sorry, but to expect that people
will do as they should is the biggest mistake we could possibly make.
Even now the <a> element can be abused in a way so as to make things
difficult for the situation, you describe, altho I grant that the expansion
of linking to every block level element does threaten to make the
situation worse, but not by much.  To begin with, in well-written
documents, large chunks aren't going to all be combined into a single
link.  And even in poorly-written documents, how often is an author
going to want to do that anyway? All those blue underlines just won't
look good to most people.

Received on Sunday, 7 December 2003 10:27:34 UTC