On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:
On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
All a media type tells you (non-authoritatively too) is the spec you
need to interpret the document at the other end of the link. That has
very little to do with the reasons that you might want to follow the
link, subscribe to it, etc.. Which is why you need a mechanism
independent from the media type. Like link types.
Now that this has sunk in, it makes a lot of sense--the @rel value
says "you can subscribe to that", "that is an alternative
representation of this", "that is where you'd go to edit this", and
so on. The media type helps the user agent figure out whether it has
the capability to do those things. For example, a feed reader that
only handles RSS could ignore subscription links to resources of type
"application/atom+xml" (ie. not present the subscription option to
the user). The "subscribe to hAtom feed" case where @type is "text/
html" might be a little difficult to make a decision on, because
there's no indication of what microformat is being used by the
"feed" (or even if there's a microformat in use at all--maybe it
really is just an HTML page, and "subscribing" to it just means
"watch for changes to the entire document"). But in the case of bare
syndication formats, things should be clear enough.
So if it really is possible to do option 5 (new media type for entry
documents, and @rel values to solve the rest of the issues), and do
it cleanly, then that'd be my first choice. If that's doomed (due to
a need to be backwards compatible with existing practice) to be a
mess of ambiguities and counter-intuitivities (eg. "alternate" means
"subscribe" when combined with a syndication type, except when it
might really mean "alternate" because it points to a feed archive
document, but anything with "feed" in it always means "subscribe"...)
then oh my.
One problem that I hadn't really thought clearly about till right now
is that understanding the nature of the think linked TO may require
some understanding of the nature of the thing linked FROM. For
example, an "alternate" link from a typical blog homepage to its feed
really does point to the same thing in an alternative format. Both
are live documents in which new data gets added to the top, and old
data drops off the bottom. But if you don't know that the webpage is
a live document, you wouldn't know whether the link pointed to a
static or live document. "alternate" is perfectly accurate, but it's
not helpful enough. "subscribe" would be much more explicit.
Which raises the question of how to point to a static alternative
representation of the data currently found in the document.
"alternate" WOULD be a good word to use for that except that it's
already being used to point to live feeds. An option that would
almost surely cause confusion would be to use "alternative" for
static alternative representations. The meaning of "static" wouldn't
exactly be intuitively clear. Maybe something more long-winded like
(oh no! hyphenation!) "static-alternate" would do. Or would "static
alternate" (and "alternate static" and "static foo alternate",etc.,
or perhaps "archive alternate", etc.) be better? For backwards
compatibility (at least with UAs that don't expect only one value in
@rel), "subscribe alternate" (and "alternate subscribe", etc.) could
be used rather than simply "subscribe".
BTW, am I remembering correctly that "feed" is being promoted for use
the way I'm considering "subscribe" above? If it's not already in
use, I'd thinK "subscribe" would be much better than "feed", because
"feed" could as easily mean "archive feed" as "subscription feed"--
it's just not explicit enough.
But perhaps this discussion all belongs in a different venue anyway...
But before I end, what about the question of a different media type
for entry documents? For the APP accept element issue, it sounds
like maybe they do. But for autodiscovery, maybe they don't.
Perhaps neither @type nor @rel is the place to distinguish, for
example, between the edit links for entries, their parent feeds,
their per-entry comment feeds, monolithic comment feeds, etc. (A
media type for entry documents would only help with one of those).
Perhaps that is the domain of @title (title="Edit this entry", etc.)
Do UAs really need to know the difference, or do only the users need
to know? Would making that information machine readable be worth the
pain involved (rel="edit monolithic parent comments"???)
Okay, that's all I can take for now.
