Subject: PaceAtomIDIsNewsML (Requiring atom:id to be a NewsML URN)

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 20:26:57 -0400

I've created a Pace to require that atom:id be a NewsML URN.
See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

For the specification of NewsML URNs see:
http://ietf.org/rfc/rfc3085.txt

		bob wyman

=========================
Abstract
Require that atom:id is a NewsML URN. Proposed by: [BobWyman] 

Status
Open 

Rationale
Much aggregator and processor experience indicates that not providing
strong guidance on the proper formation of atom:id's results in great
difficulties for the processors of atom feeds. See: mailing list
discussion. 

Proposal
Change sections 4.2.6 and 5.5 of the format specification to read: 

4.2.6 "atom:id" Element 

The "atom:id" element's content conveys a permanent, globally unique
identifier for the feed. It MUST NOT change over time, even if the feed
is relocated. atom:head elements MAY contain an atom:id element, but
MUST NOT contain more than one. The content of this element, when
present, MUST be a NewsML URN. 
5.5 "atom:id" Element 

The "atom:id" element's content conveys a permanent, globally unique
identifier for the entry. It MUST NOT change over time, even if other
representations of the entry (such as a web representation pointed to by
the entry's atom:link element) are relocated. 
For a given entry, the atom:id element's content MUST be stable across
all Atom Documents published by the same entity. 

atom:entry MUST contain exactly one atom:id element. The content of this
element MUST be a NewsML URN. 

Impacts
Slightly increases complexity of generating atom feeds and entries since
an identifier other than permalink must be created for each feed and
entry. 

Significantly increases the ability of feed aggregators and other atom
processors to detect and manage new atom entries and feeds. 

Notes
See: RFC 3085 http://ietf.org/rfc/rfc3085.txt

---

From: Ken MacLeod <[email-masked]>
Date: 25 Jul 2004 19:52:55 -0500

"Bob Wyman" <[email-masked]> writes:

> I've created a Pace to require that atom:id be a NewsML URN.  See:
> http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1.

Permathread.

Merely suggesting that the identifier should not be a URI-locator in
the examples and user guides is bad enough, but mandating a particular
URI scheme is a non-starter.

The current Atom spec says the URI should be globally (not
universally, ie. time-wise) unique.  That is sufficient for
interoperation and sufficient for the specification.

  -- Ken

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 17:53:21 -0700 (PDT)

--- Bob Wyman <[email-masked]> wrote:
> See:

+1 

Awesome. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Mark Baker <[email-masked]>
Date: Sun, 25 Jul 2004 21:08:24 -0400

> See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1, for the same reasons Ken gave.

Mark.

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 18:19:28 -0700 (PDT)

> interoperation and sufficient for the specification.

No it isn't. Bob is an aggregator author and I'm an
aggregator author who both have experience having to
write code to process the millions of syndication
feeds out there and answer to thousands of customers.
Both of us have said based on our experience the
current specification text is for interoperation and
is harmful to a positive user experience. 

Besides dismissing our points of view with your
statements of authority do you have any arguments to
justify your position. I have several. What are yours? 

=====

_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. 
http://messenger.yahoo.com

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 26 Jul 2004 02:19:39 +0100

> -1, for the same reasons Ken gave.

-1 for two other reasons (I just sent them elsewhere before I saw this):

  - NewsML urns have non-Atom semantic import. It is arguably an 
abuse to put them into Atom.

  -NewsML urns are explicitly specified as being for identifying 
NewsML items.

If this the way you want to go, please use Tag URIs - they do not 
have non-Atom semantic import, they are in fact general purpose 
identifiers, there are the same number of them as NewsML urns.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sun, 25 Jul 2004 21:22:03 -0400

> URI scheme is a non-starter.

I fail to see why (please explain :). Pretty much everyone looking to create
an Atom feed went looking for Mark's tag: scheme article. We *can* prescribe
a scheme.

Furthermore, you're free to include a service.edit link in the entry, which
you can make publicly GETable, if you wish.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 18:30:54 -0700 (PDT)

--- Mark Baker <[email-masked]> wrote:
> -1, for the same reasons Ken gave.

I didn't see any technical reasons in Ken's email. Can
you clarify exactly what they were so I can decipher
what your technical opinions on this matter are?

=====

---

From: Ken MacLeod <[email-masked]>
Date: 25 Jul 2004 21:19:42 -0500

Dare Obasanjo <[email-masked]> writes:

> No it isn't. Bob is an aggregator author and I'm an aggregator
> author who both have experience having to write code to process the
> millions of syndication feeds out there and answer to thousands of
> customers.  Both of us have said based on our experience the current
> specification text is for interoperation and is harmful to a
> positive user experience.
> 
> Besides dismissing our points of view with your statements of
> authority do you have any arguments to justify your position. I have
> several. What are yours?

The URI scheme is not the root cause of the duplicate, unchanging,
reused, or non-existent ID problems.

Thus, mandating a particular URI scheme will not solve the symptoms of
those ID problems in any significant way.

What we can do is provide dozens of examples of what globally unique
identifiers are, show how they affect interoperability, and say why
publishers should support them.

The most significant things a publishing system can do to prevent
identifier problems is 1) provide the ability to create globally
unique identifiers (preferably without user interaction) and 2)
preserve the original URI with the entry.  Neither of those require
mandating a URI scheme.

 -- Ken

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 22:27:08 -0400

Ken MacLeod wrote:
>  but mandating a particular URI scheme is a non-starter.
	Thank you for your opinion. Now, how about explaining *why* it
is a non-starter? If we can mandate the format for a date, why can't we
mandate the format for atom:id? Or, do you think we should also support
user creativity in date formats as well? If we can mandate the
identifiers for languages, why can't we mandate atom:id format? Etc...
	Can you make a case which justifies supporting variety and user
creativity in forming atom:id's? Given that these things should be
treated as opaque strings, just about all the arguments that would rely
on embedding meaning into the ids are immediately made mute. As long as
ids that should be handled as opaque strings, why is variety valuable?
What user benefit comes from variety in atom:id format?

