On
reading Ian's message, I wonder whether I was clear. I want the criteria
for *submitting* a recommendation profile proposal to admit a spec that has
a single implementation. This document will have to go through the
normal process before it can become an actual recommendation. This is a
similar (although stricter) process to any other recommendation document in the
GGF and similar standards bodies. So this process should be
well-understood in the community. The process will be stricter than
the existing GGF process fir recommendation documents, at
the existing process doesn't require any implementation to exist before
submitting a recommendation, and has fewer criteria for acceptance as a
recommendation.
WS-I
is primarily a reactive body. GGF needs to show leadership: we should
steer the development of Grid technology. On occasion we will face the
"chicken and egg" problem, in which people are reluctant to adopt a
specification because it isn't part of a profile, but we can't make it part of a
profile because it isn;t widely adopted. The process by which a submission
becomes a full recommendation seems to me an excellent way of resolving this
issue.
Any profile document will exist in
'draft' form before it is submitted as a 'recommendation', just as any other
specification. As I understand the aim of the profile
template document, it is precisely to specify that profiles must
have links to implementation experience and adoption, and to define the
rules for creating them; i.e. it specifically addresses the concerns that Ian
raises. I don't see a problem with 'draft' documents; everyone knows that
documents go through a draft stage. Unless Ian's reference to 'draft'
profiles was referring to "Informational"
profiles?
One
concern of Ian's that isn't addressed by the profile template document is
which bodies can produce profiles. The intention, I believe, is that the
OGSA profiles have to be produced by the OGSA WG. I agree
that we need some central body that controls the production of OGSA
profiles.
Dave.
-----Original Message-----
From: Ian
Foster [mailto:foster@mcs.anl.gov]
Sent: 21 December 2004
13:04
To: Dave Berry; d.snelling@fle.fujitsu.com
Cc:
ogsa-wg
Subject: Re: [ogsa-wg] Profile documents
Dave's comment captures a major concern I have about how the profile
notion seems to be evolving.
A profile, in the sense of the WS-I
profiles that formed at least the starting point for our discussion, documents
a way of using well-established and widely used specifications. I believe we
have fairly broad consensus for that definition.
However, we are now
introducing the idea of a "draft" profile that does not need to be grounded in
adoption. In so doing, I fear that we abandon the discipline that will allow
us to ensure that profiles represent authoritative statements on how to build
Grid systems. GGFers will conclude that a profile is a way to respectability.
We will start to see many proposals for profiles, many with no connection to
implementation experience or adoption, and I don't see how we will be able to
say yes to some and no to others, as we will have no clear rules for doing so.
Working groups will start to produce their own profiles, as well. We will end
up with a set of profiles that look as diffuse and ill defined as the current
set of GGF working groups. Of course, some will be "draft" and some
"recommended", but I think that distinction will be lost on the
community.
DAIS for me represents an excellent test case for what a
profile should be. It's a nice piece of work and has at least one academic
implementation. However, it hasn't seen any adoption by database vendors. That
to me means that it doesn't belong in a profile. This is not to say at all
that DAIS is not valuable, or that the DAIS team should not be working to get
DAIS adopted by vendors. It's simply saying that a profile isn't the way to do
it.
Ian.
At 09:22 AM 12/21/2004 +0000, Dave Berry wrote:
I definitely want to allow the
DAIS spec in the first data profile.
This is partly the chicken and egg
question; if a spec isn't in an OGSA
profile, people will be less
inclined to implement it. This is
particularly applicable to the
DAIS spec, because we want people to
implement it as part of their DBMS
systems, not as a standalone
executable. (This is to avoid
unnecessary copying of data in the
implementations).
_______________________________________________________________
Ian
Foster
www.mcs.anl.gov/~foster
Math & Computer Science
Div. Dept of Computer Science
Argonne National Laboratory
The University of Chicago
Argonne, IL 60439,
U.S.A. Chicago, IL 60637, U.S.A.
Tel: 630 252
4619
Fax: 630 252 1997
Globus
Alliance, www.globus.org