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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: RE: [xri] RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)


Title: RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)

Bill,

 

I agree with Gabe here wrt your second question – other specs (specifically XDI) can define how an XRI might be used to request/address specific types or instances of metadata, but that this is out of scope for XRI resolution.

 

That's why I like the basic interaction pattern of resolving an XRI to get an XRID to discover one or more network endpoints for requesting additional metadata describing a resource. Then one of those endpoint types can be a service like XDI.

 

=Drummond

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Wednesday, November 02, 2005 10:19 AM
To: Barnhill William; Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)

 

Bill-

 

Thanks for asking these questions!

 

BUT *I'M* getting confused. There's a lot here that I don't think the XRI TC needs to speak to.

 

I think generally the answer is that you can do all of the things you propose, Bill, and we (the XRI TC) shouldn't really care.

  May not be desirable even if possible, as if an XRI authority is strictly designed to signify an extensible and re-assignable name for a network endpoint (aka network location), then it doesn't signify the data about the resource at that network location, right?  

Well, I thought the pushback to my reconceptualization was (well, Drummond agreed, at least) that an XRI authority can identify *anything* (in essence, an XRI authority is just a degenerate XRI in that sense). It resolves into an XRID that describes possibly the resource identified by the authority, as well as services (such as authority subsegment resolution) hosted on behalf of that authority by some network endpoint. So Drummond's response to you confuses me since it seems to be more in line with my reconceptualization than the pushback.

 

I actually don't care too much at this point - we need to decide and move on.

 

I don't know if this answers your question about "Does there currently exist a method for an XRI that links into the containing document?" Can you explain this question in more detail?

 

Consider an XRID with some RDF metadata about the XRID itself embedded somewhere within the XRID (dc:author for example). If I want an XRI that can access that data I either need to know beforehand how that data is stored within the XRI and parse it out when I get the XRID (doable, but basically hard coded), or I need an XRI authority subsegment or XRI local path + inline resolution spec, that can reference this embedded data, for example xri://@foo*bar/(+about). Using the XRI method I don't care whether the data is embedded, or at some network endpoint,right? So that would seem the best bet, but is that (1) allowable, (2) possible within current bounds of specs. 

 

I think all of this is out of scope of the XRI resolution spec. I think people will use XRIs in different ways and we'll find out with use what works best. In fact, the XDI TC is proposing one way to use XRIs that answers many of these questions and I think other efforts at the same layer of XDI will be seen. 

 

<cliches>

Let a thousand flowers bloom. Throw some spaghetti on the wall and see what sticks. Survival of the fittest. Only the strong survive.  Veni vidi vici.

</cliches>

 

I wish I could always make my point by throwing out a list of cliches...

 

   -Gabe

 

 



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