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:]
> 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:]
> > 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:]
> > > 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
>
