All the Perl that's Practical to Extract and Report
use Perl Log In
miyagawa (1653)
(email not shown publicly)
http://bulknews.vox.com/
AOL IM: bulknews (Add Buddy, Send Message)
URI::tag and URI::urn::uuid
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>urn:uuid:941e12b4-6eeb-4753-959d-0cbc51875387</id>
<id>tag:diveintomark.org ,2004-05-27:/archives/2004/05/27/howto-atom-linkblog</id>
See http://diveintomark.org/archives/2004/05/28/howto-atom-id 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:
http://search.cpan.org/~miyagawa/URI-tag/
http://search.cpan.org/~miyagawa/URI-urn-uuid/
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Thanks! (Score:2)
-Dom
Re: (Score:1)
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 [cpan.org], 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
Re: (Score:2)
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.
-Dom
Re: (Score:1)
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?
Re: (Score:2)
-Dom
Re: (Score:1)
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
Re: (Score:1)
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.