Permalinks
<link> (deprecated)
-
Definition: One of possibly several persistent URI locations for the entry on the Web in the context and style of the publisher's website.
Comment: Links may change over time.
Example: <link>http://bob.blog/28</link>
<link> (new version)
Expresses a relationship between an Atom entity and another resource.
Structure
<!ELEMENT link EMPTY> <!ATTLIST link rel (#PCDATA) #REQUIRED href (#PCDATA) #REQUIRED type (#PCDATA) title CDATA>
(eg <link rel="alternate" href="http://www.example.org/blog/entry1" [type="text/html"] [title="This entry's webpage"']>)
Summary
-
rel - relationship
-
href - other resource
-
type - MIME type of retrievable resource
-
title - display title of resource
Description
The LinkElement is used to express a relationship between a resource identified in an Atom feed and another "external" resource. The Atom resource is normally that associated with the parent of the link element (the link element may also be used to associate a schema name with a namespace, see below). The other resource is identified in the href attribute of the link element. The rel attribute defines the relationship between the two resources.
Relationship Values
The meaning of the rel attribute is determined in one of two ways. For terms defined in the Atom specification, the term may be used directly in the attribute, e.g.
<link rel="inResponseTo" type="application/x.atom+xml" href="http://example.org/post123" />
The core terms are described at LinkTagMeaning For terms defined outside Atom, additional namespace-based qualification must be used.
Explicit Namespace
This method of defining the relationship uses a technique derived from that described in RFC 2731 (Encoding Dublin Core Metadata in HTML) . First an external schema is identified and its namespace identified with a schema name. This only needs to be done once per feed:
<feed>
-
<link rel="schema.FOAF" href="http://xmlns.com/foaf/0.1/" / >
...
Subsequently the schema may be referred to in individual link entries:
<entry>
-
<id>http://example.org/blog/post123</id>
<title>Fear of Vegemite</title> <link rel="FOAF.depiction"
-
type="image/jpeg"
href="http://rdfweb.org/people/danbri/2001/09/cam/danbri-vegemite.1000843912.jpg#" title="danbri with yeast extract" />
...
(The # suffixed to the image.jpg url prevents this wiki from automagically displaying the image inline)
Implicit Namespace (Atom Core)
Much of the time the relationship schema used will be that defined in the Atom specification. To simplify the use of this a shorthand can be used. If there is no schema explicitly associated with the content of a rel attribute (using the method described above) then the value of the rel attribute is taken to refer to a term in the Atom namespace.
So this:
<feed> ...
<entry>
-
<id>http://example.org/post124</id>
<link rel="inResponseTo"
-
type="application/x.atom+xml"
href="http://example.org/post123" />
...
is equivalent to, and will be used in preference to:
<feed>
-
<link rel="schema.Atom" href="http://purl.org/atom/" / >
...
<entry>
-
<id>http://example.org/post124</id>
<link rel="Atom.inResponseTo"
-
type="application/x.atom+xml"
href="http://example.org/post123" />
The core terms are described at LinkTagMeaning
<id>
-
Definition: Uniquely identifies this resource.
Comment: <id> can be used to identify the same resource in multiple locations or as the resource changes over time.
Example: <id>tag:bob.blog,2003:28</id>
permalinks or unique identifiers?
Permalinks: When you see a weblog entry, you often want to reference it or respond to it. To do this, you need its permalink. Since we're expecting all weblog entries to be on the Web, a permalink isn't a very onerous requirement. And the permalink is free to refer to a page that's gone 404, not on the public Internet, or on your local machine. The downside is that some innovative feeds (like stock tickers) would have some trouble generating permalinks. If we require one, they'll just make something up, and that can cause problems. And what happens when you have multiple formats (say, HTML, MP3, and Flash)? Which one do you give out as the permalink?
Unique identifiers: A unique identifier lets you figure out when two items are the same, which is quite useful. Database-backed weblog tools like Blogger and Movable Type use numbers (like 2345), not permalinks, to identify posts. They can put those numbers in the unique identifier slot, and get them back in later operations (like when the client wants say what entry it's editing. Plus it allows the permalink to move and change without breaking things, since the unique identifier can stay the same. The unique identifier should be a UniversalResourceIdentifier (URI), so that it has a consistent syntax and is should be globally unique (that way you can see if two items in different feeds are really the same).
For example, imagine you're subscribed to News.tld's tech and politics feeds. They publish a story that runs in both (it's about how the government is moving to OpenBSD). In one feed, the permalink is http://news.tld/tech/1420 and in the other it's http://news.tld/politics/1420 but they both have the same unique identifier.
TimBray is nailing down exactly what a unique identifier is in PostIdSpec.
See EntryIdentifier for an approach that gives a concrete definition of an Echo identifier, that can also support additional attributes for 'publisher-id' (post-id), 'also-at' for categories, and 'mirror' for other locations.
Poll
This is a new poll. If you voted in the old poll please vote here for the new, clarified options. Please, votes only, discusion should continue below. Please do not edit or move other people's votes.
[OpenPoll]
-
Moe (single URI element, always a permanent URL, always a unique identifier)
-
KenMacLeod (extension uris ok)
-
Larry and Curly (unique URI identifier element required, permanent URL element optional)
-
Shemp (single URI element, always a unique identifier, usually also a permanent URL)
-
Abbot and Costello (permanent URL element required, unique URI identifier element optional)
-
Peas and Carrots (permanent URL element required, unique URI identifier element required)
-
SamRuby, MishaDynin, JoeGregorio, MarkPilgrim, Manuzhai, MarkCidade, DiegoDoval, RahulDave, TomasJogin, GeorgBauer, JeremyGray
-
Can we redefine the Carrot (permanent URL) element as a (potentially non-http:) URI? I'd like to make sure that resolution of a resource to something other than a location is possible (ex. FreeNet URIs). [MichaelBernstein]
-
[KenCoar, RefactorOk] So-called 'permalinks' are going to change; that's just a fact of life. Is there some reason the concern about permanent homeliness can't be addressed with a new additional <relocatedto> element or the like? Are we talking about examining a live entry (in which case such an element might be useful), or entries long stored and therefore not necessarily up to date with the current situation? I think some means of providing permalink redirection might be good, like the 3xx HTTP status codes.
-
[SeanConner, RefactorOk] Why not put a base URL for the feed in the channel defintion (or whatever it will be called) and allow the use of relative URLs based of that? If a site moves, then the base URL changes and we avoid having to define Yet Another Tag to indicate that. It would mean that an aggregator will have to store the base URL of the feed, but I suspect that's going to happen anyway. That would also allow the use of relative URLs in the entry body (if included, and solve that particular problem once and for all).
-
Vacuum (no identifier or location is required)
-
[DeveloperDude] I do not like my chances, but why are these required? I like GUIDs, but then I am a programmer. The mundane guy is not gonna like this.
Discussion
[TimBray] I'm trying to focus the post-id debate, will have something [PostIdSpec here] soon.
[KenMacLeod] I hit upon the same idea around the same time too, see EntryIdentifier.
[MichaelBernstein, RefactorOk] Summarizing the discussion, I'd like to propose that entries have a guid required attribute in the form of a URI, that the permalink attribute be dropped, and that if the guid is in the form of a URL, that it be considered a permalink (thus making permalinks optional).
[JoeMadia, RefactorOk] In an attempt to quantify the choices (with data element names changed to protect the innocent):
A) A single required data element called Moe (of type URI) would be defined that acts as both a unique identifier for the item AND as a permalink for the item. This effectively means that Moe must be either http: or https: for the forseeable future and that all items would be assumed to have permanently hosted web pages that contain their content.
-
[JoeMadia] Fits well with most (if not all) usage scenarios today but the "permanently hosted web page" requirement is definitely a limitation on data-driven and ad-hoc feeds. If these types of feeds wanted to play with existing tools then they would be forced to start faking the Moe value. Fake Moe values wouldn't jive well with tools or people that attempt to use them. That's a lot of potential timeouts and/or broken links that we're setting ourselves up for.
-
[GregReinacker] I think you put your finger on the limitations here, pretty unfortunate.
-
[JoeGregorio] I disagree with statement, "This effectively means that Moe must be either http: or https:". A URI does not have to be a URL. I could just as easily use a urn: in the permalink. Now that I think about it, A and D are pretty much equivalent, with the condition that A just restricts the syntax a little bit more that D does.
-
[JoeMadia] The requirement in case A is that Moe is a unique indentifier AND a permalink. I don't believe that urn: could be used in a permalink value since you can't safely retrieve it or link to it. The semantics of permalinks (at least as defined in RSS 2.0) imply that it must be a value that can be plugged into a browser and expected to work... which is where the http and https comment came from.
-
[JoeGregorio] Whoops, my bad, I mis-took the 'and' for an 'or'.
-
[KenMacLeod] I think every Entry should potentially be individually resolvable. "Potentially" means a linked/referenced Entry might not be published to the web (yet), might refer to an Entry on someone's desktop never to be published, or is 404. In contrast to what I see the other options are, where a thing might be contained in some other Entry, and thus individually "invisible" to the web at large but in need of a "unique identifier". Background that might help seeing what I mean is in WhatIsAnEntry, where I equate an Entry with a URI resource, which are then composed into blogs or wikis or CMSs or the Web. Related media types within a resource, while very possibly needing a unique identifier of some type, are not (in the way I'm describing) what we're calling Entries.
B ) A required data element called Larry (of type URI) would be defined that uniquely identifies the item but does not resolve in any meaningful way (as in XML namespaces). An optional data element called Curly (of type URI) would act as the permalink for the item. If Curly was missing then tools would assume that there is no permalink for the item. In the near term, Larry and Curly would be identical in almost all cases.
-
[JoeMadia] Probably the most flexible option since Curly can be omitted today when not applicable. In the future, Curly can be replaced or enhanced with other data elements. (Such as Curly-Xml that acts a permalink to the item's XML rep, Curly-WAP, etc.) All this can occur without breaking any existing unique identifier code since Larry remains unchanged. Downsides include 1) the need for tools to support two states for each item (Curly defined and Curly not defined) and 2) the reduancy that would occur from having Larry and Curly set to the same value in almost all current feeds.
-
[GregReinacker] I think my vote would be here, option B.
-
[TimothyAppnel] I am for a hybrid of A and B where a required data element called Moe (of type URI) would be defined that acts as a permalink for the item. An optional data element called Larry (of type URI) could be defined that acts as a unique identifier for the entry. If Larry is not included it is assumed that Moe uniquely identifies the entry since Cool Moes Don't Change.
-
[JoeMadia] I'm in favor of B. Timothy, does D capture your hybrid case?
-
[TimothyAppnel] Yes it does.
-
[ChrisWilper] This is almost exactly what I propose here, except that I think Curly, if provided should be a URL and not a URI. Why? Because the intent is for it to be resolvable. A Curly that is a URN, for instance, has no useful function.
-
[MartinAtkins] This seems to provide the most flexibility and expandability.
-
[PaulJames] This follows the URI conventions we're grown to expect. Larry could be the same URI as Curly (and in weblogs probably would be), I think it is important to have a unique URI for each entry, even if it is just a URN. I also think that having two values, with Larry being abstract and Curly being a resource of some type, makes this scheme the most flexible while still providing the requirement of having a unique identifier.
C) A single required data element called Shemp (of type URI) would be defined that acts as a unique identifier for the item. If it is also a URL then it is also considered a permalink for the item.
-
[MichaelBernstein] This is the option that appeals most to me. That said, there is one inflexibility built into this option: If Shemp is a URL (therefore a permalink), you can't move the entry to a new location without also changing the unique id. Some might call this an advantage, though, as it encourages permanent locations to be permanent.
-
[GregReinacker] Don't like this one too much, because it precludes using a shared permalink for multiple unique items.
-
[JoeGregorio] Greg, can you give a use case/example for "using a shared permalink for multiple unique items"?
-
[JoeMadia] This one seems somewhat interesting. It removes the redundancy but requires tools to do a little more work to determine whether there is a permalink or not. I need to think on this one some more. I would also like to hear more about Greg's concerns.
-
[MichaelBernstein] Joe, depending on the URI schema used, the work tools would have to do would be negligible. An http:// (or https://) URI could simply be assumed to be a permalink. There is also a role, I think, for explicitly non-addressable URI's besides the urn:// schema, for example, I think a guid:// schema would be very useful. Other schemas could be application-context-dependently resolved, such as an isbn:// schema (one application might resolve it to a library holding, another to an Amazon page).
-
[GregReinacker] My "using a shared permalink for multiple unique items" scenario: Let's say I have a feed which shows the most recent entries in the Windows event log. I can build unique ID's for each item, but I can't build a permalink for them since they're not URI-addressable. So I build one page, http://example.org/eventlogstuff, which describes how to go to the actual entry, and I link all of the items to this page. Maybe a weak example :-), but I think it's a valid use case.
-
[JoeGregorio] Greg, you could have a different URL for each event, just use a fragement identifier (#1, #2, etc) in your URL to point to the different events, for example http://example.org/eventlogstuff#ev1 is a different URL from http://example.org/eventlogstuff#ev2.
-
[GregReinacker] Yep, you could do that - I'm just not convinced it should be required. What if I had a RSS feed that has two representations of the same item? Should I be prevented from pointing them both at the same permalink?
-
[TimothyAppnel] Why wouldn't http://example.org/item#pdf and http://example.org/item#html work?
D) An optional data element called Abbott would be defined that, when present, acts as the unique identifier for the item. A required data element called Costello would be defined that acts as a permalink for the item. When Abbott is missing then Costello is also assumed to be BOTH the permalink and the unique identifier.
-
[JoeMadia] The goal of this option would be to provide all the flexibility of B without suffering from the redundancy. (When Abbott and Costello are the same, Abbott can be ommitted.) Unfortunately, it doesn't seem like the flexibility is present in this option. Since Costello is required, all items would have the same "permanently hosted web page" limitation present in A which kills future flexibility. If we're willing to live with this limitation then A seems like a better choice than D.
-
[TimothyAppnel] I cast my vote for D which I believe is most Web-friendly. I disagree with the assessment that this "kills future flexibility." I would say if anything it promotes it because it lets publishers scale to their needs.
-
[JoeMadia] Sorry... I shouldn't have stated it so strongly. Future flexibility is definitely possible with this option since new data elements can be added that refine and extend semantics. I guess my main concern is that this option, like A, requires that ALL items are publicly hosted and resolvable which seems like too strong of a requirement for certain feeds. If permalink is required for all items then it seems inevitable, in my humble opinion, that certain types of feeds (Search feeds, stock ticker feeds, etc.) will begin faking permalinks since they'll have no other way to participate in the aggregation toolspace. Currently, I think that the best solution would be to have each item explicitly indicate whether it is permalinkable or not which seems to be covered in option B and potentially in option C, but not in either A or D.
-
[MichaelBernstein] I thought the discussion had basically converged on requiring a unique identifier attribute, and making a permanent addressable location optional? D seems exactly backwards.
-
[TimothyAppnel] Not at all. One of Sam's base requirements is that this is on the web. Without a permalink referencing the content or its source goes against that. While a unique identifer would be useful I assert a locator is more important and practical. Having something that can do both (a permalink) even better. Tim Bray posted some thoughts on his weblog that I really think nails it.
-
[MichaelBernstein] TimBray basically said that anything with a URI (even one that isn't a URL) is on the web. Given that a URI can serve as both a unique identifier and a locator, I think C (Shemp) captures the relevant use cases better, and in a single element.
-
[TimothyAppnel] I don't get that from reading the entry on his weblog. Of particular interest is where in discussing HTTP and URNs as URIs he says "in the world of weblog entries, I can?t imagine why you?d use an identifier that doesn?t double as a locator, so I don?t think URNs are particularly relevant." Later he says "...I think that in the ideal world, log entries are identified by URI and include a version identifier, which is a character string that can contain anything you want." I wouldn't presume that I know what Tim meant so I guess I am confused because my interpretation it does not seem to coincide with yours. Perhaps he will stop by and clarify.
-
[MichaelBernstein] Perhaps I should clarify my own understanding a bit. The conclusion of Tim Bray's posting, which says that the identifier would usually use the http: scheme, implies that at least some situations (although he finds those hard to imagine) would use a URI that was not a locator. Option C captures this exactly. The Shemp identifier must be a URI, and can be (in fact will usually be) an http: URL. Here's why I think this is important: URIs are generally not very useful unless they can be dereferenced to something, but that something is not necessarily a location. Here's an edge case: FreeNet URIs dereference to a document stored in FreeNet, but the retreival of that document has nothing to do with any particular machine on the internet; the URI enables locationless document retreival. Furthermore, some URIs can be dereferenced in a context or domain specific way. Here's an example: Imagine a set of entries, some of which represent books with an isbn: URI along with a summary description and some other metadata, and some of which are reviews of those books. An application can display the reviews and book information, as well as dereferencing the isbn: in any one of a number of ways, including fetching pricing info from Amazon.com or checking the book's availability at the local library. Granted, the review entries can contain a reference to the isbn: URI without their being a corresponding book entry available, but the whole set of entries is more useful to an application if dereferencing the isbn: URI is optional. Whew. Anyway, that is why I think option C (Shemp) is better.
-
[GregReinacker] This option is looking good to me...if you live with the requirement that all items have a permalink (which is acceptable, given the boundaries of the discussion laid out by Sam), then I think this option covers all the use cases that come to mind.
-
[TimothyAppnel] I think this goes back to the issue of context and whether we are talking about an internal or external model which, if defined, would clarify the issue. To this point I admit that there is reason to leave it open (a URI _may_ be a permalink) for now. I still remain unconvinced. I thought the RSS 2.0 guid tag implementation was horrid and poorly done. I wouldn't want to see that repeated or continued.
-
[MichaelBernstein] What I'm in favor of in Shemp is different from the guid-is-permalink situation. Shemp is a URI unique identifier. If the URI is also a URL (that is, resolvable to a location (generally, but not exclusively, http: or https:)), then Shemp is also a permalink. All permalinks are unique identifiers, not all unique identifiers are permalinks. No switching elements needed or necessary.
E) A required data element called Pea would be defined that acts as the unique identifier for the item. Another required data element called Carrot would be defined that acts as a permalink for the item.
-
[MishaDynin] This option has three advantages. Globally unique identifier (Pea) can be used by aggregators and other systems to track a post even when a permalink (Carrot) breaks -- e.g. when a blog has moved, or the layout of archive pages has changed. The unique identifier is needed for content management systems, because it may be expensive to convert a permalink into a primary key for posts. Last but not the least, the tools that do not require a separate identifier can just set the Pea to the same URI as the Carrot -- as Sam pointed out, "let's not introduce complex precedence rules or require the recipient to guess for the sake of saving a few bytes of bandwidth in the cases when (unique ids and permalinks are the same.)"
-
[ChrisWilper] I worry that _requiring_ the link to the representation excludes the use case for syndication where the publisher doesn't want/have a non-syndicated representation available. For instance, say I set up a feed (as someone has done on their own system, with RSS Bandit) to notify of system events. What does Carrot point to? Sometimes you just don't have a representation of the data other than what's included in the feed.
-
[MichaelBernstein] I don't understand. What is the point of requiring a (supposedly web locatable) Carrot value at all if you're going to fake it with a reference to the local file system? Better to choose the Larry and Curly option (B), and simply make the URL optional.
-
[MishaDynin] Sam Ruby's original post included the words "on the web." We are trying to define a data model for a weblog entry. Therefore, it's not unreasonable to require a permalink.
-
[JoeMadia] Very tempting but I still have the same concern about required permalinks:
-
[KenMacLeod] I don't see that a "permalink" is a guarantee that a resource is retrievable (now). It can be on someone's desktop (local reference), not yet publicly available, or 404 by now.
-
[MishaDynin] Stock ticker permalinks can point to pages with historical stock data. Search permalinks can point to locations of search results. Worst case scenario -- permalinks point to a page describing the feed (there's no uniqueness constraint on permalinks.) In my opinion, forcing feed generators to think about providing something with a permanent location is a feature, not a bug.
-
[MichaelBernstein] Ahh, permalink URLs aren't required to be unique? Ok, this makes more sense now. So called 'fake' permalink values can still be useful, then.
-
[JoeMadia] As far as I can tell, permalinks as defined in RSS 2.0 do require resolvability:
-
[ChrisWilper] I see why it is compelling to want to force people to put a link in there, and I'm usually of the mind that one link is better than none. But, I think forcing a link in cases where it's not readily available makes the semantics fuzzy, which at the very least leads to a fragmented user experience.
-
I guess my main concern is that this option, like A, requires that ALL items are publicly hosted and resolvable which seems like too strong of a requirement for certain feeds. If permalink is required for all items then it seems inevitable, in my humble opinion, that certain types of feeds (Search feeds, stock ticker feeds, etc.) will begin faking permalinks since they'll have no other way to participate in the aggregation toolspace. Currently, I think that the best solution would be to have each item explicitly indicate whether it is permalinkable or not
-
If the guid element has an attribute named "isPermaLink" with a value of true, the reader may assume that it is a permalink to the item, that is, a url that can be opened in a Web browser, that points to the full item...
F) No identifiers mandatory (except of course for the source URI of the feed). Seems to me that a feed without any permalinks at all could have value. Does every verse of a streaming audio song have a URI?
-
btw, has this issue really had enough discussion for it to be vote time? [DannyAyers][RefactorOk]
-
[MichaelBernstein] I think it's mostly a poll, not a binding vote, yet.
Terminology
See Glossary.
- permanent URL element
-
a URL that resolves to the resource
- unique URI identifier
-
an identifier of the resource in the form of a URI
-
Typically a primary URL used to link to the resource. It is not a guarantee.
Blog entry IDs: Permalinks or other URIs?
This is the old poll, after much discussion more than the simple options presented below were represented, so the new poll had been formulated.
What do you think should be used to identify entries?:
-
Permalinks (URL only):
-
J. Snell
-
UniqueIdentifier other than URIs:
-
Any UniqueIdentifier, including URIs:
[AaronSw] Someone changed the name of the thing people voted for but its scrolled off the info page. I've tried to correct it to the best of my memory, but please correct it if you see a mistake.
[MichaelBernstein] Consider removing your own vote from the poll above as you vote in the new one. The old poll can be removed once no more votes are recorded there. Please do not edit or move other people's votes.
External Discussion
-
Shelley Powers: Discussion on permalink as compared to unique location
Discussion
[ShelleyPowers] Consider the following scenario -- a log entry is also a comment. A log entry is also an entry in an RSS file. A log entry is also a trackback item. When one looks at all the various aspects of 'log entry', then a URL to a blog entry starts to become overly limiting.
-
[AaronSw] All of these can have permalinks.
-
[ShelleyPowers] Nope, RSS excerpts don't.
-
[AaronSw] What do you mean by RSS excerpts?
-
[MichaelBernstein] I think she means that the item in an RSS feed doesn't have a permalink to it, but only contains a link to the web version of the entry it represents.
[MarkCidade] I think we should make a distinction between PermaLinks (that point to something) and UniqueIdentifiers (that are strictly for identity and don't necessarily point to any location)
-
[JamesSnell] Agree with Mark, but we need to account for PermaLinks that are unique identifiers. Also, I still think that the complete identification of a WellFormedEntry is the PermaLink/UniqueIdentifier/TimeStamp combination.
-
[MarkCidade] I would argue that a UniqueIdentifier is all that's needed for complete identification. The other information would be redundant baggage to carry around. I'm thinking of applications like RDF triples (whereas the ID is a URI). A permalink and a unique identifer can use the same string (i.e., URI), but I would only consider that as incidental (A URI may or may not also contain timestamp related info, i.e. http://example.org/permalinks/2003-06-11#Entry1300EST).
-
[BillKearney] are we talking UID or thing-that-lets-an-http-tool-retrieve it? They're different but are often linked. What is is trying to do? Identify the item uniquely or provide an indicator of how to retrieve a unique instance of the item? An OSF-style GUID would be pretty worthless in this regard. But forcing an http style URL would likewise impinge on other transports. What's really sought here?
-
[JoeGregorio] I don't believe a seperate UniqueIdentifier is required. The permalink is sufficient as a unique id. And remember one of the first base requirements Sam listed was that this was on the web.
-
[ShelleyPowers] And a variation of log entry is a comment, which doesn't usually have a permalink, but does have a unique identifier -- the author, the blog entry, and the comment timestamp. By saying permalinks are the unique identifier then you're saying that all comments must have permalinks, or that comments aren't part of this data model.
-
[MichaelBernstein, RefactorOk] It's obvious that what we currently call permalinks can fill two functions simultaneously, that of a unique identifier, and that of a canonical URL. I guess the question is, which of these roles takes precedence? In my opinion, the unique identifier role is more important, but the form of the identifier should be that of a URI, not an arbitrary GUID. The URI may be a URL, and if so, serves as a canonical URL (ie. a permalink). Here is a possible use case: A comment feed about a book, where the first item has an isbn:// URI unique identifier, but no canonical URL, and subsequent comment entries have identifiers that also serve as canonical URLs.
-
[JoeMadia] I'm torn on this issue, in part, because I'm not sure that the choices are mutually exclusive. Why not define it such that a Canonical URL is, by default, the primary key of an item and also specifies that the item is available via http. However, if a UniqueIdentifier is present (of type URI) then it would supersede all other data and act as the logical primary key for the item. This keeps it simple for current tools but also allows for future expansion when either 1) it becomes more common for feeds to be generated without a priori knowledge of what their ultimate URL will be (data driven feeds, intranet feeds, etc.) or 2) transport independence becomes desirable. Since supporting both is not terribly difficult, it feels like low hanging fruit to me and could be much more future friendly.
-
[GregReinacker] Re Joe's comment, we already have a (bad) situation with unique identifiers (like guid in RSS2) being optional; I'd like to see a situation where we have a URI, but ALSO require a unique id for every post. They may be the same, but we should allow for syndication of information that does not exist in any hyperlink-able form, in which case they may certainly be different.
-
[MichaelBernstein, RefactorOk] I would rather make the unique identifier attribute required (and defined as a URI), and if it takes the form of a URL then it doubles as a permalink. No need for separate attributes.
-
[TimBray] I wouldn't worry, the URI tent is pretty big and if for some reason you want to identify something that can't be retrieved you can still use a URI for this purpose. I think log entries should have a single unique identifier and that identifier should be required to be a URI, and then let people work out what kind of URI works best.
[TimBray] I went on at tiresome length about this today. An entry is identified by a URI (#fragments OK), because it's part of the web. If they want it to be retrievable via web protocols they'd better use that kind of URI. I think that separately a version stamp is required.
[Skware] I think a clarification needs to be made here about PermaLinks etc. PermaLinks as used by RSS / RDF indicate an AlternativeRepresentation of the entry. It is my proposal that an AlternativeRepresentation tag be used for the purpose of showing a html representation of the Entry on the web. The PermaLink should be a link to a verbatim copy of the Entry as it would appear in any syndicated feed / channel / container / collection / buzzword of the month. A user agent should be able to resolve this and download only the entry indicated. It should be possible for an entry to be associated with multiple PermaLinks, hence a unique entry ID should must be attached to the entry. This may be standardised to be site/yyyy/mm/dd/title, or some such. The only problem is what happens when another weblog uses the same unique ID to fool the user agent into replacing someone else's entry. This is a potential security risk.
[JeremyGray] Voted. Has voting stalled out on this issue? Is it perhaps time for a TrueConsensus call regarding the current leader Peas and Carrots so that we can move forward and focus on issues like PostIdSpec and the retrievability expectations for PermaLinks as illustrated by Skware immediately above this comment?