Yes, for Higgins it's probably better to wait until the XRI TC and Neustar have moved to XRD.
The xri2xrd.net service isn't meant for systems that understand XRI/XDI/XRDS anyway. It's designed to provide compatibility with other systems that understand LRDD/XRD but don't know anything about XRI/XDI/XRDS. E.g. to fulfill SWAT0. Markus On Mon, Aug 9, 2010 at 3:24 PM, Paul Trevithick <[email protected]>wrote: > Markus, > > 1) I had thought now that XRD was stable that this was an opportunity for > Higgins to update its resolution code to use XRD instead of XRDS. > > 2) I had also thought that we could drop support for xri 2.0 syntax and > just (for simplicity) support xri 3.0. However after talking to Drummond > just now he reminded me that xri.net has not yet been updated to support > xri 3.0 syntax and thus it would be better to wait on this change. > > In fact if I understood Drummond he suggested it would be better to wait on > 1) AND 2) above and make all the changes at once in a few months when the > XRI TC had progressed and Neustar had upgraded. > > --Paul > > On Aug 8, 2010, at 3:09 AM, Markus Sabadello wrote: > > Yes, XRI Resolution has to be updated to support XRD instead of XRDS. > > In the meantime, there's a service that can resolve XRIs and map their XRDS > to an XRD. > Example: http://xri2xrd.net/=markus > > A standard LRDD resolver starting with > http://xri.net/=markus > should correctly discover the XRD for =markus. > > For Higgins, this means that the UDI resolver (higgins.idas.udi) could > probably be simplified to use LRDD for both XRIs and URIs, instead of using > XRI Resolution for the format and Yadis for the latter. > > Markus > > On Sat, Aug 7, 2010 at 9:25 PM, Paul Trevithick <[email protected]>wrote: > >> >> On Aug 6, 2010, at 2:50 PM, Drummond Reed wrote: >> >> >>> *1) UDIs not URNs* >>> >>> EntityIDs are supposed to be resource UDIs not URNs. So after we correct >>> that error in our XDI then the entityIDs will look like this: >>> >>> =mydex....@alice/$context$xdi+home+and+family//=alice >>> >> >>> Where >>> >>> - =mydex is the name of the PDS operator >>> - @alice is the community name assigned to alice by Mydex >>> >>> This is not correct. @alice is a global organization i-name. This should >> be *alice. >> >> >> Oops, of course! I knew that :-) >> >> >>> - $context indicates that we're looking for a "context" service >>> endpoint in the LDDR/XRD >>> - $xdi indicates that this entityID can be accessed over XDI >>> - +home+and+family is the id of the context >>> >>> It's been so long since I've worked with UDIs and UDI resolution that I >> can't answer this. Markus will have to. However service endpoint selection >> is no longer part of XRD (as opposed to XRDS), so I think there's going to >> be an issue here one way or another. >> >> >> The intent of the UDI term was not to invent anything new. The intent was >> to have a word that meant "either XRI resolution or Linked Data URI or <some >> other std discoverable reference>" >> >> So WRT XRI-UDIs our intent was to track whatever XRI resolution is defined >> to be per the latest thoughts of the XRI TC. It sounds like you're saying >> that the XRI resolution spex haven't been revised to work with XRD (as >> opposed to XRDS). Is that right? >> >> >> >> _______________________________________________ >> higgins-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >> >> > > > <ATT00001..c> > > > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
