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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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

Subject: RE: [wsrp] Links in a WSRP service: what do they mean?

I agree with Sasha, 3 & 4, pose a problem, that could become very confusing.
The semantics of links is well known, and if we start to muck around with
them, we could be in trouble.  I am wondering if some sort of markup
designation couldnt help either the producer or consumer make the
determination of exactly what is required under the circumstances.  My
assumption for (2) is also that the producer returned specific markup ( eg.
$consumer$/resource.htm ), that allows the consumer to do the url rewritting
to the client, in such a way that the initial request is returned to the
consumer, for translation into the required producers url.  Is that a
correct assumption ?

-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Thursday, May 30, 2002 5:02 PM
To: WSRP (E-mail)
Subject: [wsrp] Links in a WSRP service: what do they mean?


I brought up a question yesterday in the markup subgroup call that I would
like to address to the whole group.  Basically, I think we need to have a
clear idea what it means to have a link in a markup fragment returned by a
WSRP service.

Let's say we have some WSRP service A which returns an (X)HTML markup
fragment that contains the text "<a
href='http://someserver/resource.htm'>link</a>".  What should clicking this
link do?  I see four possibilities:

(1)  link a user to http://someserver/resource.htm over straight,
traditional HTTP without any proxying by the portal.
	This seems like a good idea if the linked resource is a large static file
like an image.

(2)  link a user to http://someserver/resource.htm over straight,
traditional HTTP with proxying by the portal.
	In this scenario, the portal would proxy the request to the resource, but
it would not create a SOAP request.  This would be a good idea for large
static files like images in situations where network connectivity does not
allow the end user and the portlet server to talk directly.

(3)  link to WSRP service B at the URI http://someserver/resource.htm using
	This is useful if you want to delegate part of a WSRP service to another

(4)  link to the same WSRP service A at the same URI using SOAP but pass in
an argument of the form "linkClicked=http://someserver/resource.htm";
	This is useful if you want to stay in the same service and mimic URI links
at the same time.

I think there are use cases for all four of these possibilities, and I think
that they all make some sense.  However, I think that 3 & 4 are definitely
not what links are supposed to be used for in (X)HTML, WML, & VXML, and I'm
troubled by the idea that we might rewrite the semantics of markup tags with
well established meanings.  I would propose that we define different linking
mechanisms for cases (3) & (4) above through a different markup tag (e.g.
<wsrplink>), through a new URI scheme (e.g. <a href="wsrp:blah"></a>), or
through some other means.

Part of the problem here is that different resources returned by a single
WSRP service (e.g. a portlet page, a detail view, a help page, an image)
don't have actual different URIs, and so it is difficult to refer to them in
hyperlinks in a way that is consistent with prior standards.  I think this
is a major problem with the SOAP architecture we've chosen, and we should
think about what workarounds there are to solve it.  Any ideas?


To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC