Roy,
On 2006 Apr 19 , at 17.26, Roy Williams wrote:
> ivo://nvo.caltech/VOEventRepo
> can be looked up in any VO registry, returning a description of the
> repository, such as who runs it, how many events it has, what is
> the service endpoint so it can be used.
>
> ivo://nvo.caltech/VOEventRepo#60601
> points to a specific VOEvent (number 60601) that is known to the
> Caltech VOEvent repository, but is not known to the VO registry.
These two situations should look the same to the registry/server.
In both cases, ivo://nvo.caltech/VOEventRepo is the *resource* which may be retrieved from the server; in the second case, the *client* will attach meaning to fragment 60601, and (in this case) find the VOEvent with that number within the full resource. That is, the URI spec intends fragments to be interpreted by the client, not the server, and fragments should not be present in queries.
Quoth RFC3986, section 3.5:
It's the client that dereferences the fragment: ``the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme.''
This isn't optional: ``Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications.''
Pace Guy and Ray, I don't think that to object thus is to quibble. Using a fragment like this is a failure waiting to happen!
As Guy suggests, using query would fit with the URI design:
[Section 3.4] ``The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).''
Thus <ivo://nvo.caltech/VOEventRepo?60601> identifies resource 60601 in an unimpeachable fashion (but then, so would <ivo://nvo.caltech/ VOEventRepo/60601>)
All the best,
Norman
-- ------------------------------------------------------------------------ ---- Norman Gray / http://nxg.me.uk eurovotech.org / University of Leicester, UKReceived on 2006-04-20Z20:21:39