> The current Atom spec says the URI should be globally
> (not universally, ie. time-wise) unique.  That is
> sufficient for interoperation and sufficient for
> the specification.
	In theory, it *should be* enough. However, in practice it simply
isn't. Every aggregator developer I've ever discussed this with has
expressed extreme frustration with the id's in both RSS and Atom feeds
and every one of them has said that it would be much easier to deliver
user-demanded quality if the ID's were, in fact, unique. Clearly, just
asking people to "do the right thing" isn't getting us where we need to
be in order to meet user expectations. Given that, we have little choice
but to mandate a solution.

		bob wyman

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 19:51:40 -0700 (PDT)

> those ID problems in any significant way.

Interesting. I'll list 3 problems that using HTTP URLs
as identifiers cause in RSS to RSS Bandit users today.
I'll claim that using identifiers that double
locations of network retrievable documents will cause
a significant reduction of these problems. 

1.) Duplicate posts in feeds generated by search
engines. Lots of people cross post entries (e.g. any
body who is on the Artima Buzz forums or Java.blogs).
When a search matches one of these entries it shows up
in the search generated feed multiple times because
the permalinks are different although the same entry
is referenced. 

2.) Duplicate posts when people change weblogging
tools or hosting providers. HTTP URLs vary dependent
on the users hosting provider and the tool they use.
When this information changes, the identity of every
post in the feed changes. 

3.) Redundant posts from aggregated feeds. Since I
work at Microsoft I read many feeds from
http://weblogs.asp.net, however I am also subscribed
to individual blogs of Microsoft employees who are
hosted on http://blogs.msdn.com but whose posts show
up in the feed for the former site since one domain
name is an alias for the other. Having a unique
identifier for an item would let me mark an item as
seen independent on whether it was seen on the
http://weblogs.asp.net feed or http://blogs.msdn.com
feed. 

> preserve the original URI with the entry.  Neither

You seem to miss the point. No one is claiming that
you can't make HTTP URLs globally unique using some
algorithm. The point is that experience has taught us
that if people can use HTTP URLs as identifiers, they
will use permalinks not some abstract "globally unique
identifier". Using permalinks as identifiers causes
problems. I have listed 3 above. I can come up with
more if you'd like. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jul 2004 20:12:35 -0700

> is harmful to a positive user experience.

Well, you are advancing the hypothesis that people who cannot 
competently manage a stable identifier space when the identifiers begin 
with "http:" will become capable of doing so when the identifiers begin 
with some other prefix.  It's not obviously insane and it is possible 
that you are correct.  Looking at the same evidence, I doubt it, and 
that's life.  In any case, I seriously think there is lack of 
sufficient experimental evidence to write this hypothesis into an RFC. 
-Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 25 Jul 2004 23:34:00 -0400

Dare Obasanjo wrote:
> 3.) Redundant posts from aggregated feeds. Since I work at
> Microsoft I read many feeds from http://weblogs.asp.net,
> however I am also subscribed to individual blogs of Microsoft
> employees who are hosted on http://blogs.msdn.com but whose
> posts show up in the feed for the former site since one domain
> name is an alias for the other.
	The Microsoft blogs are a real nightmare for any aggregator
developer because of this dual hosting business. Disambiguating between
duplicates on the Microsoft site is impossible without site-specific
logic. Picking one blog at random will demonstrate the problem.
	One can find a recent entry from "Rakesh's Blog" at either:
	http://blogs.msdn.com/rakeshna/archive/2004/07/25/196520.aspx
Or	http://weblogs.asp.net/rakeshna/archive/2004/07/25/196520.aspx

	On both pages, you'll find a link to "Syndication". The contents
of the file retrieved will, however, depend on the domain you use. 

The following fragment is from the RSS file at:
http://weblogs.asp.net/rakeshna/Rss.aspx

- <item>
  <dc:creator>Rakesh Namineni</dc:creator> 
  <title>Decisions.</title> 
 
<link>http://weblogs.asp.net/rakeshna/archive/2004/07/25/196520.aspx</li
nk> 
  <pubDate>Sun, 25 Jul 2004 19:09:00 GMT</pubDate> 
 
<guid>http://weblogs.asp.net/rakeshna/archive/2004/07/25/196520.aspx</gu
id> 

The following is from the RSS file at
http://blogs.msdn.com/rakeshna/Rss.aspx and describes precisely the same
entry as the previous example. The only diffence is in the URL's used as
permalinks.

- <item>
  <dc:creator>Rakesh Namineni</dc:creator> 
  <title>Decisions.</title> 
 
<link>http://blogs.msdn.com/rakeshna/archive/2004/07/25/196520.aspx</lin
k> 
  <pubDate>Sun, 25 Jul 2004 19:09:00 GMT</pubDate> 
 
<guid>http://blogs.msdn.com/rakeshna/archive/2004/07/25/196520.aspx</gui
d> 

	What you see here is a single "entry" that has completely
different metadata based on which site is used to access the entry.
These are the sorts of things that people do when they see that  an
identifier is an URL. Now, there is no question that we could contact
the Microsoft people and beg them to stop this silliness. Given the
"new, kinder, gentler" Microsoft, they might even agree to fix the
problem. However, there are many others out there who do similar things.
Who wants to be the policeman on this issue?
	Some might argue that this is just an artifact of RSS use.
However, the reality is that if Microsoft didn't understand the impact
of what they were doing when they defined their RSS feeds, it isn't any
more probable that they will figure it out when creating Atom feeds --
unless we simply make sure that atom:id is NOT an URL and thus, they
can't get confused.

		bob wyman

---

From: Ken MacLeod <[email-masked]>
Date: 25 Jul 2004 22:38:59 -0500

Dare Obasanjo <[email-masked]> writes:

> Interesting. I'll list 3 problems that using HTTP URLs as
> identifiers cause in RSS to RSS Bandit users today.  I'll claim that
> using identifiers that double locations of network retrievable
> documents will cause a significant reduction of these problems.

    <id>urn:newsml:$HOSTNAME:$DATE:$CATEGORY.$POSTNUM:1</id>

