|
Interesting - I didn't remember that we had defined
authority. The reason I was backing away was because Dave McAlpin asserted that
the XRID was an authority. Clearly thats in conflict with the definition
here.
Are you suggesting
that this definition needs to be changed in any way?
Not really. I think Dave was
suggesting this though. I still suggest, as much as possible, we not talk about
authority even if we did let that definition in the syntax doc.
For what it's worth,
I've had the following conceptual model about XRIs, resources, authorities,
and XRIDs:
* An XRI (Extensible
Resource Identifier) identifies a resource.
Yes, we all agree here. I
hope!
The *issue* is about whether the
authority segment, as separate from the path, identifies something different
than the XRI containing that authority segments plus an empty path segment.
To wit: Does @foo*bar identify
something different than the XRI xri://@foo*bar
In the conceptual model I had been
working against, the answer is yes, because @foo*bar was identifying an
authority, which by definition is not a dog, a person, a cat or a house. This
doesn't mean that @foo*bar can't be used in a the form of a complete XRI (e.g.
xri://@foo*bar/) to identify anything (e.g. dog, person, house). It just means
that there has to be a path (perhaps empty) to suggest that the authority can be
asked about the resource identified by the *full* XRI (not just the authority).
The reconceptualization was to say
that @foo*bar now identifies a resource that may host a authority subsegment
resolution service (perhaps) or X2R (or other services) *AND* can be a
house, dog, cat, etc. So there's a duality of meaning here which is odd, but is
the only way I understand other people to understand XRIs, and in practice isn't
too much of a problem on the wire.
* An
XRI may be resolvable into an XRID (an XML document) that describes the
resource identified by the XRI.
It has always been true that an XRI
could be "resolved" into an XRID. We just never specified how to get an
XRID out of a complete XRI (with a path segment that may or may not be empty).
We only specified how to get XRIDs out of the authority
segment.
* The network
endpoint responsible for assigning an XRI to a resource and returning an XRID
describing that resource is the authority for both the XRI and the
corresponding XRID.
Here's where we get into trouble -
what is meant by "the authority". If xri://@foo*bar is an authority, then its
not a dog. Last time I checked, dogs couldn't answer XRI subsegment
resolution requests. But we can just sort of ignore that by saying that the
result of resolution describes the dog and services on the network that act as a
proxy for the dog on the network. In the new conceptualization,
we are saying that resolution of @foo*bar gets back both descriptions of the
resource and network services offered on behalf of (or "relative to"?) that dog.
* One function of
XRIDs is to tell XRI resolvers how to further resolve an XRI. By the above
definition, this applies both to the resolution of authority subsegments
within the authority part of an XRI, and resolution of the local part of the
XRI. In other words, XRI resolution is the complete set of steps that may be
necessary to resolve an absolute abstract XRI into an absolute concrete URI
which can then be resolved via DNS, IP, or other means.
This seems to differ from Dave
McAlpin's assertion that resolution gets you back a descriptor document that can
contain any metadata -- i.e. no need to result in any concrete URI. I'm
surprised that this surprises you - I thought this was your position too.
-Gabe
|