RE: Issue 5 and "webarch"

Importance is in the eye of the resource owner.  If somebody wants to make a
representation of a resource globally available, they give it a URI.  If
they want to globally identify it, they give it a URI.  Your interpretation
of important may be quite different than other peoples interpretation.  And
the only definition of important that globally fits of when is a resource
important is "A resource is important when it needs a URI".

The TAG never said what classifies as "important"?  You see, it's a circular
argument.  When is a resource important?  Well, when somebody needs to use
an identifier for it.  voila.  Important resources are defined by those that
have URIs.

Also notice that the definition of Resource and URI are circular too.  A URI
is a Resource Identifier.  What's a Resource?  Something that has an
Identifier.  What's an Important Resource?  One with an Identifier.

I argue that in actuality, the TAG document provides little guidance on when
to use URIs versus not, except for the inconclusive and
context/app-dependent word "important".

Now to be clear, just about every darned ws-spec that I work on uses URIs
for identifying things.  But that doesn't mean that I think that every
single application should be constrained in this.  If some app wants to make
POs globablly identifiable and maybe dereferencable, they have no better
construct than a URI for doing so.  BUT that doesn't mean that I would EVER
want to say "All POs should be identified by URIs".  I believe in giving the
app developer the freedom to choose based upon their needs.  That's also why
the word "SHOULD" and not "MUST" appears in the TAG doc.

While theoretically possible, I don't see the rationale that says that EVERY
identifier and/or location/address in EVERY app should use URIs.

What I want to do is avoid the knee-jerk claim that everything should have a
URI.

I still think it is VERY telling that people regularly assume that the
parameters that people see in URIs, like "?id=500", are part of HTTP, when
in actuality they are defined as part of HTML.  Clearly people were thinking
that parameters were HTML specific and not scheme specific.  That is,
parameters are part of the language being exchanged and not part of the
scheme used to identify the resource.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Baker
> Sent: Thursday, January 02, 2003 4:51 PM
> To: Anne Thomas Manes
> Cc: www-ws-arch@w3.org
> Subject: Issue 5 and "webarch"
>
>
>
> I just wanted to reply to this in order to tie into the TAG's webarch
> document.
>
> On Tue, Dec 31, 2002 at 03:49:32PM -0500, Anne Thomas Manes wrote:
> > The difference is that in the first case
> > > GET <some-uri> returning some machine-processable XML document
> >
> > you have a URI that refers to the specific invoice
> instance. (which assumes
> > that the client has received this invoice URI somewhere
> along the line)
>
> Right.  That's the same with the non-URI identifier too
> though; that the
> client has received the invoice number somewhere along the line.  And
> perhaps the client even discovered them the same way, say in another
> document, ala;
>
> <some-doc>
>   ...
>   <invoice>249827348237432</invoice>
>   ...
> </some-doc>
>
> versus
>
> <some-doc>
>   ...
>   <invoice>http://somecompany.example.org/9238d928jd298sdfi9</invoice>
>   ...
> </some-doc>
>
> 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
>
> and if we were developing an invoicing app, I can think of
> nothing more
> important than an invoice.  (though I'm sure we'll hear about DaveO's
> unique interpretation of "important" 8-)
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
>
>

Received on Sunday, 5 January 2003 17:43:39 UTC