[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Resolutions
Thanks Nick, Yes it is a slippery topic for the TAG in general. I have had the most success with them describing it in terms of "Cooler XRI" All XRI bound to http are "Cool URI". In the proposal they will always return 303 redirects to resources and never the resource itself. They will contain link headers in a manner consistent with Mark Nottingham's proposals for XRDS-Simple/XRD. They can use accept headers to choose between a number of possible 303 redirects for different representations of the "thing" identified by the XRI. The difference between a "Cool URI" and a "Cooler XRI" is that via sub schemes a shared semantic also exists like ARK. This allows http://xri.net/=Drummond to descibe the same thing as https://xri.net/=Drummond . They are separate URI and can be treated as such by applications. However XRI aware semantic web apps can discover the eqivelency by examining the meta data or via knowledge of the sub scheme. We however do need locators for the actual meta data files. The question is are these locators in the https: space as seperate URI distinguished by query parameters. We have been considering http://xri.net/=drummond/?_xrd_r=application/xrds+xml to be a locator that returns a 200 response with a XRDS document. I am interested in knowing if you see a problem with that? John Bradley =jbradley On 6-Nov-08, at 11:50 PM, Nick Nicholas wrote: > Having now caught up on the W3C TAG list discussions: > > You know this, but I'll restate the obvious. After reading the > emails, particularly http://lists.w3.org/Archives/Public/www-tag/2008Oct/0104.html > and follow up: > > People will keep assuming that because http://xri.net/=drummond can > resolve to an XRDS, http://xri.net/=drummond is an identifier for an > XRDS. Jonathan Rees clearly thought so. > > Do not allow this. And do not distinguish between http://xri.net/=drummond > and http://xri.net/=drummond/?_xrd_r=application/xrds+xml , or > http://*.xri.net/=drummond and http://thing-described-by.org/xri/=drummond > . =drummond, and http://xri.net/=drummond, both identify Drummond > the Abstract Thing (the human being, in fact; Abstract really means > Not Necessarily Digital). http://xri.net/... is also a service that > gets back a description of Drummond. http://xri.net/=drummond/?_xrd_r=application/xrds+xml > is a more refined service call, to get a particular kind of > description. > > But Neither Service Call Identifies Drummond. If we say they do, > we're back at the mess we started with. That's the inherent problem > in using an identifier, URI, which is intrinsically also a service > call. All we can do with this is, always return 303s in XRI > resolution calls ("what you are getting Is Not Drummond. It's a > description of Drummond"). That doesn't change whether we specify > XRDS as a parameter or not. And maybe, push the XRDS-Location header > more in examples (if not implementations). Because that XRDS- > Location URL *is* the identifier for the descriptor. > > Pointing to the equivalence of, say, HTTP HEAD http://thing-described-by.org/info:xri:=drummond > and HTTP HEAD http://xri.net/=drummond might not be such a bad > thing rhetorically: it makes more clear the distinction between > resolution and identification, and that the XRI resolution binding > is not a retrieval of a resource named in the URL --- just as thing- > described-by.org is clearly not. > > Again, I know you know this, but it'll be a lot of work to make sure > URL-heads get it too. > > ^ > ^ > ^ > ^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Dr Nick Nicholas; Link Affiliates, opoudjis@optushome.com.au > Melbourne skype:opoudjis http://www.opoudjis.net > "Despite millions of dollars of research, death continues to be this > nation's number one killer." --- Henry Gibson, Kentucky Fried > Movie. > __________________________________________________________________________ > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]