[
Lists Home |
Date Index |
Thread Index
]
There are lots of stamps and stamp collections.
One might say that the most important goal of
the web has been to open these up for public use.
There is so much repetition of the same ideas that
it is anyone's permathread as to whether or
not what was once called 'corporate learning'
is occurring on the web even though that was a
once much touted goal of the hypermedia community.
See papers from Wayne Uejio - GE Evandale circa '90-91.
It is a challenging problem to engineer a system
with both an intuitive interface for entering
information and an intuitive interface for getting
specific correlated information back out. We
seem to be better at doing the former than the
latter (eg, QBE). One can meet your definition for
a useful system without creating a productive
one for all occasions.
len
From: Rick Marshall [mailto:rjm@zenucom.com]
On Tue, 2004-01-06 at 07:42, Bullard, Claude L (Len) wrote:
> Related orthogonally to the flexibility and grunt
> work assessment that I do agree with: the problem
> I have with so many tools today is that the engineers
> have succeeded spectacularly at enabling us to get
> information into the systems, and failed almost as
> spectacularly at enabling us to get information out.
but any useful system is
inputs -> transfer function(s) -> outputs
anything else is stamp collecting
rick
> How many projects have you worked on where the
> requirements have been driven almost exclusively
> by one culture of the data entry specialists? Udell
> makes reference to the social life of XML documents
> in his current xml.com article. Isn't this a redux
> of what we were talking about in the heyday of
> comp.text.sgml?
>
> Over the holidays, I stumbled over a TAG (the mag,
> not the group) article that I wrote in 1992 describing
> feedback adaptation, enterprise integration, chaotic
> systems, and so on. It is 2004 and we are still working
> on the same problems. Whoda thunk it...
>
> len
>
>
> From: David Megginson [mailto:dmeggin@attglobal.net]
>
> It would probably work very well if problems remained constant throughout
a
> project (like, say, building a bridge across a river), but in high tech,
> they do not -- we have only a limited need for people who can create an
> algorithm to do a computation in Olog(n) instead of On(log(n)), but we
have
> an enormous need for people who can track changing requirements and
> userscapes and refactor code violently and continuously to match them, and
> we have an even bigger need for people who help build consensus and
> communities of users. It's mostly flexibility and unscientific grunt work
> that brings success.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
