[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] resolution of an xri from browser, keep in browser or seperate?
Brian, Sounds excellent. Feel free to use both this and the XDI lists to ping us for more info on either topic. Best, =Drummond -----Original Message----- From: Bryan Rasmussen [mailto:brs@itst.dk] Sent: Monday, January 10, 2005 1:27 AM To: 'Drummond Reed' Cc: xri@lists.oasis-open.org Subject: SV: [xri] resolution of an xri from browser, keep in browser or seperate? Hi We also had some discussion of this over the holidays, off-list as i didn't have access to my work email account or my info for this list. Basically there are three ways to do protocol resolution in browsers, these are: 1. write code specific to the browser, thus you need to have a plugin for i.e. a plugin for mozilla, for opera, etc. 2. use asynchronous pluggable protocols to start a new application, this is basically a registry hack which opens a new application from the command line and passes it info, useful, but problematic in that one loses connection between the application and the browser - the application does not know what browser started it. 3. use asynchronous pluggable protocol to reroute the xri request to a local web service for resolution, this allows you to keep it in context, an installer could be written that makes sure that xri gets bound to your default browser. This is what I started, I basically got the right settings to do redirection in firefox, opera, mozilla, and ie, I didn't do much on the resolution service yet because there are for me i'm still not sure which way I should go on display, user interaction etc. your XDI suggestion is actually more along the line of what I've been considering. -----Oprindelig meddelelse----- Fra: Drummond Reed [mailto:drummond.reed@cordance.net] Sendt: 10. januar 2005 07:17 Til: 'Wachob, Gabe'; Bryan Rasmussen; xri@lists.oasis-open.org Emne: RE: [xri] resolution of an xri from browser, keep in browser or seperate? Brian, I was in already in holiday mode when your original question came in, but I just got back to reviewing it and I'd like to amplify on Gabe's response with another view of how XRI-identified-resource interaction might work w/in the browser (plus a key question it raises for XRI 2.0 resolution that I'm sending in a separate email.) [Disclaimer about the following - I'm co-chair of the OASIS XDI TC, http://www.oasis-open.org/committees/xdi, so put all of this in that context ;-)]. The view is that the option Gabe articulates of having a standard way to get more information about/interact with an XRI-identified resource could be SO useful that this is one of the key goals of the OASIS XDI (XRI Data Interchange) TC. The XDI TC is defining a way of using XRIs to identify and exchange metadata and data related to an XRI-identified resource including, if needed, negotiation of access to controlled resources using "link contracts". This means that the XDI perspective, Gabe's suggestion would be implemented through another service associated with the XRI-identified resource (probably called, naturally enough, "XDI" instead of "X2R".) The browser plug-in that supported XDI would see if the XRI-identified resource supported XDI, and if so, it could use XDI to request almost any kind of metadata about the resource, which would always be returned as an XDI document (meaning an XML document navigable using XRIs by an XDI processor). Let me know if you'd like more information about the work of the XDI TC (or feel free to join it as an observer - see http://www.oasis-open.org/committees/xdi). Best, =Drummond http://public.xdi.org/=Drummond.Reed -----Original Message----- From: Wachob, Gabe [mailto:gwachob@visa.com] Sent: Thursday, December 23, 2004 9:53 AM To: Bryan Rasmussen; xri@lists.oasis-open.org Subject: RE: [xri] resolution of an xri from browser, keep in browser or seperate? Thats a good question. Its not clear to me that there is one thing you'd do with XRIs within the context of a browser. XRIs identify resources, they don't imply specific application behavior. In fact, the same can be said of http or mailto URIs, except that everyone (except those nutty semantic web guys ;-) use HTTP and MAILTO uris in the same way, so there are standard behaviors associated with them. As for XRIs, I'd propose, as a first cut, that the browser could look for a a X2R local access service associated with the XRI's identifier authority. (X2R is the default local access service defined in the spec). The browser could perform an HTTP get to that X2R local access endpoint (X2R is really just the base HTTP semantics applied to an XRI resource). The return result would be a document displayable in a browser with further XRI or HTML links to other documents or resources. RDDL is an an extension to XHTML that does exactly this (http://www.rddl.org), allowing machine-readable markup embedded in the XHTML so that the same document can be consumed both by humans through a browswer and by machines using RDDL-aware parsing. This is something that doesn't neccesarily need formalization. I'd propose someone write a plugin for the major browsers and see how it works and how popular it is... good ideas tend to evolve and are rarely the product of instaneous genius. XRI being a good example ;-) -Gabe __________________________________________________ gwachob@visa.com Chief Systems Architect Technology Strategies and Standards Visa International Phone: +1.650.432.3696 Fax: +1.650.554.6817 > -----Original Message----- > From: Bryan Rasmussen [mailto:brs@itst.dk] > Sent: Thursday, December 23, 2004 1:56 AM > To: xri@lists.oasis-open.org > Subject: [xri] resolution of an xri from browser, keep in browser or > seperate? > > > > Hi, > > I'm just canvassing opinions here, how doe people generally > envision XRI > resolution working, if an xri request is made in the browser, do they > envision that request working within the browser. or do they > envision it > starting an xri application that gives the important > information to the > user. > > If the first that can of course be beneficial in that the > user has something > they're accustomed to. But the drawback is a browser constrained > application. If on the other hand xri launches an xri > specific application > that application can be called from any browser. For ease of > development (in > windows environment) I've found that the second model works > better. But I > suspect that users will find the flow of the first model more to their > liking. > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/xri/members/leave > _workgroup.php. > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]