[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [rights-requirements] comments on introduction
Greetings, Below are my comments/suggested edits on the introduction. I had a trouble understanding what a few of the sections meant until I had read them outloud to myself few times, so I took a shot at rewriting them to make them a bit more understandable. (It was my intention to not alter the meaning in any way.) Besides the enumerated edits below, I would also like the Introduction to include definitions for Core and Standard Extensions and a brief explanation of the difference between the two. Thanks, lisa **** 1. Suggest slight rewording for clarity. I've also included a link to the charter in parentheses since we reference it outright within the text, and the relevant parts seem to wordy to include: Original Text: (1) While the charter of the RLTC is written in words that are meant to draw upon terminology and concepts represented in existing bodies of work in the marketplace, the requirements document is intended to stand alone and uses colloquially accepted terminology. Thus, in this document we use the colloquial words equivalent to the marketplace concept of rights: permissions granted by one entity to another. Edited Text: "The charter of the RLTC (http://www.oasis-open.org/committees/rights/) is written in words that are meant to draw upon terminology and concepts represented in existing bodies of work in the marketplace. The requirements document is intended to stand alone and uses colloquially accepted terminology. In this document we use the colloquial words equivalent to the marketplace concept of rights: permissions granted by one entity to another." 2. Original Text: (2) To be rigorous, by 'permissions' we refer to a set of usage rules applicable to, for example, one or more objects or services; these rules may be used by a compliant interpreter to control a user's access to and usage of those objects or services. The 'user' in this case might be a human or a hardware or software component. Edited Eext: "By 'permissions' we refer to a set of usage rules that may be used by a compliant interpreter to control a user's access to and usage of one or more objects or services. The 'user' in this case might be a human or a hardware or software component." 3. Original Text: (3) While the language that is standardized by this committee may be expressive enough to express policy associated with the aforementioned areas within the appropriate contexts of the problem addressed, the scope of this committee is not to solve the bigger problem. The work product of this technical committee will be one component of a larger ecosystem of componentry and workflows that will address those issues that are not addressed by this technical committee itself. Edited Text: "The language that is standardized by this committee may be expressive enough to express policy associated with the aforementioned areas within the appropriate contexts of the problem addressed, however, the scope of this committee is not to solve the bigger problem. The work product of this technical committee will be one component of a larger ecosystem, and other components and workflows will be addressing those issues not addressed by this technical committee. Thanks, lisa
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC