[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: GlobalID (was RE: [xri] Minutes:Joint XRI & XDI TC Telecon Thursday 2007-06-21)
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]