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
