- From: Leslie Daigle <leslie@beethoven.bunyip.com>
- Date: Thu, 22 Jun 95 10:08:46 -0400
- To: masinter@parc.xerox.com, moore@cs.utk.edu, uri@bunyip.com
[From Keith Moore's message:]
> > What I'm getting at is that, if the URI end of things focusses on
> > developing "the ultimate address scheme", and the metadata group focusses
> > on "the ultimate representation of a data object", we may wind up with
> > two systems that are individually good, but that don't support each other
> > properly in order to provide resource location and discovery.
> We need to do these serially rather than in parallel.
And,
[From Larry Masinter's message:]
> Just because things must be coordinated doesn't mean they have to
> happen in the same working group. HTML and HTTP are different working
> groups, even though they are intertwined. For that matter, HTTP and
> HTTP Security are different working groups!
I disagree that these things should be done serially, and I am not suggesting
that they should all be done in one working group. The HTTP and HTML groups
play together because it is quite plain that usage requirements of one group
become design requirements of the other - they support the same applications
at this point.
What I have said is the that the URI group should continue to consider some
metadata issues, at the level of architecting resource location/discovery
tools.
Consider the analogy of trains and railways. You can't just sit down and
build a railway line without consideration of the cars that will run on it --
what are their handling characteristics? This affects how the turns must be
banked. How heavy are they? This affects what the railbed will be.
Similarly, you can't just build trains without consideration of the rail lines
they will run on. The ultimate train might be 20 feet wide, but it is
impractical to run that width of track through most areas (e.g., mountains).
Note that this does not mean that train manufacturers build rail lines, nor that
rail line designers build trains. Each area has other design considerations
that have nothing to do with the other (e.g., how long an individual segment
of the rail is, to minimize the number of joints, what kind of seats the train
has), and should be handled by people specializing in those areas.
Rail line designers negotiate requirements of trains, and vice versa.
To get back to my originally stated concern, I'm worried that the URI group
is in danger of designing a lovely rail line system in absence of consideration
of the trains running on it -- or perhaps by saying, "Yeah, I have ridden
in trains, I know what they are like." Similarly, the metadata group
could build a wondrous train, but it won't serve the people using our
rail line system. ("Seats? But we need cargo trains!").
[From Keith Moore's message again:]
> Also, we should beware of trying to define the "ultimate" anything.
> Rather than trying to solve a problem for all possible scenarios, we
> need to think in terms of engineering a solution which is satisfactory
> for most needs, but still cost-effective, and which leaves a path open
> for future expansion.
Agreed, if we try to build the ultimate something or other, we will be
eternally wrapped up in design while the rest of the world is off building
workable systems.
On the other hand, with a certain amount of vision, we can do more than
just stack engineering hack upon engineering hack.
Leslie.
------------------------------------------------------------------------------
"Life is a Usability Test" Leslie Daigle
leslie@bunyip.com
-- ThinkingCat Montreal, Canada
------------------------------------------------------------------------------
Received on Thursday, 22 June 1995 10:10:26 UTC