Hi Bob,

Those are my >>s so I'll respond. Below I'm talking about the stuff in section 13.3 of the spec. Primarily page 27.

Dave

Rich

No reading I can make of http://www.omg.org/cgi-bin/doc?dtc/2004-05-01 is consistent with the explanation offered below. "Authority" is not used at all in Section 9, "LSID Resolution Service". Instead, resolution is defined to be accomplished by a set of interfaces all of which take only a full (semantically opaque!!!! Sec. 8, p. 7!!!) LSID as argument. The interfaces correspond to methods offered by an LSID Resolution Service. Nowhere in Section 9 is there any relationship mentioned between resolution and the "authority identification" that is part of the syntax of an LSID. That is discussed in Section 8, "LSID Syntax" which carries the sentences (bottom of p. 7) that I have previously cited: "The authority identification is usually an Internet domain name. In this case it is recommended that it be owned by the organization that assigns an LSID in question".

There are too many ">"s for me to understand who is claiming the stuff below, but whoever it is could do me a favor by telling me which part of the spec they are reading. (Or if they found a later document at OMG). Well, OK, I haven't yet read the "Accompanied Files" listed in Appendix A., some of which are normative and take precedence over the main document. Maybe the explanation comes from one of them.

Richard Pyle wrote:

...

Many thanks for jumping in on this, Dave!

...

As I think Dave V. and others have pointed out, when an LSID is resolved, DNS is used to find the LSID authority. The LSID authority then provides information about how the LSID can be served up (e.g. HTTP, SOAP, FTP), and where to get the data behind the LSID and associated metadata. If I start serving up LSIDs with the authority learningsite.com and later decide that I'm sick of serving up LSIDs, somebody else can take over serving up the data and the metadata. However, I (or they) still bear the responsibility of running the authority which points to the data. If my lsids have an authority like lsid.learningsite.com (urn:lsid:lsid.learningsite.com:foo:bar) then someone else can take over the authority by taking over lsid.learningsite.com and I can still have www.learningsite.com, mail.learningsite.com, etc... for myself. So, with a little planning, it's not so hard to deal with an authority going away as long as the people running it are responsible.