OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Namespace delegation (was: Re: [xdi] Minutes: XDI TC Telecon Friday 2013-04-19)

[renaming thread to reflect the new topic]

Les, your point about "you can't have simple namespace delegation" anymore is the reason Markus and I spent an hour talking about it.

In DNS and other distributed naming services, that's just what you have: federated namespaces via delegation. And that's what we were initially trying to emulate with XRI architecture, just adding the semantics (and syntax) to distinguish between mutable (reassignable) and immutable (persistent) identifiers.

But what we found was that that wasn't enough benefit to justify the additional complexity.

With XDI addresses, we're moving to semantic addressing -- an address that communicates semantics about the resource you are addressing.

The thesis is that semantic addressing, paired with a semantic data interchange format and protocol will provide enough breakthrough benefits to drive adoption.

Semantic addressing still supports federated namespace delegation. But it means that an address is not just a string of delegated name. The names carry semantics. For example, in @neustar[+employee]*les, you know that @neustar is a globally unique singleton name for an instance of a group (in this case a company). You know that +employee is a class of resource available in the @neustar context. And you know that *les is the name of an instance of the employee class.

Markus and I explored whether we should introduce a new type of context symbol expressly for delegated naming, i.e., to emulate the way DNS and other federated haming systems work. Our conclusion was that this would:
  1. Complicate the XDI model without significantly adding value.
  2. Detract from the value of semantic addressing, because it would be intentionally stripping away the semantics.
So our conclusion was that XDI should stick to what it does best (and what to our knowledge it does uniquely), which is federated semantic naming. 



On Mon, Apr 22, 2013 at 4:07 PM, Chasen, Les <les.chasen@neustar.biz> wrote:
Wow … you can't have simple namespace delegation anymore?  

From: Drummond Reed <drummond.reed@xdi.org>
Date: Monday, April 22, 2013 5:32 PM
To: Markus Sabadello <markus.sabadello@xdi.org>
Cc: OASIS - XDI TC <xdi@lists.oasis-open.org>, Phil Windley <pjw@kynetx.com>
Subject: Re: [xdi] Minutes: XDI TC Telecon Friday 2013-04-19

- Community names such as =neustar*les don't work anymore, because the instance *les can't follow the singleton =neustar. Do you have any idea on how to solve this?

Markus and I talked about this for nearly an hour. The bottom line is that to be consistent with the full XDI graph model, *names and !numbers need to behave consistently as instances, which means they only follow a class (in square brackets). So it means that community names need to specify the class before the instance, e.g., =neustar[+employee]*les. Or they can use a cross-reference such as =neustar=(les). Or, for a pure name registry, it would be an instance of the mutable ID class, e.g., =neustar[*]*les. (Ugly but semantically consistent.)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]