This host template "macro" will also not help any of the three issues
described, regardless that they use the 'newsml' URN scheme.

> You seem to miss the point. No one is claiming that you can't make
> HTTP URLs globally unique using some algorithm. The point is that
> experience has taught us that if people can use HTTP URLs as
> identifiers, they will use permalinks not some abstract "globally
> unique identifier". Using permalinks as identifiers causes
> problems. I have listed 3 above. I can come up with more if you'd
> like.

I'm not sure how or if we can mandate this, but mandating that
publishers preserve the originally generated URI for an entry and that
the same URI is put in <id> for every instance of that entry and that
intermediaries always preserve the URI seems to be the most promising
solution to the problem.

Any specific URI scheme is only an example of a possible identifier,
it's not an inherent solution for the problem.

I am not trying to be argumentative about this nor do I think I
misunderstand the situation.  I *have seen* the existing publishers
use "macros" to provide IDs in their templates instead of preserving
URIs.  Mandating URI schemes isn't going to solve that problem.

  -- Ken

---

From: Mark Baker <[email-masked]>
Date: Sun, 25 Jul 2004 23:43:17 -0400

> the permalinks are different although the same entry

Why is that the fault of the http URI scheme?  It seems to me that it's
the fault of the posting mechanisms of those sites for not asking the
user for a permalink id in case there's already one (as there is in this
case).

> post in the feed changes. 

In both cases, there is an answer for users; use your own domain name,
and use better tools or at least additional tools which help you evolve
your URI space (e.g. mod_redirect).

Again, this is not a problem with the http URI scheme.

> http://weblogs.asp.net feed or http://blogs.msdn.com

And if that unique identifier were an http URI, it would work just as
well.  See #1 above.

I applaud your interests in ensuring that its easy for your users to
make permanent links, but ultimately, it's they who need to make the
committment, not us (see my answer to #2).  IMO, any attempt to try to
do for users what they won't do for themselves will result in
undesirable artifacts in the spec which impede evolution (e.g. the
mandating-the-URI-scheme requirement mentioned in the pace) and
generally just unnecessarily constrain implementations.

Mark.

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 20:48:17 -0700 (PDT)

> sufficient experimental evidence to write this

There is enough experimental evidence to show that
HTTP URLs don't work as unique identifiers. So I'd
like to see where we go from there. I'm saddened to
see that instead of listening to implementers who have
to deal with this mess on a daily basis we are still
hearing the URI religion broken record. 

This debate reminds me why other aggregator authors
have decided to stay out of the Atom discussion.   

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Eric Scheid <[email-masked]>
Date: Mon, 26 Jul 2004 13:33:22 +1000

On 26/7/04 1:12 PM, "Tim Bray" <[email-masked]> wrote:

> with some other prefix.

It may not be a matter of "cannot competently manage", but instead "looks
like a URL will do, won't bother thinking any further". Unfortunately, using
'http' URIs properly requires them to think not just about the id aspect,
but also how to handle the compromises imposed by the deferencing aspect.

If they are guided to using some arcane thing they've not seen before, and
which doesn't look like a URL does (lots of slashes and stuff), then they
might actually engage brain for the few short cycles necessary.

One hopes.

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 20:53:50 -0700 (PDT)

*sigh* 

"Guns don't kill people, people do."

I feel like a gun control advocate arguing with
members of the NRA. I really don't have time to engage
in the eternal URI permathread. HTTP URLs used as
identifiers cause problems today, Atom can choose to
mitigate this error by avoiding them or not. Atom can
fix the mess that is the various flavors of RSS or it
can wallow in their filth. You and Tim have decided
that it should do the latter. I am not attached to
Atom enough to continue debating this more than I have
now. Enjoy. 

That's all folks. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 26 Jul 2004 00:13:23 -0400

Tim Bray wrote:
> Well, you are advancing the hypothesis that people who
> cannot competently manage a stable identifier space when
> the identifiers begin with "http:" will become capable of
> doing so when the identifiers begin with some other prefix.
> It's not obviously insane and it is possible that you are correct.
	What we're talking about here is as much psychology as it is
technology. What we *do* know is that we don't want people to be
confused by "http-think" when they are creating atom:ids. For instance
http-think leads to the idea that a URI should be somehow related to the
name of the machine that is used to access an item. This is the problem
that creates the mess on the Microsoft machines. It is *obvious* that
the guids for items on blogs.msdn.com should start with "blogs.msdn.com"
while the guids for items accessed on weblogs.asp.net should be
different. Unfortunately, what is obvious isn't true.
	The goal is to get people to think clearly about the problem of
defining a unique identifier and to allow them to do it without the
confusion of unrelated ideas like those related to HTTP retrieval. This
is a psychology problem -- not a technology problem.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 26 Jul 2004 00:21:22 -0400

Ken MacLeod wrote:
> This host template "macro" will also not help any of the
> three issues described, regardless that they use the
> 'newsml' URN scheme.
	You are, of course, correct since your macro seems to be
designed to generate output. However, you *should not* be attempting to
generate the atom:id in an output function. Rather, the id should be
generated as a by-product of creating the entry. Once created, it should
be carried with the entry in internal databases, etc. as static data in
precisely the same way that a creation-date or title would be carried.
	The correct macro for output would be something like:

	<id>$ATOMID</id>

	Anything else is going to result in all the problems mentioned
before. Atom:id's should *only* be generated when a new entry is created
and then only as a one-shot input function.

		bob wyman

---

From: Sam Ruby <[email-masked]>
Date: Mon, 26 Jul 2004 00:29:02 -0400

> is a psychology problem -- not a technology problem.

To put it more succinctly: syntax matters.

Now, why isn't it *obvious* that the NewsML ID for URIs on 
blogs.msdn.com should have a ProviderId of blogs.msdn.com?

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 21:44:26 -0700 (PDT)

> blogs.msdn.com should have a ProviderId of

NewsML IDs may have the same problems as HTTP URLs. So
lets talk about the root of the problem. 

IDs must not change. 

All the problems aggregator authors face with IDs are
because they change. Either because an item is posted
on different sites with each site giving it a site
specific ID or an entry's IDs change when the content
producer changes something about the server such as
the CMS or the hosting provider. 

If Atom plans to do a better job than RSS, it needs to
solve this problem. Suggesting using NewsML URNs is an
attempt to have content producers and tools vendors
realize that entry IDs should be unique and
unchanging. However this doesn't tackle the problem at
its root. 

Ideally Atom should have normative text pointing out
that items should have unique and *unchanging*
identifiers including examples that currently break in
RSS today due to changing identifiers. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Mon, 26 Jul 2004 00:42:22 -0400

> and then only as a one-shot input function.

How many existing databases have a "column" for this?

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jul 2004 21:49:12 -0700

> RSS today due to changing identifiers.

+1 -Tim

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jul 2004 21:48:29 -0700

I care about this identifier stuff, but I care more about getting Atom  
finished.  So I am *not* going to stand in the way of a compromise  
position just on the grounds that I disbelieve its technical  
underpinnings.

So, I think we have *strong* consensus on the following proposition:

- It is not a goal that <atom:id> be usable for retrieval of  
information.

(Does anyone disagree?  I'd be astounded).

I personally think that should suffice, but I get the impression that  
the http-identifiers-are-broken faction is asking for more.  So, here's  
proposed compromise language:

======================================================================== 
==========
Given that HTTP URIs can be used for retrieval of information, it is  
possible that their use in <atom:id> could lead to erroneous  
understanding of the meaning and correct use of <atom:id>.  For this  
reason, implementors SHOULD consider using another URI scheme (see  
[http://www.iana.org/assignments/uri-schemes]) which does not imply  
information-retrieval semantics, for example URNs (see [RFC2141] and  
http://www.iana.org/assignments/urn-namespaces).
======================================================================== 
==========

BTW, with specific reference to urn:newsml:, I think it's a sensible  
and well-designed URN namespace, but I think you're going to have  
trouble getting past the problem that leaps to my eye when I read the  
RFC3085 abstract:
   "This document describes a URN (Uniform Resource Name) namespace for
    identifying NewsML NewsItems.  A NewsItem is an information resource
    that is expressible as a NewsML element within a NewsML document
    conforming to the NewsML Document Type Declaration (DTD) as defined
    by the International Press Telecommunications Council (IPTC)."

---

From: Sam Ruby <[email-masked]>
Date: Mon, 26 Jul 2004 01:03:17 -0400

> RSS today due to changing identifiers. 

I predict that if somebody were to write up such a pace, it would get 
consensus quickly.

I did a quick scan:

In RSS 1.0, there is a statement: "{item_uri} should be identical to the 
value of the <link>  sub-element of the <item> element, if possible."

In RSS 2.0, one can find "isPermaLink is optional, its default value is 
true."

A single xml.com article which describes how an unregistered URI scheme 
can be used has influenced countless Atom feeds to use the "tag" scheme.

It seems that one can conclude that in feed formats in which the 
documentation suggests that ids be links, results in feeds with ids as 
links.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Mon, 26 Jul 2004 15:32:45 +0900

+1

Regards,   Martin.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 26 Jul 2004 02:40:39 -0400

Sam Ruby wrote:
> How many existing databases have a "column"
> for this? [i.e. AtomID]
	Even with the Atom specification in its current form, anyone who
is generating atom feeds SHOULD have such a column. It is unfortunately
quite clear that many don't even though an atom:id is already required
to be invariant. Thus, the atom:id must be based on invariant data.
Given that base URL's and other elements from which ids might be
composed can vary, the only way you can meet the requirements of the
specification are to fix the atom:id at the time that it is first
generated.
	I'm concerned that your question implies that we should avoid
making specification decisions that might require people to modify their
existing implementations. Frankly, I think such a suggestion is totally
inappropriate. The only way we could meet such a restriction is by
ensuing that Atom is nothing more than a simply transform on RSS. The
point of this exercise is to define a better format, not just change the
names of the existing fields. We should not be overly constrained by
existing implementations. Our goal should be to define a format that
will best allow user's needs to be better addressed by future
implementations.

		bob wyman

---

From: Martin Duerst <[email-masked]>
Date: Mon, 26 Jul 2004 15:35:36 +0900

>See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1. It is never a good idea to restrict a specific field to
a single URI scheme (or URN scheme, or whatever). If you do that,
the point of using an URI just disappears. If you want to use
NewsML only, the best thing to do is to call the attribute
"NewsMLid" (or some such), and to remove the leading urn:newsml:.
Otherwise, people will use other uri schemes anyway.

But when you do that, you realize that you severely limit future
extensibility.

Regards,    Martin.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 26 Jul 2004 02:46:02 -0400

Sam Ruby wrote:
> Now, why isn't it *obvious* that the NewsML ID for 
> URIs on blogs.msdn.com should have a ProviderId of
> blogs.msdn.com?
	Because, an atom:id which is a NewsML URN is something different
from an URL. Thus, users of these things will learn new practices, new
philosophies, new expectations for how they are used. As Eric Scheid
wrote: "If they are guided to using some arcane thing they've not seen
before, and which doesn't look like a URL does (lots of slashes and
stuff), then they might actually engage brain for the few short cycles
necessary."

		bob wyman

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Jul 2004 08:59:17 +0200

Hi,

maybe looking at other IETF specs for guidance would be of interest.

WebDAV (RFC2518) uses URIs to identify locks. The so-called "lock 
tokens" URIs "...MUST be unique across all resources for all time" 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.6.3>). So 
this is a very similar problem.

Solution:

1) cleanly spell out the uniqueness requirement, but say that *any* URI 
scheme will do as long as this requirement is fulfilled

2) recommend *one* specific scheme that works fine, and use that one 
through the examples

1) ensures that people how want HTTP URLs can actually use them (or 
something else). 2) helps those who are unsure and just want a reliable 
solution without having to think too much about the details.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Dan Brickley <[email-masked]>
Date: Mon, 26 Jul 2004 03:40:22 -0400

