[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [rights-requirements] Some proposed topics for Aug. 28
Gentlefolk,
We are defining a XML data structure, together with an algorithm for its interpretation, namely an authorization algorithm which gives a thumbs up or thumbs down to a given attempt to exercise a right.
In my mind, as simply as I can put it, the 'core' material speaks to the fundamental XML mechanics of defining the data structure, and the specification of the algorithm. An important part of the nature of the specification is that the algorithm specification should not, indeed cannot, enumerate the semantics of all possible rights (or principals or resources or conditions, for that matter); thus the algorithm specification MUST be written in such a manner so as to allow rights that, say, were invented after it was written to be accommodated within the algorithm.
With that in mind, I see some important distinctions:
"No rights unless explicitly granted” speaks to the algorithm specification, namely that it should not answer “yea verily” unless the right in question has been explicitly granted. Such a requirement directly speaks to the specification of the authorization algorithm.
In contrast, "The rights language shall be able to express permissions associated with the fair use doctrine of the US Copyright Act" seems to be entirely analogous to (for example) “The rights language shall be able to express permissions associated with the appropriate use of XYZ Co’s source code control web service”. That is, it seems to be entirely within a certain category of things which are outside the algorithm specification, a category which, as above, necessarily exists.
If someone were to propose a “claim right” construct, I would hope that they also propose its impact on the authorization algorithm; absent the specification of such impact, there is no semantic conveyed, and the construct is devoid of technical meaning or interpretation. This is a crucial point.
Finally, I’ll mention in passing a lingering underlying concern I have about the nature of some of these proposals, namely that they are so heavily US focused. I for one am extraordinarily leery of producing a REL that codifies and embodies US law as a distinguished or more-equal nature than that of other nations, provinces, and states.
Bob
-----Original Message-----
Hari et al. --
We have several items we would like placed on the agenda for tomorrow's call.
During last week's call, several subcommitte members requested clarification of the terms used by Hari to parse the requirements. In particular, concern was raised over the distinction between domain and core requirments and the apparently inconsistent application of the definitions to seemingly similar requirements.
During last week's conference call, some subcommittee members urged us to understand the expressions that "the core" allows. We have assumed that "the core" is the XrML Core 2.1 Specification. Based on this assumption, we have identified changes, both additions and subtractions, that our requirements call for. We are preparing change requests accordingly. One such change request is the addition of a core "claim right" element that is on equal footing with the "grant right." Such a right is "common to all" domains and is necessary to ensure that appropriate extensions can be accomodated.
Using our understanding of these definitions, we extracted from our submission 25 requirements, 22 of which qualify as "core" requirements.(Analysis attached.) By contrast, Hari's analysis revealed only 6 requirements, 5 of which are "domain." We reviewed other requirements submissions and found that our analyses of those were substanitally different from Hari's.
For example, OEBF requirement 2.5.1 states, "No rights unless explicitly granted" and is said to be a core requirement encompassing both RL and system requirements. By contrast, the reworded SBL requirement 3 states, "The rights language shall be able to express permissions associated with the fair use doctrine of the US Copyright Act" and is considered a domain requirement, presumably because of its reference to a particular law.
These requirements make structurally identical demands on the REL. The SBL requirement merely invokes a familiar doctrine as a way of summarizing a likely approach to rights expression that is common to all domains. This fits the definition of a core architectural requirement, not a domain requirement. Perhaps these differences are attributable to the lack of detailed, operational definitions of the "core," "domain," "system" and "rights language" (RL) categories.
We feel that fairness and consistency will suffer if we, as a subcommittee, fail to arrive at a common understanding of the definitions of the categories, and of how they have been applied to the current submissions.
A place to start in this effort would be to see a parsing of the XrML 2.1 Core and Standard Extension into the form that Hari has offered for other requirements.
We look forward to discussing these points tomorrow.
Aaron Burstein Dean Rowan ------------------ Samuelson Law, Technology & Public Policy Clinic http://www.samuelsonclinic.org/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC