Among the many and several things you
forget to mention, Bob, are the literally years of requirements gathering that
have already gone into the engineering that has produced the artifact we have
in hand, XrML2. With that perspective I believe that in no way shape or form
are we lacking for breadth in the space of design requirements for the task at
hand. Indeed, if you’ve understood the architecture you’ll realize
that the XrML2 core in particular is all about fundamental expressivity of
authorization policy structure, not particular authorization polices. In
analogy, it is all about the structure of English grammar, not particular
English sentences. It is whether the grammar is expressive enough is our
fundamental question, not whether we have an inventory of all the English
sentences one would ever want to write. You don’t have to examine every
possible sentence in order to come to an informed opinion that the grammar will
in fact be able to form sentences that one might want to say in the future. In
the same way, we don’t have to examine every possible user of the rights
language (though of course more is better) in order to come to an informed
opinion that the rights language is expressive enough to address their needs.
You seem to repeatedly advocate and
infinite and never-ending cycle of inquiry, consultation, and coordination with
a continually growing litany of outside organizations, even waiting, delaying, and
dallying for those who by your own admission rank us of a such low priority to
not even respond to us for months. Engineering is never done with perfect
information. In all engineering exercises, there comes a point where one
understands that shipping is a feature too, and resolves that one has the best
handle one can on the problem under the circumstances, and decides that
necessary refinements will be made later. Given your stance here and on related
issues, if I didn’t know better, I’d suspect that you actually
didn’t want this group to ever manage to produce a successful result.
Whether we will be voted up or down by
the broader membership will depend on the quality of the product and its actual
manifest utility, not the quantity of the requirements gathered in its
production; the two are not the same thing. More requirements are better than
fewer, but we will never manage to personally meet all of the customers of this technology.
Bob
-----Original Message-----
From: Bob Glushko [mailto:glushko@SIMS.Berkeley.EDU]
Sent: Thursday,
August 22, 2002 9:05 AM
To: Robin Cover;
Rights-Requirements SC
Subject: Re: [rights-requirements]
HIPAA, HL7 and general questions
This is too important a comment not to respond in
support of Robin Cover.
At 08:03 PM 8/21/2002 -0500, Robin Cover wrote:
------------------------------------------------------------------
"An assignment of initial representatives was made. The following
final list was agreed upon by the Requirements SC:
1. MPEG ("Motion Picture Expert Group") - BG
I know this is what the minutes of the meeting say, but I don't think that
"final" really meant final. Granted, Hari probably wrote these
minutes in a state of "irrational exuberance" because he's got the
job of moving things along, but throughout the summer he and the rest of the
committee have demonstrated a willingness to solicit requirements from other
organizations as we identified them as potential stakeholders and we've
accepted requirements "out of the blue" from organizations who identified
us without any help. I don't think there has been any sinister attempt to
exclude anyone from participating.
The problem is simply that it takes time to engage the appropriate
organizations and for their internal schedules to reach a point where they can
pay attention to us. I've tried all summer to get UBL engaged with us but
have failed simply because they've spent most of the last two months in getting
a significant new release out themselves. UBL has obvious and important
overlaps with the scope of our work. But you can't expect them to drop
their own work because we are impatient.
So I completely share Robin's concerns that this TC is overly
fixated with schedule at the expense of getting complete requirements, and that
our failure to adequately engage the HL7/HIPAA constituency is a serious
one. There is no way that the TC can claim to be creating a comprehensive
rights expression language without their input. I also agree that
the withdrawal of the XBRL camp puts us in a weaker position when we try to
convince the OASIS membership to approve our work as a standard.
Now if we were developing some narrow vertical specification -- like so many of
the OASIS TCs -- it wouldn't matter so much. But most of us believe that the
core expression language is supposed to be "the mother of all rights
expression languages" that, when extended, will be usable by all the
"domain" languages. We can't plausibly claim that if we don't
get requirements from healthcare and financial services, two of the most
important domains. Telling them "we'll get to you in future versions
of the spec" isn't credible. We'll get voted down by the broader
membership.
-------------------------------------------------------------------
Liora seemed to suggest that if this domain were to be considered as to
its rights-language requirements, one would need to go through HIPAA
specs and the HL7 RIM (Reference Information Model) to make sure the
underlying requirements in the data models were accounted for in the
RLTC requirements specification. So one might ask: can we do this job
at this point, or would it actually make more sense for Liora to do this
job once there's a draft requirements document to inspect?
Liora is a member of OASIS because of the reciprocity agreement it has with
HL7. I recommend that we invite her to join our TC, at least for a few weeks,
so that she lead this evaluation and insertion of the HL7/HIPAA requirements
into our set. We simply don't have anyone in the requirements team
now with the expertise to do this.
This would ensure that we'd be credible when we published our requirements for
external review. We should do the same with XBRL -- I know that Zac Coffin has
withdrawn from the TC, so we need to beg him to come back or to find someone to
take his place.
bob