From: Gavin Thomas Nicol (email@example.com)
Date: Tue Aug 22 2000 - 03:22:40 PDT
> > The interesting thing about both is that there are alternatives,
> > that, for many applications, are simpler, and more appropriate.
> That's the problem. Each application taken on its own could hack up a
> simpler alternative, but we're then left scratching our heads as to how
> each of these alledgedly indepedent apps fits in with their
> not-so-dissimilar neighbours.
This is *the* hard problem anyway. That's what the XORBA thread is partly
about. Take EDI as an example, or e-commerce in general. Standardization
here is only 80% of the solution.
> On the Web, whereit's a fundamental that everything is connected to
> everything, we've a duty when working in overlapping domains to
> think about how our application plays well with other in the
> same space.
It's one criteria. I am a firm believer in "may a thousand flowers
bloom" and natural evolution of software systems. When things need
to converge, they will. They will converge much more quickly if there
is a "killer" application, like the HTTP/HTML/URL team.
> RDF piggybacks off the Web's one unifying principle
> (URI names for everything) and tries not to add
> much else besides. Sure you could probably do each individual
> application in a simpler format (comma separate text files anyone?) but
> you pay the price when it comes around to hooking all these different
> apps together. Which is what the Web is all about...
I think RDF has some great potential uses, but we should explore
alternatives where they make sense.
For example, RDF has been touted as a data modelling language by some
folk. I saw it used as an RPC packet representation recently.... which
was a mess, and easily replaced by a *much* simpler XML-RPC system.
Still, that was probably a bad use of RDF... as a simple framing
system, it's fine. I'm more interested in mapping into it, when
needed, than always encoding in it.
This archive was generated by hypermail 2b29 : Tue Aug 22 2000 - 03:26:11 PDT