SV: [xri] resolution of an xri from browser, keep in browser or seperate?

[Bryan Rasmussen <brs@itst.dk>]

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
.