Re: WebArch Ambiguity about Objects, PLUS Suggested Major Replacement

Sandro Hawke wrote:
> The "mind trick" in object-oriented design is to conflate some
> "object" (which might be a person

Hm... the part of my brain that deals with using O-O classes to 
systematize building procedural logic is a different part than the one 
that writes text with <'s in it to describe instances of, well... 
anything.   So most of Sandro's prefatory arguments are lost on me.

> I think you mean something like:
> 
>   Owners of URIs, especially ones which may appear in a public
>   context, SHOULD make available representations [information] that
>   describe[s] the nature and purpose of those URIs.

This seems like an improvement, although the "[information]" is entirely 
unnecessary.

>>The Web is a universe of resources. 
> 
> This must mean data-structure objects.  The universe is a universe of
> problem-domain objects.  The web is about information about those
> problem-domain objects.

Er, no it needn't.  The universe is whatever it is.  Web architecture is 
a formalism that contains resources, identified by URIs, that you work 
with via representations; the architecture describes how you interchange 
representations.

>>A resource is defined by [RFC2396] to be anything that has
>>identity. Examples include documents, files, menu items, machines, and
>>services, as well as people, organizations, and concepts.
> 
> Obviously these are problem-domain objects.

I don't understand what you mean by "problem-domain object", and I don't 
think I should have to in order to write Web software.  Resources are 
things that have URIs and can be dereferenced to get representations. 
If it helps you in your applications to think of them as problem-domain 
objects that's fine, but not necessary.

>>One can append a fragment identifier to a URI to yield an identifier
>>for part of, or a view of, a resource
> 
> Now we're back to data-structure objects.  It makes perfect sense to
> talk about a view or fragment of a collection of information.

Sigh.  Webarch does *not* have its act together on fragments... this may 
be because the Web doesn't.

>>When one resource refers to another via a URI, a link is formed.
> 
> Sounds like a data-structure object containing a pointer to another
> data-structure object.

No, it's a URI embedded in a representation.  The system is 
self-contained and its definition includes everything you need to know 
to write the software.  The Web's notion of a link is qualitatively 
different from an object identifier in a bunch of ways that I shouldn't 
have to elaborate here, to start with two different users of the URI 
might get different representations, and quite properly so.

>>When many resources are linked this way, the large-scale effect is a
>>shared information space, where resources are identifiable by URI.
> 
> Sure, just like a program which has lots of objects in memory, all
> linked together.  A URI (or web address) is just like an object
> reference (which is really a memory address).

The Web is not at all like a set of linked in-memory data structures. 
Attempts to think of it that way lead to the implementation of broken 
software.

> I wish you didn't use the term URI for talking about both http URIs
> which clearly (IMHO) identify information repositories (data-structure
> resources) and for talking about strings like
> "mailto:nobody@example.org" and "urn:oasis:SAML:1.0" which can
> identify anything.  The term "URL" is almost right for the first
> group, but not quite.  I guess my favorite is "web address".  URI is
> okay for the second group, except that lots of people turn "URI" into
> "web address" in their head, because that's how it's usually used.
> How about "internet identification string"?   [ Just joking. ]

You're not the first to rail against the extreme generality of the 
URI/resource/representation formalism.  However, industrial software 
like you find in browsers and servers and caches and robots seems to 
work as the architecture says it should without any angst.

>      If something is important, there should be information about it
>      on the web.  If you're creating or defining something, especially
>      something conceptual and related to the web, you should pick a
>      web address where information about it can be maintained for as
>      long as the thing might be of interest.
> 
>      That web address can also be used to unambiguously identify the
>      thing itself: people can say things like "My data is in the
>      format defined at http://sample.org/format7."
> 
>      This secondary use of web addresses to identify things described
>      on the web can be very attractive to designers of protocols and
>      data formats.  Traditionally, designers have assigned names and
>      numbers to identify elements of their system.  If the system was
>      open, the assignments had to be managed through a public
>      institution like IANA or ISO, or they could use UUIDs.  URIs make
>      an excellent alternative because (1) they are cheap and easy to
>      obtain, and (2) they readily lead people (and even machines) to
>      more information.
> 
>      Designers should be careful, however, to distinguish between
>      places where a web address is used to directly identify a web
>      page and those where it is used in this indirect manner to
>      identify something described on the web page.  (This is true
>      regardless of the use of fragment identifiers in web addresses;
>      they simply involve a portion of a web page.)  

The language in the first paragraph is good, but the argument runs into 
trouble and falls apart.  At some point in time, I might want to name 
something with a http:-class URI and not have any representations for 
it; this works just fine in practice, there's a huge number of XML 
namespaces like this.  Later on, I might decide that providing some 
representations might be useful.  The existing architecture's 
agnosticism about the different kinds of URIs makes this trivially easy, 
but the proposal that URIs be sorted into the class that has 
representations and the class that doesn't really gets in the way. -Tim

Received on Friday, 3 January 2003 17:50:18 UTC