* Tim Bray <[email-masked]> [2004-07-25 20:12-0700]

+1

I have a problem with mandating a particular URI scheme (ie. URNs) when
there are other non-HTTP URI schemes (freenet, uuid, tag, ...) that are 
in a similar business. Even in the URN world. there are other corners of
URN space, current and future, which try to do the same thing. I'm not
seeing a compelling reason for creating a dependency on NewsML URN/URIs.

Dan

---

From: Dan Brickley <[email-masked]>
Date: Mon, 26 Jul 2004 03:44:23 -0400

* Martin Duerst <[email-masked]> [2004-07-26 15:32+0900]

+1

Dan

---

From: Dan Brickley <[email-masked]>
Date: Mon, 26 Jul 2004 03:53:32 -0400

* Bob Wyman <[email-masked]> [2004-07-26 02:46-0400]
> from an URL. 

I wouldn't be so sure. The more popular such URN ID systems become, the
more likely it is we'll start to see resolution services provided at the
ISP / proxy cache layer. At which point the pschological distinction
between "I can put this into the browser address/URL/etc bar to get
myself a representation of it" vs "I can put this into Google to get
myself a representation of it" starts to crumble.

http://www.dlib.org/dlib/june98/06powell.html for example shows the use
of DOI URNs with a Squid proxy cache. If you plug your laptop into the
Bath University network there's a good chance that identifiers like 
urn:doi:10.1000/1 will behave an awful lot like http URLs. The distinction
between URL and non-URL URI isn't such a technical one, but is more to
do with the transparency and ease of finding/locating/accessing
representations of the thing the URI names. Which in turn is more to do
with markets, adoption and quirks of engineering history. Todays URNs
could be tommorrows URLs.

Dan

---

From: Dan Brickley <[email-masked]>
Date: Mon, 26 Jul 2004 04:02:10 -0400

* Bob Wyman <[email-masked]> [2004-07-25 22:27-0400]
> mandate the format for atom:id? 

I think this comparison misses the mark. Mandating the date syntax
gives us an ISO-8601 profile, ie. an agreed notation for writing dates
down. Mandating an identifier syntax gives us URIs, ie. an agreed
notation for writing identifiers down. Both are wise; but neither is in
the business of telling us *which* dates or identifiers are legitimate.
Messing with the value space ("no dates before Alan Turing, 'cos weblogs
and aggregators didn't exist then"; "no URIs except those assigned
according to the NewsML URN approach") is a reasonable distinct sort of
restriction to be making. An unnecessarily one, in my experience.

Or, do you think we should also support

> creativity in forming atom:id's? 

You make good arguments for restricting to a common identifier syntax 
(in atom:id and elsewhere). The URI spec can serve that purpose for us,
just as we have a common date syntax for date-related fields.

Dan

---

From: Dan Brickley <[email-masked]>
Date: Mon, 26 Jul 2004 04:04:26 -0400

* Martin Duerst <[email-masked]> [2004-07-26 15:35+0900]
> >See: http://www.intertwingly.net/wiki/pie/PaceAtomIDIsNewsML

-1 to the Pace, for the reasons given by Martin and my recent posts 
in this thread.

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 26 Jul 2004 10:52:40 +0100

Tim Bray wrote:

> - It is not a goal that <atom:id> be usable for retrieval of  information.
> 

I agree, but more than non-goals are needed. Bob and Dare, the 
implementors  who are boosting NewsML have already indicated 
agreement with this requirement:

"all Atom entries must have unique (space and time) surrogate keys 
to support aggregation use-cases"

Whether or not you one uses URIs for retrieval is not the issue - 
stability of identifiers is - the claim is that HTTP /URIs/ result 
in instability and in part this may be down to them also being URLs. 
But it would be a mistake to think that not saying it's a non-goal 
for atom:ids to be retrievable will address the matter.

> proposed compromise language:

Excellent - text. Thank you.

I would suggest:

"Atom entries are required to use stable and unique URIs in the 
atom:id elment. Note: past experience has shown that the use of URLs 
(such as the http: scheme) can lead to erroneous understanding of 
the meaning and correct use of atom:id. For this reason, 
implementors SHOULD consider using  URNs which do not have retrieval 
semantics (see [RFC2141] and 
http://www.iana.org/assignments/urn-namespaces). In any case Atom 
consumers MUST NOT expect that the values used in atom:id import any 
semantics other than that of identification."

ie whatever the exact end text is, it should say two things 1) what 
the requirement is (stable identity), 2) not to use identifiers for 
anything other than identity.

>    by the International Press Telecommunications Council (IPTC)."

This has already been pointed out twice, along with the extra 
semantics the scheme carries. It seems to have gotten lost in all 
the fire and brimstone so far. Do keep pointing it out every few 
posts - it's not the same concern as Martin's.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Mon, 26 Jul 2004 12:39:26 -0400

On 26 Jul 2004, at 12:48 am, Tim Bray wrote:

> the http-identifiers-are-broken faction is asking for more.

I actually agree that the http-identifiers-are-broken group are  
overlooking that in RSS the guid doubles as the address of a  
retrievable resource, whereas in Atom it doesn't. I think that makes  
the problem already solved.

> ======================================================================= 
> ===========
> ======================================================================= 
> ===========

Saying aggregators should never attempt retrieval of the resource at  
<id>, and that publishers don't need to point them at anything might be  
enough.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 26 Jul 2004 09:56:35 -0700 (PDT)

> the problem already solved.

If past experience tells people that an HTTP URL used
as an identifier in a syndication format should be the
permalink why should they behave differently when a
new syndication format shows up that uses HTTP URLs as
identifiers? 

Are you claiming that there are no Atom feeds out
there that use permalinks as values of atom:id? 

=====

---

From: Elias Torres <[email-masked]>
Date: Mon, 26 Jul 2004 13:26:28 -0400

> the problem already solved.

I'd rather say that in Atom it shouldn't double up as address and
guid. But that's exactly the problem. Before this discussion started,
everyone either was going to do what Mark suggested in his XML.com
article or just use their current URLs. If we don't make it clear to
people to think twice before creating an ID, they will just use the
URL assuming that the user was clever enough to choose a nice scheme
for their posts (i.e. /archives/200x/02/01/etc).

> <id>, and that publishers don't need to point them at anything might be

I'm not advocating that the IDs used cannot be resolved. I actually
would like them to be, but then again that's not the problem. The
problem is not whether something is resolvable or not, the problem is
that IDs need to behave as IDs. That is not changing and unique. So if
Dare and/or others decide to resolve LSIDs or just HTTP URLs used in
the atom:id element that's ok, what they are complaining about is that
they are not unique.

This is extremely important because as you mentioned RSS
publishers/developers are not used with coming up with unique IDs,
they in fact been using URLs for way too long and it does not work (as
per all the reasons already mentioned in this thread). If we want to
improve upon RSS we need to take a definitive step in Atom and not
brush it off with a "Generic URI" element.

---

From: Tim Bray <[email-masked]>
Date: Mon, 26 Jul 2004 10:42:21 -0700

On Jul 26, 2004, at 10:26 AM, Elias Torres wrote:

> If we don't make it clear to

Right.  And, given the right level of commitment and management 
structure, there's nothing intrinsically wrong with doing this.  But 
the discussion here has convinced me that it's highly appropriate to 
wave lots of red flags to ensure that people *do* think twice, and if 
they have misgivings about the longevity of their HTTP-space, to use 
something else.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Mon, 26 Jul 2004 10:39:54 -0700

On Jul 26, 2004, at 2:52 AM, Bill de hÓra wrote:

>  For this reason, implementors SHOULD consider using  URNs

No.  For example, "tag:" is a URI scheme, not a URN namespace.  
Specifically pointing at URNs is not appropriate. -Tim

---

From: Ken MacLeod <[email-masked]>
Date: 26 Jul 2004 12:43:33 -0500

> (Does anyone disagree?  I'd be astounded).

For what it's worth, atom:id's probably will be used for retrieval,
but not by using the URI scheme as the primary access mechanism.

It will certainly be used as an internal linking identifier
(eg. PaceLinkParent), and its use for external (cross-feed) linking is
very likely as well.

At first it will only be usable in clients, but I highly suspect the
big feed services to offer URI to URI-location mapping and caching.

That would certainly be easier and more robust than always carring
around the URI name and one of many URI locators for every cross-feed
reference between entries, origins, and other Atom resources.

  -- Ken

PS. I want to emphasize this has nothing to do with the URI scheme.
Even if http: URIs were 95% dereferencable, using the ID for both
internal referencing and caching would still be used.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 26 Jul 2004 20:30:27 +0200

On Sun, 25 Jul 2004 21:44:26 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> Ideally Atom should have normative text pointing out that items should
> have unique and *unchanging* identifiers

I agree. I've tried to hack down some specification text about this in  
PaceRecommendIdScheme[1]. Please revise it and make comments if you think  
of anything that might improve it.

> including examples that currently break in RSS today due to changing
> identifiers.

Great idea. I've always stated that the Atom specification currently  
contains too few examples (it only contains one). Since you know this  
problem space better than the most of us, could you maybe provide some?  
Just put them down on the Wiki if you will. Thanks in advanced.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Ken MacLeod <[email-masked]>
Date: 26 Jul 2004 13:25:39 -0500

Focusing on the specific requirement that publishers preserve
identifiers, here are three tests and code review suggestions I came
up with to test atom:id recording and portability in publishing
systems.  I'll link them to the ConformanceTests page when they show
up in the atom-syntax archive.  These tests are not automatable in
general usage, but publishers could automate them for their own needs,
and others can use them manually to validate publishing systems.

These tests apply regardless of URI scheme.

ID-IS-SAME-IN-MULTIPLE-LOCATIONS

    Create an entry intended to appear in multiple locations
    (categories, cross-site syndication), note its atom:id identifier.
    Confirm the same ID appears in all locations.

    Code Review: ensure the atom:id identifier is generated in a
    manner that won't change depending on the location the entry is
    output or when transmitted to other systems (using Atom format or
    internal transmission formats).

ID-IS-SAME-AFTER-MIGRATION

    Create an entry, note its atom:id identifier.  Reconfigure the
    system or relaunch the system in a way that the URI locations that
    entries appear would change, such as new base-URI location, domain
    name change, or user name change.  Confirm that the atom:id noted
    earlier has not changed.

    Code review: ensure that the atom:id identifier is generated once
    and stored with the entry along with its other content, and the
    stored ID is used whenever the entry is output.

ID-IS-SAME-AFTER-IMPORTING

    If the publishing system supports importing of Atom
    archives/feeds, load the Atom test case [[note to editor:
    reference test case]].  Confirm that the atom:id in output is
    [[note to editor: copy atom:id from test case]].

    Code review: ensure that imported atom:id identifiers are stored
    with the entry and the stored ID is used whenever the entry is
    output.  Note that there is no a priori limit on the length of a
    URI, so a variable length storage field is most appropriate; if a
    fixed length must be used, consider making it configurable at
    install and/or run-time, and ensure that the length of imported
    URIs does not exceed the configured length.

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 26 Jul 2004 19:31:31 +0100

> Specifically pointing at URNs is not appropriate. -Tim

Good catch.

cheers
Bill

---

From: "John Panzer" <[email-masked]>
Date: Mon, 26 Jul 2004 13:14:49 -0700

> big feed services to offer URI to URI-location mapping and caching.

It sounds like you're saying that dereferenceability (d16y?) would be an 
add-on extension rather than something needed by the protocol, right?

So any cross-references that someone would typically need to dereference 
would _not_ use atom:id, or at least would require a URI-location as well?

 > reference between entries, origins, and other Atom resources.

Easier for the clients, anyway.  I'll just note this:  It's nontrivial 
for a server to provide an efficient, scalable id lookup service for 
abitrary unique string keys which are not under server control.  Not a 
huge problem, by any means, but it's certainly a layer that doesn't 
exist today for our product and would need to be built.

-John

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 26 Jul 2004 13:45:25 -0700 (PDT)

> of anything that might improve it.

I'm busy today and tomorrow. If no one has helped with
this Pace by Wednesday I'll give it a whirl.

> Just put them down on the Wiki if you will. Thanks

Ditto. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 26 Jul 2004 19:16:20 -0400

I sent mail to Tim Kindberg, author of the Tag ID, to check on the status of
Tag. The following is his response (published with his permission):

"We are continuing to push for registration -- especially because Atom has
been tending towards using tags and YAML has adopted them."

"It's absurd that newsml has been registered but tag hasn't. The
registration process is notoriously broken. Larry Masinter has organised a
BOF session for the next IETF meeting (around 1st August) which will
consider, among other things, why certain schemes including ours are not
getting anywhere. No reason has been given for the lack of progress. We're
busy people and have sometimes been a little slow to get the next draft out
but we've done everything asked of us."

"Tags have been endlessly debated but before now we've been missing a user
community to back us up. If representatives of the Atom community were to
send out a message to [email-masked], cc Ted Hardie, the IETF area director,
saying you want to use tags but need the scheme to be recognised, that could
only help."

"Cheers, Tim."

	From this, it sounds like those who would prefer tag to NewsML and
who are attending the IETF meeting should consider attending the BOF to
encourage progress on tag adoption.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Mon, 26 Jul 2004 16:47:14 -0700

> encourage progress on tag adoption.

Hmm, I note that the TAG URI home page states 
[http://www.taguri.org/#whoIsUsing] that "Tags are used to identify 
blog items in the  Atom personal publishing standard,  as in this 
example." (points at http://www.intertwingly.net/wiki/pie/IdElement?)  
-Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 26 Jul 2004 20:25:24 -0400

> Specifically pointing at URNs is not appropriate. -Tim
	Tim, forgive me for obviously missing something here... Could you
please explain why "pointing at URNs is not appropriate." I don't get it.
Please accept my apology if this is a really stupid question.

		bob wyman

---

From: "Laurent Le Meur" <[email-masked]>
Date: Tue, 27 Jul 2004 09:40:16 +0200

I followed the discussion and will just add a quick comment as a former
participant to the creation of the NewsML URN.

The requirement (please see http://www.newsml.org/pages/intro_newsml2.php if
you want to read the complete NewsML requirements, recently written during
the study of the totally revamped NewsML 2) is expressed as follows:
 	
Identification
1) Each news-item MUST have a globally unique identifier, i.e. an identifier
that is unique, unambiguous and permanent. 
2) This news-item globally unique identifier MUST take the form of a URN.
3) The globally unique identifier of a news-item MUST be independent of its
physical representation.

