[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] getResource question
Such a change would imply a Consumer could extract the wsrp-url parameter from the URL and send it as a resourceID to the producer. It is somewhat awkward to do so. A cleaner solution would be to change the ResourceParams struct to ResourceParams [O] ID resourceID [O] string url (language to say that this field is the wsrp-url parameter) ... and add a conformance statement that clarifies that the Consumer MUST supply one of these fields (but not both) depending on whether the Producer specified a wsrpUrl or a resourceID parameter in the URL. I also noticed that the Sec 10 is not clear if a resource URL can specify both a wsrp-url and a resourceID. We should further clarify that "If the resource is not URL-addressable, Consumers MUST/SHOULD use the resourceID parameter to specify an ID to retrive the resource. Producers MUST NOT specify both a wsrp-url parameter and a resourceID parameter in the same URL." Regards, Subbu Andre Kramer wrote: > Web browsers do in practice have a limit on the size of URLs which > argues for the max length. However, I now see your point and agree we > could make the type of the resource identifier xsd:string. > > Regards, > Andre > > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@bea.com] > Sent: 27 May 2005 16:19 > To: wsrp > Subject: Re: [wsrp] getResource question > > I thought about that possibility, but I don't think it is valid. WSRP > spec restricts IDs to be of less than 4096 chars (or less, depending on > how many bytes it takes to store a char), where as URLs have no such > restrictions in the spec. > > That's why I brought up the need for some persistence (atleast in > memory) for wsrpUrl <-> resourceID mapping. > > Regards, > > Subbu > > Andre Kramer wrote: > > I don't think we need to introduce a notion of some sort of persistent > > resourceID. The resourceID parameter is just a way to point to a > > resource and it should be perfectly legal (and normal) to use a URL > > string as a resourceID. From the point of view of the protocol and the > > consumer a resourceID is just a URI (a unique identifier for a > resource) > > - we do not describe or mandate the mapping mechanisms. > > > > Regards, > > Andre > > > > -----Original Message----- > > From: Subbu Allamaraju [mailto:subbu@bea.com] > > Sent: 27 May 2005 15:01 > > To: wsrp > > Subject: Re: [wsrp] getResource question > > > > Andre Kramer wrote: > > > Yes, URL-addressable resources need their addresses (URLs) mapped > into > > > the resourceID resourceParam. Remember that these (resourceIDs) > > > themselves get put on URLs in the markup which is why I though it > > > clearer as well as more general to not make them explicitly URLs or > > even > > > URIs (even though these are likely to be the common cases). > > > > My main concern is that, a majority of resources are static and > > therefore are URL addressasble. Web servers and app servers don't help > > map static resources to resourceIDs. > > > > We can encourage non-URL addressable resources to use the notion of > > resourceID, but it is somewhat inconvenient to map static resources to > > resourceIDs. There is some cost to managing resourceIDs (perhaps > > persistently), and this discourages producers from supporting the > > getResource operation. > > > > I find that it is more natural for producers to use URLs for > > URL-adressable resources, and resourceIDs for other resources (such as > > some bank statement generated from user's query), and that the > > getResource should provide for both. > > > > Regards, > > > > Subbu > > > > > > > > > > > > Regards, > > > Andre > > > > > > PS. Wish we had WS Addressing endpoint references ... > > > > > > -----Original Message----- > > > From: Subbu Allamaraju [mailto:subbu@bea.com] > > > Sent: 26 May 2005 22:42 > > > To: wsrp > > > Subject: [wsrp] getResource question > > > > > > I've a question on the getResource operation. > > > > > > AFAIR, the primary use case for this operation was to allow > Producers > > to > > > > > > serve resources over SOAP instead of HTTP, which was not possible > with > > > WSRP1.0. > > > > > > But it is not clear how a WSRP2.0 producer can serve > URL-addressable > > > resources via the getResource operation without somehow mapping > those > > > addresses into resourceIDs. > > > > > > My question is, why is not there a wsrpUrl parameter in the > > > ResourceParams structure? The lack of such a parameter may impact > the > > > motivation for supporting this operation in producer/consumer > > > implementations. > > > > > > Can someone clarify? > > > > > > Thanks > > > > > > Subbu > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this mail list, you must leave the OASIS TC > that > > > generates this mail. You may a link to this group and all your TCs > in > > > OASIS > > > at: > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and 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]