OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-requirements message

[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