On Fri, 3 May 2002, Geir Magnusson Jr. wrote:
> My point is that, like it or not (I like it, Costin doesn't) there is some
> benefit of letting like minded people form a community unto themselves -
> this is the whole argument behind bringing XML and Jakarta together - lots
> of like minded people working together can be more than the the parts
> individually. (On this subject, I have concerns about the size of such a
> beastie, but that's not the point here...)
Yes, there is great argument for allowing like minded people to form a
community. But that's an argument for keeping XML and Jakarta apart, not
together. XML people are not interested in Java as a community, and
Jakarta is not interested in XML as a community. Sure they have
cross-over, but not as the communitys chief interest.
The issue is that people are wanting the communities to be discrete, which
is fundamentally flawed. Communities overlap.
Apache mainly has language centric communities. I think this is good, in
that it helps with those particular mentalities and stops us getting these
solutions that are half perl, half java, half rebol. The XML project is
somewhat of an anomaly as XML is not really a computer language but more
of an all pervasive technology.
I think an XML community does make sense. And a DB community does make
sense. But they don't entail implementations.
There should be a Java implementors community. A perl community. A Tcl. A
<insert weird language>. Etc. Which is close to the current. These people
are the developers. They hold 'ownership' of the implementation.
Then there are horizontal communities. XML, DB, GUI, Corba, etc.
These people bring together implementations as a community. They contain
the knowledge of what to use where, how to use it. In short the user
discussion and documentation at a high macro level. These horizontal
communities would not hold implementations though, unless they be XSL
scripts, SQL scripts, or XML scripts that describe GUIs.
This way, everybody is happy?? [Probably not].
It seems to be a classic information architecture problem actually. Does
the user have 1 way to get to product A/data-bite B, or do they have
multiple paths.
The former is easier to manage. It makes more sense to focused users and
keeps things very focused.
The latter is harder to manage, but is far better for users who are
viewing the content. They are able to view the content in a particular
context.
So: Java/Perl/C = Content.
XML/DB/GUI = Context/View. which may contain minor data.
Before anyone gets too anti these ideas, they're just ideas :) I have very
little personal belief in them yet. I've noticed that I tend to get in
trouble saying things on the lists that people think I have a fervent
belief in.
Any views?
Hen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
