First posted: June 3, 2004; updated July 1, 2004; updated August 19, 2004
This is neither a definitive nor even a nearly complete history of the rights expression language known as the eXtensible rights Markup Language. I did some exploring of the evolution of XrML when researching a white paper on rights expression languages for the Library of Congress. I am creating this document to store and preserve what I have learned, and perhaps to save the time of others interested in this topic. Robin Cover's coverage (no pun intended) of XrML's chronological development and technology is an excellent source of information. My write-up here focuses on the usage rights, and by that I mean the rights that mainly determine what an end user can do with the digital resource. XrML has extensive vocabularly that interacts with trusted systems and business practices that are not covered here.
Although he wasn't the first person to define an interest in expressing rights algorithmically for the purpose of e-commerce, Mark Stefik, a researcher at Xerox PARC, is known as the originator of the concepts that became the XrML language. Stefik's research was on the topic of trusted systems for secure digital commerce[*], of which one part was a language to express the rights that the system would allow users to perform on digital resources.
The earliest evidence of this system that I have access to is the patent that Stefik filed for Xerox in November of 1994 (and was granted in February of 1998) entitled: "System for Controlling the Distribution and Use of Digital Work Having Attached Usage Rights Where the Usage Rights are Defined by a Usage Rights Grammar" (US Patent 5,715,403, issued to Xerox Corporation).
The 1994 patent proposes a set of trusted repositories that enforce usage rights that are permanently and directly attached to a digital work. The descriptions of these repositories and the diagrams that illustrate their workings look somewhat crude by today's standards of trusted systems design, but they cover a good deal of the thinking about trusted systems that is current today.
He also anticipates the need for special "devices" that can render the works while maintaining the protection, and acknowledges that the general-purpose computer is not a trusted device:
"...repositories never allow non-trusted system to access the works directly. A maker of generic computer systems cannot guarantee that their platform will not be used to make unauthorized copies." [*]
The rights language in the patent has the following usage rights defined:
|Play||A process of rendering or performing a digital work on some processor. This includes such things as playing digital movies, playing digital music, playing a video game, running a computer program, or display a document on a display.|
|To render the work in a medium that is not further protected by usage rights, such as printing on paper.|
|Transport type||Copy||Make a new copy of a work|
|Transfer||Moving a work from one repository to another|
|Loan||Temporarily loaning a copy to another repository for a specified period of time.|
|File Management type|
|Backup||To make a backup copy of a digital work as protection against media failure.|
|Restore||To restore a backup copy of a digital work.|
|Delete||To delete or erase a copy of a digital work.|
|Folder||To create and name folders, and to move files and folders between folders|
|Directory||To hide a folder or it's [sic] contents|
|Derivative Works type|
|Extract||To remove a portion of a work, for the purposes of creating a new work.|
|Embed||To include a work in an existing work.|
|Edit||To alter a digital work by copying, selecting and modifying portions of an existing digital work|
|Install||To install new software on a repository|
|Uninstall||To remove existing software from a repository.|
It also allows controls by copy count, time, security class, and fees and incentives.
|Copy count||... limit as to the number of "copies" of the work which may be exercised simultaneously for the right.|
|Restrictable/unrestrictable||... a condition to specify the effect of usage rights and fees of parents on the exercise of the right. (kc: Also Unchargeable/chargeable)|
|Time||... provides for specification of time conditions on the exercise of a right.... The terms "time" and "date" are used synonymously to refer to a moment in time. (kc: Further divided into start, end, and intervals.)|
|Security class||Access specifications can specify a required security class for a repository to exercise a right or a required authorization test that must be satisfied.|
|Usage Fees and Incentives||The billing for use is fundamental to a commercial distribution system. (kc: Allows for per use or metered; can be a fee from the user, or an incentive paid to the user.)|
At some point between 1994 and 1998, Xerox formed its Rights Management Group to continue the work represented in the patent. In November of 1998, Xerox issued the first XML version of the Digital Property Rights Language (DPRL), labelled Version 2.0. Prior to that time, DPRL had been written in the LISP programming language. Since LISP is mainly used in scientific applications, not in commerce, re-writing DPRL in XML was essential for its wider adoption. I do not have a copy of DPRL version 1.0, although there is evidence of it — and its LISP-ness — in the Stefik article in Scientific American in 1997.[*] (If you have a copy of DPRL version 1 that you can pass on to me, I'd very much like to see it.)
DPRL makes it clear that this is a machine-readable language, and that the activities controlled by the language take place within devices:
"Thus, specifications in the rights markup language are intended to be readable by machines rather than directly readable by people. They are used by systems that store, play, transport, copy, and sell digital works. These repositories potentially include a range of devices with embedded computers, including personal computers, set top boxes, personal document readers, personal entertainment devices, on-line servers, and trusted printers." [*]
"There are no rights in DPRL for actions performed by people, such as 'play for educational purposes,' although this might alternatively be approximated as 'play for a user possessing a specific, valid educator or student certificate.'" [*]
DPRL also appears to be the first version that states the rule that any rights not explicitly listed in the rights language cannot be granted. (If this is in the patent, I couldn't find it. If you find it, let me know.) This puts a great deal of pressure on the rights language, not to mention the implementors. The difficulty here is the need to balance security with the fact that one doesn't know what capabilities might be desirable in a product five or ten years hence. It means having to anticipate all uses, present and future without creating a language that is so general that it leaves loopholes for unauthorized uses.
"The rights for a digital work are explicitly listed. Any right not in the list is not granted." [*]
The rights list for DPRL 2.00 is the same as that in the patent, above, with two elements added: Export and Verify. Time and Fee are now modifiers on any of the rights, and a new modifier, Access, has been added.
|Export||... makes a digital copy outside of trusted system control.... that is not encrypted or otherwise protected. An Export right might be exercised, for example, to release an older work after it has passed out of copyright. (kc: Now life + 70 years!)|
|File management type|
|Verify||Verify rights are used to authorize checking of the authenticity of a work.|
|Access||Access specifications for authorization enable non-monetary criteria to govern the exercise of usage rights. (kc: I.e., subscribers, members of an institution.)|
In April of 2000, ContentGuard, recently spun off from Xerox and owned jointly by Xerox and Microsoft, published the eXtensible rights Markup Language (XrML) Version 1.0. The first "edition" of this standard was itself issued as a protected PDF file. The protection limited use of the file to the actual CPU where the download had taken place. To download XrML it was also necessary to agree to a lengthy contract that granted you a royalty-free license to use XrML, but that also stated:
"You agree that your use of the XrML Specifications indicates you You share the goal of promoting a common standard based on XrML and that You agree to all of the terms and conditions of this License Agreement."[*]
"Subject to the terms and conditions of this Licence You grant ContentGuard and all other Licensees a world-wide, royalty-free unlimited license to use all XrML Derivative Works that You create."[*]
These conditions, along with the protected nature of the file, appears to have been a deterrent to its use, or at least it was perceived that way by ContentGuard, because later the file was issued in a non-protected PDF format.
XrML 1.0 is an evolution of DPRL. It expands much of the management structure of DPRL: it adds unique identifiers, private and public keys, and other mechanisms for identifying and verifying the authenticity of the issuer and the user of the resource. It also adds certification for hardware and software that would be part of the trusted environment. The rights list remains the sam, although the definitions of individual rights have changed somewhat. In particular, XrML 1.0 distinguishes clearly between those rights that create a new resource versus those that modify an existing resource.
|Right||XrML 1.0 Definition|
|... we use the word "render" to refer to processes that transform a digital copy of a work into a form where it can be seen or used outside of the repository.|
|Play||PLAY rights refer to ways of making a transient or ephemeral copy of a work available for use. For example, a page of a book may be displayed on a screen or music may be played out a speaker. The image on the screen or the sound coming out of the speaker is a transient copy.|
|PRINT rights refer to making more permanent rendered copies of a work outside of the control of a repository.... the printed copy can be viewed without requiring that the "PRINTER" be used the entire time.|
|Export||An EXPORT right makes a digital source copy outside of trusted system control....An EXPORT right might be exercised, for example, to release an older work after it has passed out of copyright.|
|Transport rights govern the creation and movement of persistent copies of a work under the control of trusted repositories.||Copy||A COPY right is the right to make a new digital copy of a work.|
|Transfer||A TRANSFER right is the right to transfer the digital work from one repository to another. A TRANSFER right does not increase the number of copies of a work because the transfer transaction between two trusted systems removes the digital work from the sending repository when the copy has been created and verified on the receiving repository.|
|Loan||A LOAN right is the right to loan a copy of the work for a period of time. ... Typically, during the time that a work is loaned, the original copy of the work cannot be rendered. ... At the end of the loan period, the copy of the work on the receiving repository deactivates and the copy on the loaning repository reactivates.|
|File Management type|
|File management rights govern access to directory and file information when two repositories are connected. File management rights control how directory information of one repository can be accessed from another. They also control the making and restoring of backup copies.|
|Backup||Backup grants the right to make copies of a work for the purpose of guarding against the loss of the original due to accident or catastrophic media or equipment failure. The backup operation creates an encrypted copy of a digital work, which is in a form where it cannot be rendered without first exercising a restore operation.|
|Restore||A restore operation converts an encrypted backup copy into a usable copy in a controlled manner. Restore rights typically elaborate various fees and conditions that balance the interests of the copy owner with the interests of the publisher.|
|Delete||Delete rights govern the operation of deleting a copy of a digital work. The generally expected practice is to grant any copy own the right to delete the work. The right to delete needs to be controlled in applications where many people can log into a repository and where deleting a file could be done accidentally or in malicious mischief.|
|Verify||Verify rights are used to authorize checking of the authenticity of a work.|
|Folder||Folder rights govern the creation and naming of subfolders, and the right to reconfigure the folders by moving files and folders among folders.|
|Directory||A directory listing may be requested of any folder in a repository, allowing either the local or a remote repository to get information about the works, their parts, and other folders contained in it.|
|Derivative Works type|
|Derivative work rights govern the reuse of a digital work, in whole or part, to create a new composite work. The design goal for derivative work rights is not to cover all possible forms of reuse. Many kind of reuse involve substantial negotiation about issues that are outside the scope of what a practical trusted system can mediate or check. Rather, the derivative use rights are intended to automate the simple case where the rights owner can pre-determine fees and repository-testable conditions on a work prior to distributing it digitally. (kc: see note in paragraph below table)|
|Extract||The Extract right allows removing a portion of a digital work, creating a new work.... Extract differs from Edit in that it does not grant the right to modify a work, except by removing parts of it.|
|Embed||Embed grants the right to include a work as part of a composite work. Embed puts a copy of a digital work inside a composite work. If the optional editor specification is not given, then any editing system can be used. Otherwise, only the specified editor can be used.|
|Edit||Edit grants the right to modify a work. Edit is like Extract in that it creates a new work. It differs from Extract in that it is used to make changes to a work.|
|Configuration rights govern the adding and removing of system software from highly secure repositories. These rights are not relevant on platforms where the loading of software is not controllable.|
|Install||An Install operation makes software runnable on a repository. Just copying a program to a repository does not make it runnable. The installation operation checks that software is certified, that it has not been tampered with, and that it is compatible with the repository. If these conditions are satisfied, the install operation links the software into the secure software procedures of the repository.|
|Uninstall||The Uninstall operation removes software from the running system. Uninstall does not delete the file corresponding to the program. It merely disables it from running, restoring it to the state before it was installed.|
I want to draw particular attention to some of the rights here and their definitions. First, the rights Embed and Extract. What is key about these two rights is that they each involve more than one resource. With Embed, there is the work that the rights are attached to that has the Embed right, and the "composite work" that will receive all or a portion of the "focus" work. Extract is similar in that there is the focus work and the "new" work that is created by extraction. There is a significant assumption in these two rights, which is that the control is not associated with a single protected work but that the protection also applies to the re-used parts of the work. How this extended protection works is not clarified, but the introduction states: "Generally, embedding is done by a distributor, who adds value by repackaging the work." So it is possible that Embed and Extract are not intended as end-user rights. (Note that this is not a change from DPRL, although the language is a bit clearer in XrML 1.0.)
The other set of rights that I want to point out are the Backup/Restore and Install/Uninstall. The way that they are defined here they do not refer to the actions that we generally perform on files today. Instead, these actions imply special controls that are assumed to be part of the trusted system environment. Backup and Restore are a trusted backup and restore; and Install and Uninstall refer to adding a digital resource to a trusted repository or at least gaining them the status of "registered and usable" in the trusted environment.
The version of XrML that was made available in early 2002 is a radical departure from all of the preceding versions of the rights language. Version 2.0 is an abstract rights language with very few core elements. The core elements of XrML 2.0 are the ones needed to establish trust between systems so that transactions can take place. These include the Issuer of the license, the other parties to the license, and the ability to include resources and rights, digital signatures, etc. This version is not specific to any medium or type of resource, and could be used to control rights on digital resources, services, or even facts.
"XrML has thus become comprehensive by providing a framework to express rights at different stages of a workflow or lifecycle, generic by defining a large body of format and business neutral terms (about 100) and using these terms to specify rights to any digital content and any digital services, and precise through the development of a grammar and processing rules that allow unique interpretation of the language." [*].
The usage rights themselves are not included in the core. Instead, the core is extended to include actual rights and conditions. There is a standard extension that has some general-purpose data elements that cover counts, some time-related functions ("validityTimePeriod"), various fee options ("payment Flat," "bestPriceUnder,"), and the elements for revoking the license.
The rights data elements that we saw first in the Xerox patent and that have carried through all versions of the standard are carried in this version in an extension called the Content Extension. There are some new rights and some new rights element names or definitions, although the overlap is quite high. This table includes the rights from XrML 1.0 for comparison purposes:
|Xrml 1.0||XrML 2.0||Definition|
|File Management Rights|
|Directory||accessFolderInfo||Represents the right to deliver or reveal information about the works contained within folders.|
|Backup||backup||Represents the right to make copies of a digitalWork for the purpose of guarding against the loss of the original due to accident or catastrophic media or equipment failure.|
|Delete||delete||Represents the right to delete the digitalWork in a secured repository. The right to delete must be controlled if many people can log into a secured repository and delete files either accidentally or in malicious mischief.|
|execute||Represents the right to execute a resource (for example an application like a word processor) from a secure repository.|
|Folder||manageFolder||Represents the right to perform the following operations: create subfolders, name subfolders and reconfigure folders by moving files and folders among folders read Represents the right to read the work from the repository.|
|Restore||restore||Represents the right to restore a work from a backup copy, converting the backup copy to usable form.|
|Verify||verify||Represents the right to check the authenticity of the work in the repository. Authentication typically involves verifying signatures of signed data using the public/private key pair. Integrity verification ensures that the data received exactly matches the data that was sent; it ensures that the data has not been tampered with.|
|write||Represents the right to write or save the work in the secure repository.|
|Copy||copy||Represents the right to create a new copy of the digital Work, separate from the original that was copied.|
|Loan||loan||Represents the right to lend a work to another principal for a specific period of time. While the work is on loan, the original copy cannot be used.|
|Transfer||transfer||Represents the right to transfer a work to another repository, removing the work from the original location.|
|Derivative Works Rights|
|Edit||edit||Represents the right to make changes to a work to create a new work based on the original work. Edit is like extract in that it creates a new work. It differs from extract in that it confers the right to make changes to the work.|
|Embed||embed||Represents the right to include the work as part of a composite work. An embed operation places a copy of the work inside the composite work.|
|Extract||extract||Represents the right to use a portion of the work to create a new work. The extracted material is created as a new work, separate from the original work. Extract differs from edit in that it does not grant the right to modify a work.|
|Export||export||Represents the right to make a source copy of the work outside of the secure repository. For example, saving a protected (encrypted) work in clear-text. Export differs from copy in that an export is made to an in-the-clear non-secure repository, whereas a copy is made to another secure repository.|
|Play||play||Represents the right to render the work in a transient form, as appropriate to the content type (for example displaying a book, playing an audio clip, or showing a video).|
|Represents the right to make a permanent non-digital rendered copy of the work outside the control of a repository. Exercising this right might result in printing a hard copy of a book or creating an audio recording on a magnetic tape.|
|Install||install||Represents the right to make software executable (installed) on the repository, including, for example, checking that the software is certified, that it has not been tampered with, and that it is compatible with the repository.|
|Uninstall||uninstall||Represents the right to disable software from running, restoring it to the state it was in before it was installed.|
In March of 2002, Hari Reddy of ContentGuard became chair of a new OASIS technical committee on Rights Languages. The first meeting was in May of 2002. At that time the committee had over a dozen members and six sub-committees. In a meeting on May 21, ContentGuard appears to have presented XrML 2.1 as the starting point for the committee's work. It isn't clear if the entire standard was available to the committee; an earlier email had presented this short Technical Overview, which was sent to committee members on May 28, 2002, and is dated May 20, 2002. In this version of XrML, the standard has been pared down to consist solely of a Core Schema "containing definitions of concepts that are at the heart of the XrML 2.1 semantics, particularly those having to do with evaluation of a trust decision," and a "Standard Extension schema containing definitions of concepts that are generally and broadly useful... ". There are no usage rights defined in this version of XrML, since those rights were all in the Content Extension Schema.
|XrML 2.0||XrML 2.1|
|Core Schema||Core Schema|
|Standard Extension Schema||Standard Extension Schema|
|Content Extension Schema|
The difference in these versions does not seem to be significant, except that at the same time that the OASIS group was meeting, MPEG was working on a standard that was also based on XrML, and that would look like:
|XrML 2.0||XrML 2.1||MPEG-21|
|Core Schema||Core Schema||Core Schema|
|Standard Extension Schema||Standard Extension Schema||Standard Extension Schema|
|Content Extension Schema|
|MultiMedia Extension Schema|
The OASIS committee was stuck; they couldn't build on the MPEG-21 schema because it wasn't complete, and they couldn't develop their own independent schema because it might not be compatible with the MPEG-21 work. In addition, some committee members had concerns about the patent status of the OASIS work in relation to XrML and the "objectivity" of the committee. This latter was particularly problematic during votes that took place in meetings where nearly one third of the members present were employees of either ContentGuard or Microsoft. In August, 2004, the committee voted to disband.
XrML version 2.1 is not mentioned on the XrML web site, and the full standards document may not have ever been written. But the Technical Overview is a good introduction to the MPEG-21 standard, which was based on the version 2.1 core.
The Motion Picture Experts Group (MPEG) has developed a series of standards for the packaging and delivery of multi-media content in digital form. There are MPEG standards number 1, 2, 4, 7, and 21. Each covers a different problem area, for example MPEG-2 defined the DVD format, and MPEG-7 defined the standard for description and search of audio and visual content. MPEG-21 covers issues of structuring a digital package for network delivery of multi-media files and the application of identifiers and rights expression. The MPEG is a technical group of the International Organization for Standardization (ISO), and MPEG-21 was voted by the membership in 2004 to be an official ISO standard.
The MPEG-21 REL is another major change to the XrML language. Although many of the elements remain, the style of the document has changed fairly dramatically. Gone is the explanatory text that was generally found in XrML 2.0; what remains are soley the formal definitions of the data elements. For example, the entry under "Terms, definitions, symbols, and abbreviated terms" for "Authorizer" reads:
authorizer ordered five-tuple as defined in 5.5
And 5.5 reads:
5.5 Authorizer An authorizer is an ordered five-tuple containing the following members, in order: a) an r:License, b) an r:Principal, c) a time instant, d) an authorization context, and e) an authorization story. NOTE Conceptually, if an r:Grant or r:GrantGroup is authorized, it is part of a License and is authorized in that License by some Principal at some time instant based on some authorization context and there is an authorization story explaining why that Principal was permitted to make that authorization.
A general overview of MPEG-21 Part 5 was provided by RightsCom, but it is a high level overview and doesn't really help one understand the details. Fortunately, for the data elements that are in the rights section (referred to as "verbs") there are short definitions in the Rights Data Dictionary (RDD), which is Part 6 of the MPEG-21 standard.
The other great change is that the Content Extension is gone, and a MultiMedia Extension appears in its place. The Content Extension that was in XrML no longer exists in this version. This may mean that it has been effectively abandoned:
Because of this progress [kc: the progress made by MPEG in defining the REL for multimedia works] ContentGuard has frozen its release of XrML at Version 2.0. This is the final release ContentGuard expects to post to XrML.org. ContentGuard will maintain and support version 2.0 until such time as it is replaced by a release from a standards body and is no longer needed by our customers. [*]
And it appears that MPEG-21 is the standards body release that now takes its place:
This is the final release ContentGuard expects to post to XrML.org. Working drafts of version 2.1, reflecting changes/upgrades to XrML version 2.0 Core, Standard extension (SX) and Content extension (CX - to become the MPEG extension) can be found on the MPEG web site. [*]
The MultiMedia Extension is analogous to the Content Extension of XrML 2.0, although there are many differences in the data elements, some of which are attributable to MPEG's emphasis on multi-media works rather than documents. Where XrML 2.0 allowed for Edit, Embed, and Extract, the MPEG-21 REL characterizes the edit-like functions in terms of two factors: 1) whether the end result is one edited file or whether a new file is created in addition to the original file, 2) how the edit changes the size of the file. Sometimes these can be combined to be equivalent, or nearly equivalent, to rights elements in XrML 2.0, but not always. The table below gives the rights data elements from the MultiMedia Extension, with the XrML 2.0 rights included for comparison. I have used the definitions from the Data Dictionary.
|XrML 2.0||MPEG-21||RDD Definition|
|edit||Adapt||To ChangeTransiently an existing Resource to Derive a new Resource. With Adapt, two distinct Resources will exist as a result of the process, one of which is the original Resource in unchanged form, and one of which is newly made. Changes can include the addition to and removal of elements of the original Resource, including the Embedding of other Resources. Changes can be made temporarily to the original resource in the course of the Adapt process, but such changes are not saved in the original Resource at the end of the process.|
|delete||Delete||To Destroy a DigitalResource. Delete applies only to DigitalResources. Delete is not capable of reversal. After a Delete process, an "undelete" action is impossible.|
|Diminish||To Derive a new Resource which is smaller than its Source. With Diminish, two distinct Resources will exist at the end of the process, one of which is the original Resource in unchanged form, and one of which is newly made, whose content is Adapted from the original Resource, and a Measure of which is smaller than that of the original while no Measures of it are larger. Changes can include the removal of elements of the original Resource. Changes can be made temporarily to the original Resource in the course of the Diminish process, but such changes are not saved in the original Resource at the end of the process.|
|embed||Embed||To put a Resource into another Resource. The Resource into which a Resource is Embedded can be pre-existing or can be created by the act of combining the EmbeddedResource with one or more others. Embed refers only to the embedding of an existing Resource in another: if a "copy" of an existing Resource is to be created and Embedded in another, then both Adapt and Embed would be used.|
|edit?||Enhance||To Derive a new Resource which is larger than its Source. With Enhance, two distinct Resources will exist at the end of the process, one of which is the original Resource in unchanged form, and one of which is newly made, whose content is Adapted from the original Resource, and a Measure of which is larger than that of the original while no Measures of it are smaller. Changes can include the addition of elements to the original Resource, including the Embedding of other Resources. Changes can be made temporarily to the original Resource in the course of the Enhance process, but such changes are not saved in the original Resource at the end of the process.|
|Enlarge||To Modify a Resource by adding to it. With Enlarge, a single Resource is preserved at the end of the process. Changes can include the addition of new material, including the Embedding of other Resources, but not the changing or removal of existing elements of the original Resource.|
|execute||Execute||To execute a DigitalResource. Execute refers to the primitive computing process of executing. Execute applies only to a DigitalResource.|
|install||Install||To follow the instructions provided by an InstallingResource. An InstallingResource is a Resource that provides instructions which when followed result in one or more Resources that are new, or Enabled, or both new and Enabled.|
|Modify||To Change a Resource, preserving the alterations made. With Modify, a single Resource is preserved at the end of the process (that is, no additional Resource(s) come into existence). Changes can include the addition to and removal of elements of the original Resource, including the Embedding of other Resources within it. Specializations of Modify can be differentiated by specific attributes of the Resource being preserved or changed. The specific attributes can be on a list or can be called out by using a list. Lists can be inclusive (for example, "Attributes a and b must be changed") or exclusive (for example, "Everything except attributes c and d must be changed"). Attributes that are not constrained in specializations can be changed.|
|Move||To relocate a Resource from one Place to another. With Move, at least the location of the Resource is Changed.|
|play||Play||To Derive a Transient and directly Perceivable representation of a Resource. Play covers the making of any forms of Transient representation that can be Perceived directly (that is, without any intermediary process) with at least one of the five human senses. Play includes playing a video or audio clip, displaying an image or text document, or creating Transient representations that can be touched, or Perceived to be touched. When Play is applied to a DigitalResource, content can be rendered in any order or sequence according to the technical constraints of the DigitalResource and renderer.|
|To Derive a Fixed and directly Perceivable representation of a Resource. Print refers to the making of a Fixed physical representation, such as a hard-copy print of an image or text, that can be Perceived directly (that is, without any intermediary process) with one or more of the five human senses.|
|Reduce||To Modify a Resource by taking away from it. With Reduce, a single Resource is preserved at the end of the process. Changes can include only the removal of existing elements of the original Resource.|
|uninstall||Uninstall||To follow the instructions provided by an UninstallingResource. An UninstallingResource is a Resource that provides instructions which when followed result in one or more Resources that had previously been Installed being Disabled or Destroyed.|
Not all Rights that were explicitly included in XrML 2.0 are in MPEG-21, although it may be possible to combine some MPEG-21 Rights to create those same XrML 2.0 rights. (kc: I will continue to investigate these to see if there are ways to accomplish them in MPEG-21. At the moment I'm not sure about most of them.) Not included in MPEG-21 are:
The Open eBook Forum (OeBF), a group developing standards and business models for the ebook industry, voted to accept the MPEG-21 REL as its rights language standard. The committee decided to accept the MultiMedia Extension as its base, and to extend that with their own additions to the language. The OeBF extension to MPEG-21 Part 5 does not add, nor delete, any rights. It does add one new "principal" [kc: essentially a noun] for the Clipboard, which is defined as:
"Typically, a user may "copy" or mx:adapt a Resource to oebx:Clipboard, leaving the original Resource intact. The user may then "paste" or mx:embed the copied Resource or cut oebx:Portion from oebx:Clipboard, inserting it into the same or another Resource.
In these cases, oebx:Clipboard may be used as the Principal of the mx:Source and mx:Destination Condition to restrict the repository which content can be moved from and to, respectively. A Grant that allows "copy to clipboard" may specify mx:adapt as the Right and mx:destination as the Condition where mx:destination/mx:principal is oebx:Clipboard. A Grant that allows "paste from clipboard" may specify mx:enlarge as the Right. The mx:enlarge Right identifies the act of modifying a Resource by adding to it. Using this Right, Alice can add materials to the ebook,including pasting content from the clipboard."
It also adds some extensions to the Conditions in MPEG-21 that make it possible to designate rights that can be exercised with periodicity, such as "every 2 weeks" and to define portions and units, like "chapter" or "page."
In addition a condition is created called "TextToSpeechOff" that is particular to the ebook trade; many publishers of ebooks do not allow the text to be interpreted by a text-to-speech function in the ebook software because they interpret this as a violation of the performance rights of their book contract (and as competition to their audio book sales?). The TextToSpeechOff condition is necessary because the MPEG-21 REL verb Play, which allows the text to be displayed on a screen, would also allow the text-to-speech function of ebook software.
Although lending and in particular library lending was one of the requirements of the OeBF rights language, no "loan" right was added to the OeBF extension. Instead, it was suggested that lending could be accomplished through specialized services that would track lending. Although such services are possible (and there are lending services for ebooks in use in libraries today), this does mean that the loan right is outside of the standard language.
 Stefik, Mark. "Trusted Systems," Scientific American, 276(3):78-81. [back]
 Ibid. [back]
 Digital Property Rights Language, Manual and Tutorial - XML Edition. Version 2.0., 1998. Xerox Corporation. p. 5 http://www.oasis-open.org/cover/DPRLmanual-XML2.html [back]
 Ibid, p. 7 [back]
 Ibid, p. 7 [back]
 Stefik, Mark J., Inventor. System for Controlling the Distribution and Use of Digital Works Having Attached Usage Rights Where the Usage Rights are Defined by a Usage Rights Grammar. US Patent 5,715,403, Feb. 3, 1998 [back]
 ContentGuard. [License Agreement Relating to the XrML Specification You Requested], accessed on 5/2/2000. Quote is from Introduction. Partial URL: http://184.108.40.206/xrml/XRMLSpecReq...40008&utc=UTC-20000502155129+%28UTC%29& [back]
 Ibid. Section B.3. Partial URL: [back]
 ContentGuard. eXtensible rights Markup Language (XrML) 2.0 Specification; Part 1: Primer. 20 November, 2001. p. 8. http://www.xrml.org/get_XrML.asp [back]
 ContentGuard. About XrML. 2004. http://www.xrml.org/about.asp [back]
 Ibid [back]
Cover, Robin. Digital Property Rights Language (DPRL). http://www.oasis-open.org/cover/dprl.html
Cover, Robin. eXtensible Rights Markup Language (XrML). http://xml.coverpages.org/xrml.html
LaMacchia, Brian. Key Challenges in DRM: An Industry Perspective. Presented at 2002 ACM Workshop on Digital Rights Management, Washington, D.C., November, 2002. http://www.farcaster.com/papers/drm2002/drm2002.pdf
McAllister, Neil. Freedom of Expression: Emerging standards in rights management. New Architect Magazine, March 2002. http://www.newarchitectmag.com/documents/s=2453/new1011651985727/index.html
Rosenblatt, Bill. Extensible Rights Management Language (XrML) 2.0. November 28, 2001. http://www.drmwatch.com/special/article.php/3095201
Stefik, M. (1996). The Digital Property Rights Language. Manual and Tutorial. Version 1.02, September 18th. Xerox Palo Alto Research Center, Palo Alto, CA.
Stefik, Mark. "Trusted Systems," Scientific American, 276(3):78-81.
Stefik, Mark, and Alex Silverman. 1997. http://www.xrml.org/reference/Pendulum97Jul29.pdf
Xerox Corporation. The Digital Property Rights Language Manual and Tutorial - XML Edition. Version 2.00 — November 13, 1998. http://www.oasis-open.org/cover/DPRLmanual-XML2.html