Available formats: HTML and PDF. In case of a discrepancy, the HTML is considered definitive.
NOTE: To enable interactive browsing of the XrML schemas and examples, the XrML Specification and its companion Example Use Cases document use an HTML version that leverages the XML access functionality provided by the W3C Xpath recommendation. For this reason, you need to view these HTML documents with a browser that supports that recommendation (for example, Internet Explorer Version 6.0). If your browser does not support this functionality, please view the PDF versions of those documents.
Copyright © 2001 ContentGuard Holdings, Inc. All rights reserved. "ContentGuard" is a registered trademark and "XrML", "eXtensible rights Markup Language", the XrML logo, and the ContentGuard logo are trademarks of ContentGuard Holdings, Inc. All other trademarks are properties of their respective owners.
Part III: Standard Extension Schema
Part IV: Content Extension Schema
6.1.2 StateReferenceValuePattern
6.1.3 The ExerciseLimit Condition
6.1.4 The SeekApproval Condition
6.1.5 The TrackReport Condition
6.1.6 The TrackQuery Condition
6.1.7 The ValidityIntervalFloating Condition
6.1.8 The ValidityTimeMetered Condition
6.1.9 The ValidityTimePeriodic Condition
6.1.9.1 ValidityTimePeriodic/start
6.1.9.2 ValidityTimePeriodic/period
6.1.9.3 ValidityTimePeriodic/phase
6.1.11 The Territory Condition
6.1.11.1.1 Territory/location/region
6.1.11.1.2 Territory/location/country
6.1.11.1.3 Territory/location/state
6.1.11.1.4 Territory/location/city
6.1.12 State Interaction Elements
6.2 Payment and its Extensions
6.2.5.1 PaymentPerInterval/rate
6.2.6.2 PaymentPerUse/allowPrePay
Some concepts arise commonly in many XrML usage scenarios, but the elements and types that are used to capture them do not really belong in the core. The extensions defined in the Standard Extension are classified according to the purpose that they serve. They are broadly classified into conditions, payment notions, name, and revocation extensions.
Condition Extensions
The standard extension schema defines nine extensions of the type
Condition
. Of these, six extensions require a notion of communication with
an external authoritative value. To facilitate the definition of these
extensions, a type StatefulCondition
is
defined as well. Condition extensions are constructed either by extending
StatefulCondition
type or by directly extending the
Condition
type.
Naturally, what it means for a condition extension to be satisfied is left
to its description.
Some conditions may be tied to an external authoritative piece of data.
These arise when the exercise of a right is predicated upon querying or
manipulating the value of this external piece of data. For example, the
number of times some content may be rendered can be bounded by some value.
To cover such usages, XrML2.0 standard extension defines a
type called StatefulCondition
. The type is an extension of the
type Condition
defined in the core. It includes a child element
stateReference
, which indicates the means with which
communication is made
with the state or service. The state holds the piece of data and returns it
in the form of one or more XML nodes when queried for its value. The schema
that describes the XML nodes returned by the state is left to the specific Condition
that extends StatefulCondition
. Manipulations of the state value
must also be permitted. Elements of type StatefulCondition
(or a derivation
thereof) must define specifically their interaction with the state.
The element stateReference
indicates the means by which the state is to be
queried or manipulated. It has type ServiceReference
as defined in the core.
StateReferenceValuePattern
stateReferenceValuePattern
The element stateReferenceValuePattern
specifies an unbounded number of
XML element nodes. This element matches a stateReference
if and only if for every
XML element node that is a sub element of the stateReferenceValuePattern
element, there exists an identical XML element node in the set of XML
element nodes returned by the state designated by the stateReference
, when
queried for its value.
The element stateReferenceValuePattern
is typically used with the
obtain
element. When the right
to
obtain
a grant
with a stateful condition is issued,
then to specify the initial values the state value happen to take, a
stateReferenceValuePattern
is created containing the XML nodes that
correspond to the desired state value. This ensures that only stateReference
s whose designated states have the requisite state values
appear in the obtained grant
.
The following example illustrates a grant
issued to Alice that allows her
to obtain another grant
to play "A Clockwork Orange" up to twenty times. The
obtained grant
uses the stateful condition ExerciseLimit
.
ExerciseLimit
exerciseLimit
Sometimes grant
s have an upper bound on the number
of times the associated rights may be exercised. This
can be a certain number of times a document may be printed or the
number of times a piece of music may be played. The element exerciseLimit
captures these cases.
The element has type ExerciseLimit
, which is based on StatefulCondition
. Typically,
all of the information needed to evaluate an exerciseLimit
condition is
obtained by querying the state designated by stateReference
, including the
initial value of the limit associated with the grant
.
When a right conditioned by exerciseLimit
is exercised, the state
designated by the stateReference
in exerciseLimit
is queried
for its value. The state returns count
containing an
integer
value c
.
Upon exercise of the right, the value of the state is updated to return
count
containing c - 1
hereon.
The exerciseLimit
condition is satisfied if and only if c
is greater than
zero and the value of the state is updated as described above.
In the following example, Alice may print
the book, but only for a certain
number of times.
exerciseLimit
SeekApproval
seekApproval
A grant
may have rights that may be exercised only upon specific approval
from a service.
The element seekApproval
of type SeekApproval
is used to model these cases.
seekApproval
is based on the type
StatefulCondition
. The exercise of
such a right typically involves querying the appropriate state for approval.
The means to connect to the state is made available with the child element
stateReference
.
When a right conditioned by seekApproval
is exercised, the state
designated by the stateReference
in seekApproval
is queried for its value.
The state returns approval
containing a
boolean
value b
.
The seekApproval
condition is satisfied if and only if b
is true.
In the following example, Alice may
print
the book, but only upon prior approval from the designated state
reference.
seekApproval
TrackReport
trackReport
This locally defined element is used to indicate what should happen if communication with the designated state should fail. With a setting of "lax" communication failures may be ignored and the right may be exercised, whereas a setting of "required" would prevent exercises. The default is "required".
The trackReport
condition requires that the exercise of the associated
right is reported to a designated state. The trackReport
element is based on the TrackReport
type, which is an extension
of StatefulCondition
. The means to
connect to the state is made available with the child element
stateReference
.
A child element, communicationFailurePolicy
,
allows the setting of policy regarding the exercise should
the communication with the state fail.
When a right conditioned by trackReport
is exercised, the state
designated by the stateReference
is notified of the exercise. The state
responds in some fashion to confirm the notification.
Except when the communicationFailurePolicy
is set to lax
,
the trackReport
condition is satisfied if and only if the state is successfully
notified of the exercise of the right. Note that trackReport
does not define
how the state records the report. This may be done with a boolean
value or
an integer
value.
In the following example, Alice has the right to print
a book, but the
exercise of that right must be reported.
trackReport
TrackQuery
trackQuery
The
trackQuery
condition
represents a condition on a specific value that a state holds.
The trackQuery
element is based on
the TrackQuery
type, which is an extension of
StatefulCondition
. The means to
connect to the state is made available with the child element
stateReference
.
For the trackQuery
condition to be satisfied the state must have a value
within the range is specified by two child elements notMoreThan
and
notLessThan
.
When a grant
conditioned by trackQuery
is exercised, the state designated
by the stateReference
is queried for its value. The state returns
count
containing an integer
v
.
The trackQuery
condition is satisfied if and only if v
lies between
the values contained in notMoreThan
and notLessThan
.
In the following example, Alice can print
the
book only when the designated state value is between five and ten.
trackQuery
TrackQuery
is commonly used together with trackReport
, to model exercise
of rights predicated on the exercise of other rights. The following example
demonstrates one such usage. The idea is that Alice may listen to a piece of
music as many times as she pleases provided she has listened to some
commercial. The grant
related to the commercial has a trackReport
condition. When Alice attempts to
listen to the piece of music, the trackQuery
condition herein allows exercise of the right only when the state value tracked
by the trackReport
condition has a value greater than zero.
ValidityIntervalFloating
ValidityIntervalFloating
ValidityIntervalFloating
is a temporal condition that is used to indicate
for what length of time a right may be exercised. For example, we may speak
of a grant
that provides a right that can be exercised for one week. The element
validityIntervalFloating
is based on
the type ValidityIntervalFloating
, which is based on
StatefulCondition
. The semantic of the
condition expressed is that the interval of exercise of the right to which a
validityIntervalFloating
is applied must lie wholly
within some contiguous duration of time.
When a right conditioned by validityIntervalFloating
is exercised, the
state designated by the stateReference
is
queried for its value. The state returns EITHER a)
validUntil
holding a
dateTime
value v
OR b) validFor
holding a
duration
value d
.
It the state returns d
, and the right is currently to be exercised,
then it is updated to return validUntil from hereon with a value equal to c + d
, where c
is
the current time.
The validityIntervalFloating
condition is satisfied if and only if the interval of
exercise of the right lies wholly within the interval {from: c, to: v}
or within the interval {from: c, to: c+ d}
In the following example, Alice can exercise the right to print
the book
only when time has not run out of the state clock.
validityIntervalFloating
ValidityTimeMetered
validityTimeMetered
A locally defined element of type integer
. It serves to indicate the
period with which the metered time is measured. For example, a quantum of
one hour would meter every usage to the closest hour.
The validityTimeMetered
condition that is used to indicate for
what non-contiguous length of time a right may be exercised. Unlike the
validityIntervalFloating
condition, the length in question only takes into
account the periods of time of actual exercise. For
example, a user may be granted the right to play music clips from a catalog for a cumulative period
of one hour; the user may exercise this right by playing, say, twelve
five-minute clips over a week, or over a month. The element validityTimeMetered
has type ValidityTimeMetered
, which is an extension
of
StatefulCondition. The means to connect to the state is made with the child
element stateReference
.
Upon exercise of a right conditioned by validityTimeMetered
, beginning
with the moment of exercise, at regular intervals of quantum q
units
of time, the state designated by the stateReference
is queried for its
value. Suppose at interval i
the state returns
validFor containing a duration
value di.
Then, the state is updated to return di
- q
hereon. This continues until the value of di
is
lesser than q
, or when the interval of exercise of the right is
complete.
The validityTimeMetered
condition is said to be satisfied at interval
i
if and only if di
is greater than q
.
In the following example, Alice can exercise the right to read the book only when time has not run out on the designated state clock.
validityTimeMetered
ValidityTimePeriodic
validityTimePeriodic
A locally defined element of type
dateTime
. Indicates the start of the
time, typically date, from which the periods designated in this right become
meaningful.
A locally defined element of type
duration
. This indicates the frequency
with which the exercise time window recurs.
A locally defined element of type
duration
. This is used to indicate a
period of latency before beginning each time window. When this value
is positive then it directly specifies the duration of latency. When this
value is negative, then the duration of latency is equal to the length of
period minus the absolute value specified herein.
A locally defined element of type
duration
. This indicates the actual
length of the time window.
A locally defined element of type integer
. Indicates a bound on the
number of time windows. This element is optional.
Sometimes grant
s may predicate
rights to be exercisable on a periodic basis, such as "every weekend
after Jan 1 2001 for a total of ten times". That is following some
starting date, a time window of exercise periodically recurs. Such
conditions are expressed using the validityTimePeriodic
element. The element validityTimePeriodic
has type ValidityTimePeriodic
, which is an extension of
Condition. The child
element start marks the starting date for this condition to become relevant.
The child element period indicates how often this time window should recur.
The length of the duration is indicated by the element duration. An optional
element phase is used to mark latency from the beginning of the period.
Formally, let s
be the
start time, h
the phase, d
the duration
and c
the count. Then the interval of exercise of the right must fall
in one of the intervals described by the expression {from:s + i*p + h,
to: s + i*p + h + d}
where the value of i
ranges from 0 to c - 1
if
h
is positive and ranges from 1
to c
if h
is
negative. If c
is unspecified then i
is unbounded.
In the following example,
starting January 1st 2001, Alice may print
the book only on the first two days
of the second week of every month. Furthermore, this right lapses after
twelve
months.
validityTimePeriodic
The negative phase can be used to capture certain interesting periods.
For example, on Memorial day, people who are veterans may watch the movie
"Pearl Harbor" for free. Memorial day is the last Monday of May. So we
combine three validityTimePeriodic
conditions. The first one captures the
last week of every month, the second one captures the month of May and the
final one captures all Mondays beginning Jan 1 2001.
validityTimePeriodic
Astute readers will note that Memorial Day can actually be characterized without the usage of phase.
validityTimePeriodic
Fee
fee
This element of type paymentAbstract
is abstract. It is meant to be
substitutable
.
For more details and examples of extensions see
paymentAbstract
.
This locally defined optional element contains a
paymentAbstract
element. It specifies
the minimum amount due the fee
recipient. If the total amount paid is less
than the value of this element, a new payment in the amount of the
difference is due.
This locally defined optional element contains a
paymentAbstract
element. It specifies
the maximum amount due the fee
recipient. If the total amount paid is
greater than the value of this element, a new credit in the amount of the
difference is due. If the total amount paid is equal to the value of this
element all other payments resulting from this fee
are void until the value
of max increases.
This locally defined element is of type of AccountPayable
. It indicates the
party to whom, and the means by which, payment is to be made. To allow
for the rare cases where this is discovered from context, this element is
left optional.
AccountPayable
is used to identify a party to whom one can transfer a sum
of money, along with an identification of the means by which such a transfer
is to take place. While there are undoubtedly many ways this can be done,
two ways are explicitly defined. The type AccountPayable
is defined as a
choice between three options. The first, a paymentService
, identifies the
party to whom the payment is made. The second option, aba
, identifies
a bank in the US banking system. As a provision to support other
forms of banking mechanisms, an option is made for specifying other
banking means as well. This is realized by the any
element.
AccountPayable
The locally defined element ServiceReference
.
This identifies the party to whom the payment is to be made, and
the interface to the service indicates the necessary payment mechanism.
The locally defined element identifies an account within a US banking institution by means of conventions established by the American Banking Association. It defines two child elements, institution and account. The banking institution is identified by its nine-digit banking routing number using the institution. The account within that institution is identified with account.
A grant
can predicate that a fee
be paid before a right can be exercised.
Typically fee
s involve a payment, and a designation of the party the payment
is made to. Options about what form the payment should take (such as
periodic or one-time or usage-based or metered) are reflected by the paymentAbstract
element.
The fee
element is of
type Fee
, which is an extension
of Condition. A child element
to
of
type AccountPayable
is used to characterize both the payment and the payee.
There are two other optional elements. The optional
min
price specification indicates the minimum price to be
paid if the right is
exercised at all. The optional max
price specification
refers to the maximum price to be paid if the right is exercised at all.
When both a maximum and minimum price specifications are given, the maximum
price specification dominates.
Suppose that the fee
s
in payment, min
and max
independently amount to p
, min
and
max
respectively due for the exercise of the associated right as
defined by the respective payment extension. Then, x
is min
if
p <=
min
<
max
; x
is p
if
min
< p<
max
;
x
is max
if min
<
max
< p
. Then the fee
condition is
satisfied if and only if the amount x
is paid to the entity
identified by
to
Not all forms of payment extensions are directly comparable. For the fee
condition to be sensibly evaluated, it is necessary that the payment
extensions of the paymentAbstract
elements in payment, min and max are
comparable. In the standard extension, the
payment extensions either
contain state references or they do not. Stateful payment extensions are not
comparable with stateless ones. So it is required that the payment
extensions in payment, min and max are either all stateful or all stateless.
The corresponding fee
conditions are respectively termed as stateful and
stateless.
Territory
territory
The locally defined element location defines inline the optional elements
region
,
country
,
state
,
city
,
postalCode
and
street
that
designate a physical location.
The locally defined element region, as defined by its type RegionCode
, is
a three-letter ISO 3166 region code.
The locally defined element country, as defined by its type CountryCode
,
is a two-letter ISO 3166 country code.
The locally defined element state is a two-letter code for US states.
The locally defined element is of type
string
and designates a city.
The locally defined element postalCode
is of type
string
and
designates a postal code (e.g. a zip code).
The locally defined element street is of type string
and
designates a
street.
The locally defined element defines inline an element url
to designate a
digital location.
The locally defined element url
, has
type anyUri
and can be any uri.
Grants may sometimes predicate rights to be exercisable only in certain
locations. These locations may correspond to physical or geographical
regions, or they may correspond to virtual or digital locations. The element
territory
is used to specify such conditions.
territory
has type Territory
,
which is an extension of Condition
. The child element location is used to
indicate physical locations, and the child element domain indicates the
digital locations. Since the right may be exercisable in more than one
location, physical or digital, the content model for territory allows for an
unbounded number of children.
The territory
condition is satisfied if the exercise can be shown to be
occurring in at least one of the locations or domains.
In the following example, Alice may print
the book only if she is in the USA
or from a device in the www.xrml.org domain.
territory
conditionThe following elements are used by various elements of type
StatefulCondition
(or derivations thereof) to describe their interaction
with the state. Specifically, the state exchanges data using these elements.
This element of type boolean
is
used by seekApproval
.
This element of type integer
is
used by ExerciseLimit
,
trackQuery
and
paymentPerUse
.
This element of type
boolean
is used by paymentFlat
.
This element of type
duration
is used by validityIntervalFloating
and validityTimeMetered
.
This element of type dateTime
is
used by validityIntervalFloating
and paymentPerInterval
.
The notion of payment is left abstract in XRML2.0. The element paymentAbstract
has type
PaymentAbstract
.
The type PaymentAbstract
does not define any specific sub-elements.
In
its place more concrete forms of payment such as paymentFlat
,
bestPriceUnder
, callForPrice
,
markup
etc. are to be used. The standard extension defines seven different
kinds of payments. Each of these defines its own notion of when a
payment has been made that work toward the fee
condition being
satisfied. Since payment extensions themselves are not conditions, we
introduce a notion of fulfillment. For a fee
condition to be satisfied, the
payment extension must be fulfilled. Each payment extension describes the semantic of
its fulfillment.
Payment Extensions
PaymentAbstract
paymentAbstract
Cash
PaymentFlat
paymentFlat
This locally defined element of type Cash
indicates the amount to be paid
to exercise the right.
This locally defined element contains a stateReference
that holds a value.
This value is
true if payment has been made, and false otherwise.
Some rights may be exercised upon the payment of a one-time fee
. For
example, purchasing a song. The paymentFlat
element of
type PaymentFlat
is used to describe such payments. A
local element rate is used to indicate the amount to be paid and another
element paymentRecord
is used to designate a state which holds the
information whether the payment has been made.
When a right conditioned upon a paymentFlat
fee
is exercised, the state
designated by PaymentFlat
/
paymentRecord
/stateReference
is queried for its
value. The
state returns paid
holding a
boolean
value b
.
When a payment of amount as designated by
rate
is made, the state is updated
to return paid
set to true.
The paymentFlat
payment is fulfilled if b
is true.
In the following example, Alice may listen to "La Bamba" provided she makes a one-time payment of $5.
paymentFlat
PaymentMetered
paymentMetered
This locally defined element of type Cash
, together with the element
per
,
indicates the charge per period.
This locally defined element of type
duration
indicates the period
available for the payment of the rate
.
This locally defined element of type
duration
indicates
the quantum by which time is measured for the computation of the amount.
This locally defined element of type
duration
is used for rounding
purposes. It indicates what portion of time may elapse before someone is
billed for the whole duration defined with
by
.
Some rights may be exercised upon the payment of a fee
that is prorated
according to the duration of usage. For example, one may have the right to
play a game and pay a fee
according dictated by the length of time one plays
the game. The paymentMetered
element of
type PaymentMetered
is used to
describe such payments. A local element
rate
, with another element
per
, is
used to designate the basic cost. Another element
by
is used to describe the
granularity with which time is measured. Finally, the element
phase
is
used for rounding the units of time that are smaller than the duration
described by the by
element; a value of zero would have the effect of
rounding up, and a value of the duration described in the
by
element would
have the effect of rounding down.
Formally, after normalizing all of the duration values to seconds,
suppose the rate
is r
,
per
in seconds is p
,
by
in seconds is b
,
and phase
in seconds is
h
.
Then, if the interval of exercise of the right is t
seconds,
then the payment due is given by the expression r*[b/p]*[floor(t/b) +
round]
where round
t%b is greater than
h
and is zero otherwise.
In the following example, Alice may play a game but is charged a daily rate of 24$/day. This rate is computed on an hourly basis. Furthermore, any usage of over thirty minutes is docked as an hour. So if Alice spends two hours and twenty-nine minutes playing, then she would end up paying $2 in all ($1 after 30 minutes and another dollar after 90 minutes). However, if she spends two hours and thirty-one minutes playing she would end up paying $3 in all (yet another dollar after 150 minutes).
PaymentMetered
PaymentPerInterval
paymentPerInterval
This locally defined element of type Cash
, indicates the amount to paid
for the allocation of an interval of time defined by
per
.
This locally defined element of type duration
, indicates the quantum
of time allocated with the payment of the amount in
rate
.
This locally defined element contains a stateReference
whose value is the
time through which the amount is paid.
Some rights may be exercised for a period of time that they are paid for.
For example, one may buy up some time to play a game and may keep playing
the game until it is paid for. The paymentPerInterval
element of type
PaymentPerInterval
is used to describe such payments. A local element
rate
,
with another element per
, is used to indicate the cost for a certain
duration of time. Another element
paidThrough
is used to record the time
until when the right may be exercisable.
When a right conditioned upon a paymentPerInterval
fee
is exercised, the
state designated by paymentPerInterval
/
paidThrough
/
stateReference
is
queried for its value. The state returns
validUntil
that contains a
dateTime
value t
. This marks
the time until when the right may be
exercised. For every payment currently made in the amount in
rate
, if t
is in the future then it is increased by the duration designated in the
per
element. Otherwise,
the value is set to a time that is per
duration from the global official
time (colloquially, the present time). The state is then updated to return
validUntil
containing the new value of t
.
The paymentPerInterval
payment is fulfilled if the interval of exercise
of the associated right is bounded by t
.
In the following example, Alice may play
her game and is charged a rate of
$5/day.
paymentPerInterval
PaymentPerUse
paymentPerUse
This locally defined element of type Cash
indicates the amount to be paid
for a certain number of uses, if specified by the element
initialNumberOfUses
,
otherwise it defines the amount to be paid for each use.
This locally defined optional element is used to allow for prepayments.
This optional element of type
integer
indicates the number of uses
each rate payment buys. If absent, the number of uses is one.
This locally defined element contains a stateReference
that indicates the
remaining number of uses.
Some rights may be exercised upon payment of a fee
for each use. For
example, one may have the right to listen to a piece of music provided a
payment is made for each listening. The element paymentPerUse
of type
PaymentPerUse
is used to describe such payments.
When a right conditioned upon a paymentPerUse
fee
is exercised, the state
designated by paymentPerUse/allowPrePay/prepaidUsesRemaining
is queried for
its value. The state returns count
containing
an
integer
value c
.
Upon exercise of the right, the value of the state is updated to return
count
containing c - 1
hereon. When
payment in the amount defined in the
rate
element is made, then state is updated to increment count
by the
initialNumberOfUses
value.
The paymentPerUse
payment is fulfilled if the value of c
is
greater than zero and the state is updated as described above.
In the following example Alice may print
the book five times provided she
pays $5.
paymentPerUse
BestPriceUnder
bestPriceUnder
bestPriceUnder
is a kind of payment that can be dynamic and is determined
when the account is settled. It is used to accommodate special deals,
rebates, and pricing that depends on information that is not available to
the trusted repository at the time the usage right is exercised, but without
communicating with a dealer before the purchase is authorized. A bestPriceUnder
specification limits the risk to the user by naming a maximum amount
that the exercising of the right will cost. This is the amount that is
tentatively charged to the account. However, when the transaction is
ultimately reconciled, any excess amount charged will be returned to the
user/copy-owner in a separate transaction.
The bestPriceUnder
element has type
BestPriceUnder
, which is an extension
of PaymentAbstract
. It has a child element
fee
which is used to indicate
the charge. The bestPriceUnder
element is defined to be in payment's
substitution group, and can be used wherever payment is expected.
In the following example, Alice may print
the book and will be charged
at most $5 to do it.
bestPriceUnder
CallForPrice
callForPrice
This optional element of type ServiceReference
indicates the location
where the negotiation may be supported. This may simply be a matter of
locating a dealer.
callForPrice
is similar to bestPriceUnder
in that it is intended to accommodate cases where
prices are dynamic. However, unlike bestPriceUnder
, communication with a dealer
to determine the price is required before the purchase is authorized; the
transaction cannot be completed if the trusted repository is unable to
communicate with the dealer.
callForPrice
is of type CallForPrice
, which is an extension of PaymentAbstract
. It can contain
possibly several location child elements. The location elements are used to
communicate with the dealers.
callForPrice
Markup
markup
This locally defined element is of type float. It indicates the fractional
rate at which markup
is calculated.
Implies a context in which multiple resources are being used simultaneously.
The total price for using the specified resource is calculated, and the
amount is paid as defined by any license agreements for that resource. The
price is then marked up by the rate specified in this markup
element, and
the markup is paid as specified by the containing fee
element. If the
specified resource is not used in conjunction with exercising this grant
,
this markup is not fulfilled and the containing fee
is not satisfied.
Markup
fee
s are fee
s that are computed as
a percentage of other fee
s. For example, a distributor may want to add a
flat ten percent overhead for selling copies of a digital work, or a
government may want to tax sales of a digital works.
The following example shows a license
granted to Alice (by some distributor) that allows Alice to issue a
grant
conditioned upon the payment of a marked-up
fee
. This allows Alice the
flexibility of setting her own fee
when issuing the grant
. The distributor
pockets the markup
of 10%.
markup
The following example shows two license
s
that may be exercised by a streaming media consumer. The first one is a
grant
to actually play the content for some
fee
, and the second is a
grant
to download the content from some repository for a markup of the fee
indicated in the first.
Together with the possessProperty
,
the resource Name
and its extensions
allow license
s to straightforwardly express authorized association of names with
principals. This is useful for modeling the X.509 certificate like binding
of names to principals. The standard extension defines four extensions
of the type Name
.
Name Extensions
Name
name
The name
element is of type Name
. This is an extension of the
abstract type Resource
.
Along with
the possessProperty
right,
the name
element being a
resource
can be used
in license
s to associate a
name with one or more principal
s.
Such license
s allow other
license
s to be
issued to, colloquially speaking, principal
s identified by their name.
The name
element is conceptually abstract and should not appear in an XrML
document except in the form of a variable reference.
The following example shows a license
which allows anyone who has the
name Alice, as authorized by the grant
in the prerequisite right, can watch "A
Clockwork Orange". This example illustrates how an extension of
name is used; note the use of commonName
to identify the authorized principal
.
name
extensionEmailName
emailName
The emailName
element is of type EmailName
. This is an extension of the
type Name
. Typically it contains a string that designates an internet
email address (per rfc822/2822). Like with
name
, license
s
can associate the element emailName
with principal
s by using the right
possessProperty
.
DnsName
dnsName
The dnsName
element is of type DnsName
.
This is an extension of the type Name
.
Typically it contains a string that designates a domain name. Like
with name
,
license
s can associate the
element dnsName
with principal
s
by using the
right possessProperty
.
CommonName
commonName
The commonName
element is of type CommonName
.
This is an extension of the
type Name
. Typically it contains a string that designates a colloquial
name. Like with name
,
license
s can associate the element
commonName
with principal
s by using the
right possessProperty
.
X509SubjectName
x509SubjectName
The x509SubjectName
element is of
type X509SubjectName
. This is an
extension of the type Name
.
Typically it contains a string that
designates a subject name from some X509 certificate. Like with
name
, license
s
can associate the element x509SubjectName
with
principal
s by using the right
possessProperty
.
X509SubjectNamePattern
x509SubjectNamePattern
The x509SubjectNamePattern
is of
type X509SubjectNamePattern
. This is an
extension of the type ResourcePattern
.
The x509SubjectNamePattern
is pattern
that matches an x509SubjectName
. Specifically it matches the root of the
x509SubjectName
tree. This element can be used to enforce constraints
similar to the X.509 specification.
The revocable
element of
type Revocable
, based on Resource
, is used with
the revoke
right.
Typically, to revoke a signature, a license
is issued
which identifies the principal
that has the right to revoke the signature specified by the revocable
element. The revocable
element identifies the signature either by its
literal value or by indirect means such as its cryptographic hash value.
The following example illustrates how Alice has the right to revoke
a specific signature. Note that the signature is
referred to by its cryptographic hash value.
revocable