RE: Issue 5 and "webarch"

This is getting nitty-gritty.

What the WSA is talking about are URIs as opposed to URLs. So a URI makes
individual names distinct but does not make the information retrievable, it
does not necessarily associate a location with it.

They are also talking about important resources. You could have a tree of
resources where the root of the tree is an important resource identified by
its own URI (e.g. the accounting system) and the leafs are specific
resources identified by a name in that namespace. The actual name of a
resource is a combination of that URI and its local name.

So back to our getStockQuote example, the resource (expedient; device;
asset - OED) would be accounting related resources designated by the URI
http://www.company.com/accounting, which is not a URL. The name of an
operation to retrieve an invoice would be qualified by that URI
{http://www.mycompany.com/accounting}getInvoice. And the service to which
you would post this request would be identified by a URL
http://accounting.mycompany.com/service.

Such a composition is consistent with Namespaces in XML and the statement
made in the WS Architecture document.

Claiming that the architecture document refers to an invoice as important
resource and mixes URIs with URLs is a bit of a strech in my mind. At least
I don't see how the WSA supports Mark's thesis that every bit of information
should be exposed by a URL that you can simply fetch with an HTTP GET.

arkin


> With respect to URIs, isn't it true that namespace URIs can
> qualify multiple resources?  Of do I misunderstand namespaces?
>
> Thanks,
>
> Eric
>
> -----Original Message-----
> From: Champion, Mike
> Sent: Saturday, January 04, 2003 8:06 PM
> To: www-ws-arch@w3.org
> Subject: RE: Issue 5 and "webarch"
>
>
>
>
>
> > -----Original Message-----
> > From: Mark Baker [mailto:distobj@acm.org]
> > Sent: Thursday, January 02, 2003 7:51 PM
> > To: Anne Thomas Manes
> > Cc: www-ws-arch@w3.org
> > Subject: Issue 5 and "webarch"
>
>
> > But, independantly of whether you buy the argument that
> > GET-of-a-URI is
> > a superior data retrieval mechanism than
> > getInvoice()-over-POST, I would
> > like to point out that according to the TAG's latest Web architecture
> > draft, to do things in a Web architecture compatible way
> > requires using
> > the former (ala issue 5).
> >
> > From the draft;
> >
> > "All important resources should have a URI"
> >  -- http://www.w3.org/TR/webarch/#pr-use-uri
>
> My sense of the WSA WG is that we've been getting more and more
> comfortable
> with what I think is a fundamental reality that your analysis
> seems to skip
> over: "Web services" certainly intersect with "the Web" but goes
> beyond it.
> [I mean the Web as we know it with universally dereferenceable
> URIs, not the
> abstraction of anything that can be identified with some URI yet
> may or may
> not actually "exist" in the sense of having a retrieveable
> representation].
> There are plenty of "Web services" that operate over multiple protocols
> (e.g. an HTTP gateway to a proprietary MOM system that triggers a  program
> on a mainframe) or behind firewalls where arbitrary URIs can't be
> referenced.  Like it or not, we have to consider the requirements of those
> systems as well as the more REST-friendly cases of SOAP over HTTP on the
> public Internet. As best I can tell from day job experience and
> reading the
> trade press, these may well be the majority of Web services actually
> deployed now.
>
> I (personally) have no trouble with the principle that "all important
> resources should have a URI."  I have a lot of trouble with the assumption
> that all web services can dereference one of these URIs can get back a
> meaningful representation of the resource it identifies in a sufficiently
> fast and secure manner so as to be useful.
>
> I feel confident that the W3C AC and membership have given us the latitude
> to see the world this way, and I'm (speaking SOLELY for myself) confident
> that the TAG will see the practicality of this perspective if and
> when they
> choose to review our work.  In the meantime, I'm working on the assumption
> that we will be explaining how the WSA intersects with the Webarch, not
> working from the presupposition that the WSA is a subset of the Webarch.
>

Received on Sunday, 5 January 2003 15:34:37 UTC