RE: [rights-requirements] HIPAA, HL7 and general questions

["M. Paramasivam" <parama@microsoft.com>]

Hi Robin:

Thanks for writing back. My comments below... (I have excerpted portions
of your email that I can address; I hope I have not messed up the
context)

[Robin]
>   - following the September 4th TC meeting (assuming the approval of
>     the V1.0 Requirements SC Draft), any new requirement documents
which
>     is received will be acknowledged as received, and its contents
>     analyzed; if the analysis proves to simply affirm the data points
>     in the v1.0 REQ, these will be noted clerically as supportive; if
>     the analysis proves to levy requirements *not* already envisioned
>     in the 1.0 REQ, Hari says they will be labeled as v1.1 reqs and
>     will NOT be relevant to the design work which is scheduled to
>     result in an OASIS Standard of May 2003
> 
> Hari, can you clarify if any of this is incorrect based on what you
> have articulated orally and in writing?
> 

I will await Hari's clarification but it is certainly not my
understanding that v1.1 (or subsequent ones) "will NOT be relevant to
the design work which is scheduled to result in an OASIS Standard of May
2003". ThomasD's email suggests that this is not the case either. I do
think that clarification on this issue will go a long way in addressing
many of your concerns as they seem to be rooted in 1.0 req being the
last word toward requirements.

[Robin]
> I have expressed appreciation similarly to Hari, privately and I think
> publicly, for the meticulous, careful audit trail supported by numbers
> and preservation of the "raw" data.  It represents a lot of work, and
> could serve as a model for some processes I've seen in the past which,
> by comparison, were haphazard and imprecise.

Good. I am glad that we are agreed on that.
 
[Robin]
> The respect in which I find it puzzling is that:
> 
> * the identification of "entities" from whom input would be sought
seems
>   unrepresentative, for example
> 
>  - failing to identify the ODRL effort, which arguably is the ONLY
real
>    alternative to XrML as a rights language (see Bill Rosenblatt's
>    recent review of ODRL and OMA's use in OMA Download)

Just a minor nit: Both the MPEG and OeBF requirements were co-authored
by Renato Ianella, who is the architect of ODRL. So, I am not sure I'd
say that the requirements process failed to identify the ODRL effort.

[Robin]
> In my experience, the whole idea of requirements engineering is to
obtain
> input and evaluation from the stakeholders in such a manner that the
> designers can confidently create something representing the users'
wishes.
> Asking for documents would be stage 1; creating a draft Requirements
> Document REQ 1.0 would be stage 2; soliciting public review of the
> Draft Requirements Document would be stage 3; correction and
augmentation
> of the Requirements Document based upon public review would be stage
4.

I agree with all of the above but I am unsure why you think this current
process precludes what you suggest. 

>   As far as I
> know, this is precisely why W3C and other standards efforts would
> publish a Requirements document and solicit public feedback:
> 
> i.e., publicize the draft REQ document in appropriate channels, create
> an email address for public comments, establish a comment period for
> the draft, publicize a method for contributing additions/corrections
> in the most suitable format for evaluation, etc.

These are great ideas and we should do this with REQ v1.0. The first
step toward that is getting a REQ v1.0 though.

Overall, it appears as though we are asking for the same things, but for
some reason I seem to think I am going to get them while you think you
are not.