[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] GlobalID (was RE: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-21)
How does using a persistent XRI for a
providerID relate to having private roots? From: Drummond Reed
[mailto:drummond.reed@cordance.net] Markus, see [=Drummond] inline. From: markus.sabadello@gmail.com
[mailto:markus.sabadello@gmail.com] On Behalf
Of Markus Sabadello On 7/9/07, Drummond
Reed <drummond.reed@cordance.net
> wrote: * Wil and Markus have both pointed out in
email that value of a GlobalID can be deduced from the value of a LocalID
element in all previous XRDs in the chain of resolution. However Drummond
pointed out that a GlobalID still adds information in that it selects a
specific subset of those LocalIDs to produce an absolute GlobalID. In most
cases this will be a subset of the LocalIDs in the resolution chain that are
persistent identifiers, vs. other LocalID values that may be reassignable.
[=Drummond]
The role of ProviderID is essentially to provide the CanonicalID for the XRD
provider (vs. the target resource). Any verified synonym of that ProviderID
will also work. See below. [=Drummond]
Not until now…;-) and not because it adds
extra information (you could really replace it with a LocalID, the resolver
must remember the previous ones anyway), but because it allows you to separate
the whole process into two steps: First you resolve your original XRI, along
the way you verify any GlobalIDs you find. And second, you resolve the
polyarchical CanonicalID, looking for a Ref or Backref to one of the (already
verified) GlobalIDs of your original XRI. [=Drummond]
Exactly right. It constrains the whole Canonical ID verification process
because with each XRD, all the resolver needs to do is: a) verify each asserted
GlobalID, if any (which MUST be hierachical, so it’s very efficient to
verify), and b) verify any asserted CanonicalID, if any (which, if it is
hierarchical, verifies just like a GlobalID, or if it is polyarchical, will
reference back exactly as you put it – to one of the (already verified)
GlobalIDs of your original XRI). [=Drummond]
I’m sorry I didn’t reply to that – I meant to but got
swamped. See below. Or if it was too
complicated, here is a short version: [=Drummond]
That idea was first promulgated by XRI TC representatives from Epok that
pointed to XRI namespaces and other places where URNs were already being used
as persistent identifiers for resources. If such an XRI authority already has a
URN, it might want to continue using it. However in ED03, I think we should: 1)
Strongly recommend use of a persistent XRI for XRI authorities. 2)
Further clarify in the new Self-Description section (the section that will
define how you can get a self-describing XRD from any XRI authority, including
a community root authority) that ProviderID is synonymous with any verified
GlobalID, CanonicalID, Ref, or Backref in a self-description XRD. That way even
if an XRI authority wants to use a URN as a ProviderID, a resolver can
determine its XRI synonym on which other GlobalIDs can be rooted.
[=Drummond]
Good question. Since URLs do not have an authority chain, other than fragments
(for which the fragmentless URL is authoritative), they are “flat”.
So the ProviderID would be the same as the original URL. That’s another
big difference between XRIs and URLs. [=Drummond]
Hope this helps. Keep asking these great questions! =Drummond
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]