Title: getting started on requirements
I
would like to add my support of Bob Atkinson's thoughts. I think it might
be useful to divide the requirements gathering process into three parts.
1)
There are requirements that will inform our work on the Core architecture of the
language.
2) There are those that inform the work on the Standard Extension,
and as Bob A. pointed out that is not as time sensitive as those for Part
1.
3) There are those that inform the way participants in a given
domain (e.g.. UBL, eBooks, Healthcare, Web Services, etc) might want to build
extensions to suit there applications. These requirements will help in
designing and describing the Extensions Process and Guidelines that we would be
promoting to any group that sees the need for an REL. Beyond that,
detailed requirements from a given domain will be collected by the participants
in that market to actually develop the extension of REL that solves their
problem, however the development of that extension will be done by them and not
by the RLTC.
/Brad
-----Original Message-----
From: Bob Atkinson
[mailto:]
Sent: Thursday, May 23, 2002
1:48 PM
To: Glushko, Bob;
Cc:
Subject: RE: [rights] getting started on
requirements
There are many
approaches to getting organizations that might usefully be interested in our
work from caring about it; this is by no means a black or white thing. It is,
for example, certainly not the
case that we should reasonably gate the forward progress of our work on a
positive thumbs-up from *all*
the organizations that you mention, for doing so would put us in a perpetual
state of paralysis. There is rather a balance to be struck.
The XrML2 core is
pretty simple in its structure: (subject, verb, direct object, conditional
clause)* is its basic template. This mirrors (not at all surprisingly) the
core structure of every pretty much every authorization framework that I can
think of, a body of work which is not exactly immature. The collective wisdom
of our committee in this area surely can lead us to understand where we are
exploring well understood territory and where solicited input likely would be
most valuable.
In some contrast, the
XrML2 standard extension may find more useful goodies from a broader
consideration of domains than has heretofore occurred. But here the price of
omission is less than that of the core: this is but one extension, a well
known and well publicized one yes, but an extension nevertheless. No central
or fundamental harm comes from the omission of an element therefrom: it can
live in a different extension with comparatively minor consequences. This is
not to say that producing a useful and handy standard extension is not
important, only that the scheduling considerations are different and less
compelling when striking the overall scheduling balance.
Rather than the
serial approach outlined below, I advocate a parallel one, one wherein we
pursue outreach such as is suggested below (perhaps together with some focused
personal prodding where members of our committee have useful contacts) at the
same time as we in our own collective wisdom (which appears to actually cover
quite a broad spectrum and thus to be a reasonable sounding board) articulate
the requirements that we can see; this we should be able to do in quite short
order. Having done that exercise, we will be able to easily understand what we
have well in hand and what we are lacking, and so able to judge the importance
of obtain à priori design input from particular external
organizations.
There is also another
perspective on this. MPEG21 is moving forward apace with their work involving
XrML. It is in my understanding unlikely (though others here certainly have
more detailed knowledge than I on this topic) that our TC will be able to
significantly alter the schedule on which they do so. If we fail to connect
with their schedule by some means or other, they will, I believe, in the end
create a fork of XrML, the core and standard extension included. It would then
seem to me of precious little relevance of how much other organizations
believed "that our TC
is going to speak for them.", for they
would have an alternate and arguably more compelling source for this
technology. MPEG21 is by no means the only customer of our work, but it is
equally by no means just one among equals.
Bob
-----Original
Message-----
From: Glushko,
Bob [mailto:]
Sent: Thursday, May 23, 2002 6:54
AM
To:
Cc:
''
Subject: [rights] getting started on
requirements
I'm eager to start getting requirements and it strikes
me that there is significant overlap between that process and the liasion
process with related standards efforts and other organizations with interests
in DRM.
Specifically, the best way to achieve broad consensus
and buy-in on a DRML is to
1)identify the relevant organizations
2)invite them to review the current specifications,
especially the use cases (since these are the most accessible point to get
started), and submit any new requirements or use cases, along with any
schedule constraints or milestones in their activities that present
opportunities for synchronization
[i'm reacting here to the unidimensional view
in our kickoff meeting that seemed to make the MPEG21 milestones the only ones
that matter to us]
3)do a careful job of analyzing their
requirements
I've thought about the impact of a request like this
on standards activities that I'm currently involved in (like UBL) and I
suspect that we'd need to give the organizations we identify in step (1) here
at least a month to get back to us. It is unreasonable to give them any
less time; for example, in the UBL case, there is intense work going on to get
ready for a 1-week face to face meeting the week of June 2-6, and nothing is
going to get higher priority. So the earliest there could be any serious
consideration of DRM issues would be the second week of June, and that ignores
the "catch up" time needed when you get back to work after being out of touch
at a standards meeting for a week.
My point here is that we have to be realistic about
the schedule for collecting requirements from other standards efforts. If we
don't give people sufficient time to do this according to their own processes,
they will not buy into the idea that our TC is going to speak for
them.
I also think that we need to cast a wider net than
simply the standards organizations that Brad listed on Tuesday. We need to
identify some in the user community rather than the technology or content
communities because I think that in the former is where our acceptance and
credibility problems are most likely to appear. I will start down that road
assuming that Brad and others already have a handle on the groups who are
creating their own DRMLs.
-bob
Robert J. Glushko, Ph.D.
Engineering Fellow
One Market
Street, 13th Floor Steuart Tower
San Francisco CA 94105
415-644-8731