Globally unique identifiers are defined as: An identifier that is unique,
unambiguous, and permanent. Being unique and unambiguous means that there is
a 1:1 relationship between the identifier and the identified object. Being
permanent means that its value never changes when time passes, and is never
reused as an identifier for another object even if the original object
disappears.

The IPTC decided to create globally unique identifiers in the form of URNs
in order to avoid the usual ambiguity between an id and a locator (it has
been discussed extensively here). 

We knew that this had more to do with "good practices" than technical
features. The main interest of the NewsML URN is effectively that it gives
providers a *recipe* for globally unique ids creation. It is easy: no
specific central body is needed for the affectation of provider ids, as
internet domain names are used. As news archives are important, the fact
that a domain name ownership can change is taken into account. As in the
case of the Tag URIs, it uses the association of a domain name and a date
(it is a full ISO date/time stamp, but a year could usually be sufficient)
to get an unambiguous provider id. As revisions are an important part of
news handling (atom will certainly also go there some day), the NewsML URN
also use revision ids.

And it works well, for the main news providers worldwide, for 3 years now. 

Certainly Atom should not require a specific URI scheme; I see at least one
specific reason for this: an Atom item may be created out of another form of
item, maybe a NewsML news item, and we should be able to keep the guid
across the change of format.

But as Julian says, the specs could show the use of a good URI scheme via
samples. As the IPTC has already thought about a modification of the wording
of the RFC3085 (there is an ambiguity in some wording), removing the express
association between this URN and NewsML NewsItems could perhaps be studied
by the IPTC, if NewsML URN are of interest for a broad range of users. 

Laurent Le Meur
NewsML WG chairman
Agence France Presse

  > -----Message d'origine-----
  > De : [email-masked] [mailto:owner-atom-
  > [email-masked]] De la part de Julian Reschke
  > Envoyé : lundi 26 juillet 2004 08:59
  > À : Tim Bray
  > Cc : [email-masked]
  > Objet : Re: PaceItemIDIsNewsML: Struggling for compromise
  > 
  > 
  > Hi,
  >

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 27 Jul 2004 10:29:29 -0400

Laurent Le Meur wrote:
> an Atom item may be created out of another form of
> item, maybe a NewsML news item, and we should be able
> to keep the guid across the change of format.
	A common case of needing to import an identifier into an Atom
document arises whenever an RSS feed is converted to an Atom feed or
whenever one or more items from an RSS feed are inserted into an Atom feed. 
	If the Atom spec requires (as I proposed in PaceItemIDIsNewsML) that
the id MUST be of one form or another, then it will be necessary for tools
to create new and conformant ids for "foreign" items that are imported or
converted. This would be unfortunate since it is unlikely that different
synthesizers would agree on the precise method for improvising ids for
foreign items/entries. Thus, we would have duplicates flowing through the
system which had different ids. Over time, as Atom becomes the dominant
format, this problem would slowly evaporate, however, I think we need to be
prepared for a long transition from RSS to Atom. Also, we need to recognize
that even if RSS were to be completely replaced by Atom, we would still have
many entries that are sourced from feeds such as NewsML, NNTP newsfeeds,
etc.
	It seems that atom:id should permit any URI, if only to ensure that
