Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

miyagawa (1653)

  (email not shown publicly)
AOL IM: bulknews (Add Buddy, Send Message)

Journal of miyagawa (1653)

Tuesday September 26, 2006
08:18 AM

URI::tag and URI::urn::uuid

[ #31127 ]

In Atom feed, URI does quite an important role to guanratee the uniqueness of the feed and entry. Among others (like permalinks), urn:uuid and TagURI are frequently used to construct atom IDs.

<id> ,2004-05-27:/archives/2004/05/27/howto-atom-linkblog</id>

See for more.

Perl URI module doesn't have tag and urn:uuid subclasses, which itself isn't a big deal since you can always use $uri->opaque and stuff to get the string itself to compare. Though, having URI::tag and URI::urn::uuid would be useful to programatically construct those URLs and parse some information out of them.

Hence my new modules:

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I've just been generating Atom feeds, and URI::tag is just what I need!


    • Personally, I prefer UUIDs. They make it self-evident that the ID is an opaque identifier that needs to be stored alongside the entry somewhere. Tag URIs tempt people into generating them dynamically from the permalink, which, as we all know, does occasionally change (whether or not it should).

      F.ex., when I took over maintainenace of XML::Atom::SimpleFeed [], there was a blob of HTTP-to-Tag conversion code in there that was used in case an explicit ID was absent. My first official act as the new maintainer

      • I disagree. It seems perfectly obvious to me that anything that begins with "tag:" shouldn't be resolvable. Anyway, in my case, I came on to the project when tag URIs had already been chosen. This module was just a nice way of cleaning them up.

        For what it's worth, I'm only using it for generation, not parsing.


        • The question is not whether it’s resolvable. Do you generate tag URIs once and store them as a separate property of each record, or do you derive them from other properties (such as from the permalink) every time you generate the feed?

          • I'm using them as part of an OpenSearch feed. Each entry is a search result. The tag id is built each time from the domain name, a fixed year, and the entry id of the search result. So yes, in theory, the domain name could change, but in practise it's unlikely enough that I'm happy tag uris are OK.


      • Practiaclly the answer would be very simple.

        1) Tag URI can be construct using permalink any time from HTTP permalink, 1.1) but Tag URI should be stored somewhere as a metadata of the entry if permalink would be likely to change in the future, while 2) UUID needs to be stored as a metadata from the beginning, since otherwise regenerating the feed every time changes the UUID.

        So, yeah, I agree with you that using UUID explicitly declares the necessity of storing it as a metadata, but practically TagURI is stil
        • Yah, I’m not saying you should never use them. Tim Bray uses his HTTP URIs as IDs. Any URI is valid. I’m just saying I prefer infrastructure to use UUIDs because it makes View Source programming more likely to come out correct.