[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] FW: For Tuesday (More about top-down XRD stuff)
John, It seems that the TC is interested in
factoring out some common properties used in different use cases (XRI
discovery, URI discovery, oAuth) and putting them in the XRD. That may be fine
and good from an HTTP infrastructure caching standpoint, but it won't work if
the use cases aren't understood because the common properties just won't be
useful to the use case (and if the needed properties aren’t in the cache,
then what good is the cache?) So Tuesday let’s look at this “URI
discovery” use case because that seems like one of the big three (if not
the biggest of the three.) Let's assume that there will be a
discovery function that takes a URI as input, maps it to an entity in some
entity space (URI entity space?) and then returns information about the entity
(the XRD.) So what I'm asking for is (1) what are the
characteristics of this URI entity space and (2) what specifically is the
behavior of the discovery function? One first needs to talk about the function
itself before trying to determine what parts of its output can be shared with
other use cases. ~ Steve From: John Bradley
[mailto:jbradley@mac.com] FYI 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. =jbradley On 8-Feb-09, at 1:00 AM, Steven Churchill wrote:
FYI: From: Steven Churchill [mailto:steven.churchill@ootao.com] 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 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.]] · 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]