items can be imported from non-Atom sources with minimal loss of
information. However, I think it is still important that we attempt to
achieve as much consistency as possible in the ids that are generated for
native Atom encodings. Thus, I would argue that the specification should say
that "An atom id SHOULD be a NewsML [Tag, or whatever] URN/URI" in order to
encourage that consistency.
	An alternative would be to provide a means by which a "native"
atom:id can be distinguished from one which is not native. This could be
done with an attribute as in:

	<id type="foreign">ISBN:97898709870</id>

Or, the rule could simply be that if an id did not conform to the native
Atom format, it should be treated as foreign. If NewsML or Tag was the
"native" format, Atom would prohibit foreign ids that started with either
"urn:newsml:" or "tag:" and declare that any id that did not start with
those characters was to be considered "foreign" and thus treated differently
from a native id. For a native id, a duplicate detecting algorithm might
trust the combination of atom:id and atom:updated (or some similar date) to
determine uniqueness. With a foreign id, one might also do textual analysis
when determining uniqueness.

		bob wyman

---

From: Elias Torres <[email-masked]>
Date: Tue, 27 Jul 2004 11:10:00 -0400

My group in IBM has been helping many organizations with large amounts
of data migrate to an LSID identification scheme and this has not been
a problem. If we are going to recommend atom:id must be of a specific
format, then we should.

For example, let's say I have several wordpress databases, one for
each blog. Wordpress only uses an integer for the id of the entry.
Then what we always do is create a mapping to the new ids w/o having
to change their existing structure (columns). Again, this is only
works in the case where the id cannot change (opposed to date columns
in blog dbs).

urn:lsid:torrez.us:blog:1 where blog maps to mySQL db torrez_wp and
row with ID 1.

Now let's say somebody already is using a NewsML identifier or
another. The fact is that most identifiers have within their
environment a unique id.  For example:

urn:newsml:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L06156584:1U

would get translated to:

urn:lsid[*]:reuters.com:20000206:IIMFFH05643_2000-02-06_17-54-01_L06156584:1U

Then, if they wanted to keep their newsml urn they would store as
extra data under their own namespace or a common extension namespace
for that matter. Because they need to know what that entry maps to in
their existing systems, unless they can derive the same thing from the
LSID for example. Most likely News dbs don't store the whole urn as
their id in the db. The urn is generated from an internal private key.

The point is that if we are going to the whole trouble of discussing a
scheme for IDs, let really solve the problem so everyone can
cross-link "Atom" feeds uniformly and can get more information from
the id than just a strcmp() result and get stuff like resolving for
example.

[*] or whatever scheme the group decides.

Elias Torres

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 28 Jul 2004 08:32:05 +0200

On 26 Jul 2004 13:25:39 -0500, Ken MacLeod <[email-masked]> wrote:

> [...]
> [...]
> [...]

Great, Ken. Such tests will make it easier for developers to understand  
what atom:id must conform to.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 28 Jul 2004 08:35:57 +0200

> encourage progress on tag adoption.

Definately. But another thing: Would it be possible to request a minor  
feature request for tag URI's? It would be great if the URI scheme we  
chose as atom:id's recommended scheme, supported revisions, like NewsML  
URN's.

---

From: Norman Walsh <[email-masked]>
Date: Wed, 28 Jul 2004 14:26:57 -0400

/ Tim Bray <[email-masked]> was heard to say:
| BTW, with specific reference to urn:newsml:, I think it's a sensible
| and well-designed URN namespace, but I think you're going to have
| trouble getting past the problem that leaps to my eye when I read the
| RFC3085 abstract:
|    "This document describes a URN (Uniform Resource Name) namespace for
|     identifying NewsML NewsItems.  A NewsItem is an information resource
|     that is expressible as a NewsML element within a NewsML document
|     conforming to the NewsML Document Type Declaration (DTD) as defined
|     by the International Press Telecommunications Council (IPTC)."

You might find RFC 3151 "A URN Namespace for Public Identifiers" a little
less troublesome along those lines.

Interestingly, I used such URNs as IDs for a while. You can still find them
in the everything feed, http://norman.walsh.name/atom/everything.xml
For example:

   <entry>
      <title>Dinner with Vermeer</title>
      <link rel="alternate" type="text/html"
            href="http://norman.walsh.name/2004/02/08/vermeer"/>
      <id>urn:publicid:%2B:IDN+norman.walsh.name:DOCUMENT+007,023</id>
      <issued>2004-04-01T04:22:00Z</issued>
      <modified>2004-04-01T13:35:54Z</modified>
      <dc:subject xmlns:dc="http://purl.org/dc/elements/1.1/">Theater</dc:subject>
      <dc:subject xmlns:dc="http://purl.org/dc/elements/1.1/">Reviews</dc:subject>
      <summary>On Friday and Saturday evening, Amherst Writers &amp;
Artists Press presented a theatrical fundraiser: dinner
accompanied by a series of tableaux
vivants of Vermeer paintings. [Update: there are now 35 known Vermeer paintings.]
</summary>
   </entry>

I have carefully preserved these identifiers even as I've reverted to HTTP URIs.
I now wonder if I'll feel inclined to re-revert. Hmm.

And, in the off chance that you want to retreive a representation of
the entry and you find that you only have the atom:id at hand, you
have only to include http://norman.walsh.name/catalog.xml in your XML
Catalog path and it'll resolve just fine. I'm just sayin'.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Extinction, n. The raw material out of
http://nwalsh.com/            | which theology created the future
                              | state.--Ambrose Bierce

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 13:51:33 -0700

> less troublesome along those lines.

And, since we're casting about in the space of registered URI schemes 
and URN namespaces:

I followed  http://www.iana.org/assignments/uri-schemes to RFC1738 to 
RFC1036, section 2.1.5.

    news:/ongoing/When/200x/2004/02/20/[email-masked]

Now, RFC1036 does "strongly discourage" the use of slashes.  But that 
aside, we have a perfectly legal URI in a registered scheme... No, I 
probably don't think this is a good idea, but it's no more obviously 
crazy than some of the others we've been offered. -Tim