Re: [xri] FW: For Tuesday (More about top-down XRD stuff)

Steve asked me to skype him Tuesday morning at 7am before the regular XRI call to discuss his concerns around the changes to XRD schema and XRI resolution.

The primary use for the XRD that Eran has in his first draft is for the URI entity space.

For the people who have been following that the definition of an entity space for URI is much slipperier that perhaps they originally thought.

For XRI we do have the advantage of a much cleaner entity model. As we look at XRI resolution and entity descriptors Steve is correct that we do need to keep in mind that XRI themselves are always abstract identifiers and will have some differences when it comes to describing relationships with other entities.

We are just starting the work on the new XRD format and I don't myself have any real concerns that we cant use the same XRD format for both descriptors.

One of the reasons I have been so interested in 303 and 404 http responses is because those along with URI fragments are the closest thing HTTP has to the XRI descriptor.

The semantics of a XRD with a abstract URI as a subject/CID should be similar to those when a XRI is the subject.

The semantics of an XRD when it's subject is a URI that represents an information resource as is the case with oAuth and other use cases gets more complicated once you go down the rat hole of trying to have multiple XRD's to represent different possible response codes. As these issues get resolved on the URI side I expect the resulting entity models to become more similar in many respects.

At this point however I don't think the HTTP entity model is 100% nailed down.

On 8-Feb-09, at 1:00 AM, Steven Churchill wrote:

FYI:

From: Steven Churchill [mailto:steven.churchill@ootao.com]
Sent: Saturday, February 07, 2009 7:24 PM
To: 'John Bradley'
Subject: For Tuesday

John,

Here’s what I have in mind for Tuesday:

The problem is that the XRI TC is still trying to define the entity discriptor format (the new XRD) outside the context of its overall entity discovery framework.

As I said in my last email to the TC (a few months ago), an entity discovery frameork has:

1.       Entity space
Entities have:
a) “Generic” characteristics. These are the characteristics that are obtained using the service access rules. In other words, an entity’s generic characteristics can be anything we want because we formalize how to get them via service type and URI. (The entitys’ generic characteristics are extensible.) Good design!

b) Structural characteristics. Hierarchical children; poyarchical references, and so forth.

2.       Discovery function
Input: identifier (and perhaps plus other stuff)
Output: entity descriptor (and perhaps other stuff)

In XRI this devined by “XRI resolution”
3.       Identitfier fomat
In XRI, this is, well, an XRI.
4.       Entity Descriptor format
Returned by the discovery function and used to access structural and/or generic characteristics (via indirection.)

John, as I mentioned above, for the new XRD, the TC is trying to define (4) without properly considering 1-3. For example, from a purely abstract standpoint, what should 4 contain? It should contain:

·         The “generic characteristics” -- or more specifically, how to get to them using the service access rules.
·         Structural characteristics. In XRI, the direct hierarchical children can be obtained indirectly via an authority service. [[N.B: Note in XRI how it’s silly to bury this structural characteristic inside the service access stuff. Gratuitous overloading again.]]
The polyarchical references (Refs) and disguinshable identifier (CID) are both structural characteristics.
·         Bookkeeping stuff needed by the discovery function. In XRI, this includes <Query>, sigs, nested XRDS for auditing, etc.
That’s pretty much it.

So let’s talk Tuesday about the new XRD as an entity descriptor – but from the context of it’s items (1) and (2) above (that is, from the context of it’s entity discovery framework.)

The bottom line is that I don’t think anyone really understands either the entity space or the discovery function, and without those, the TC really should not try to define the descriptor format.

Gracias,

~ Steve

xri message