From: rpa@netcom.com (Ramin Firoozye)
Message-Id: <9310281820.AA28064@netcom4.netcom.com>
Subject: Thumbnail Sketch of the UR* Arena
To: uri@bunyip.com (URI Mailing List)
Date: Thu, 28 Oct 93 11:20:39 PDT
>
> From: Karen R. Sollins <sollins@lcs.mit.edu>
> Subject: Thumbnail Sketch of the UR* Arena
>
> ...
> 1) a name that identifies it.
> ...
> 2) a locator, or many.
> ...
> 3) characteristics.
> ...
>
This sure is one topic begging for summarization efforts like this.
I'm having a heck of a time keeping the listeners interested when droning
on about UR this and UR that... (;-)
Name, Directions for Finding, and Attributes (my preferred terms).
Short and sweet.
> Now, I'd like to understand from someone else what else we need in the
> way of hooks in the infrastructure in order to allow the applications
> builders and information architects and engineers to do their part.
> In fact, I suspect that part of the confusion is that there are
> people in this group whose missions are to be the information and
> application architects and engineers. And those are important tasks,
> but we must understand where the cut comes between those tasks and the
> shared support structure that we are trying to provide for all of
> them.
> Karen
>From the perspective of one such architect, I applaud this nod of
acknowledgement that perhaps, whatever is decided on, has to be built
and more importantly, used and supported. My one attempt at presenting
ways to implement and package the UR* material seems to have fallen on deaf
ears. I am still convinced that to propogate and encourage the use of
the UR* standard, someone has to put out a standard API that encapsulates
the underlying semantics, otherwise, only those patient enough to decipher
the rules and guidelines will use it and the whole point of "Uniform" will be
lost. A number of other support mechanisms allowing for two-way conversion
between UR* and other external schemes will also be necessary to support
the inevitable backward compatibility that will have to be handled for
a while. These are academically unattractive, but pragmatically necessary
tools for implementation. Leaving them to individual developers will
lead to subtle incompatibilities and eventually an industrial-sized
"mil-spec" type standard that will try to cover every possibility.
Cheers,
R.
-- Ramin Firoozye' rp&A Inc. - San Francisco, California Internet: rpa@netcom.COM - CIS: 70751,252--