Input: [Keyword] tel [State] Telephone [Control type] A text field [Data type]

Output: Text with no line breaks


Input: [Keyword] url [State] URL [Control type] A text field [Data type]

Output: An absolute IRI


Input: [Keyword] email [State] E-mail [Control type] A text field [Data type]

Output: An e-mail address or list of e-mail addresses


Input: [Keyword] password [State] Password [Control type] Text field that obscures data entry [Data type]

Output: Text with no line breaks (sensitive information)


Input: [Keyword] datetime [State] Date and Time [Control type] A date and time control [Data type]

Output: A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC


Input: [Keyword] date [State] Date [Control type] A date control [Data type]

Output: A date (year, month, day) with no time zone


Input: [Keyword] month [State] Month [Control type] A month control [Data type]

Output: A date consisting of a year and a month with no time zone


Input: [Keyword] week [State] Week [Control type] A week control [Data type]

Output: A date consisting of a week-year number and a week number with no time zone


Input: [Keyword] time [State] Time [Control type] A time control [Data type]

Output: A time (hour, minute, seconds, fractional seconds) with no time zone


Input: [Keyword] datetime-local [State] Local Date and Time [Control type] A date and time control [Data type]

Output: A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone


Input: [Keyword] number [State] Number [Control type] A text field or spinner control [Data type]

Output: A numerical value


Input: [Keyword] range [State] Range [Control type] A slider control or similar [Data type]

Output: A numerical value, with the extra semantic that the exact value is not important


Input: [Keyword] color [State] Color [Control type] A color well [Data type]

Output: An sRGB color with 8-bit red, green, and blue components


Input: [Keyword] checkbox [State] Checkbox [Control type] A checkbox [Data type]

Output: A set of zero or more values from a predefined list


Input: [Keyword] radio [State] Radio Button [Control type] A radio button [Data type]

Output: An enumerated value


Input: [Keyword] file [State] File Upload [Control type] A label and a button [Data type]

Output: Zero or more files each with a MIME type and optionally a file name


Input: [Keyword] submit [State] Submit Button [Control type] A button [Data type]

Output: An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission


Input: [Keyword] image [State] Image Button [Control type] Either a clickable image, or a button [Data type]

Output: A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission


Input: [Keyword] reset [State] Reset Button [Control type] A button [Data type]


Input: [Keyword] button [State] Button [Control type] A button [Data type]


Input: [Identifier] Agreement [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment]

Output: Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.1: Terms for the entity Type of the Policy Entity


Input: [Identifier] Offer [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment]

Output: Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Privacy [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment]

Output: Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Request [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment]

Output: Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Set [Semantics] Policy expressions that consists of entities from the complete model [Comment]

Output: The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Ticket [Semantics] Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession [Comment]

Output: May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known).

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Property] additionalType (added) [Description] An additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax. [Expected Type]

Output: URL


Input: [Property] description [Description] A short description of the entry. [Expected Type]

Output: Text


Input: [Property] image [Description] URL of an image of the entry. [Expected Type]

Output: URL


Input: [Property] name [Description] The name of the entry. [Expected Type]

Output: Text


Input: [Property] url [Description] URL of the entry. [Expected Type]

Output: URL


Input: [Property] alternativeHeadline [Description] A secondary title of the entry. [Expected Type]

Output: Text


Input: [Property] inLanguage [Description] The language of the content. Please use one of the language codes from the IETF BCP 47 standard. [Expected Type]

Output: Language


Input: [Property] dateCreated [Description] The date on which the content was created (in ISO 8601 date format). [Expected Type]

Output: Date


Input: [Property] dateModified [Description] The date on which the content was most recently modified (in ISO 8601 date format). [Expected Type]

Output: Date


Input: [Property] keywords [Description] The keywords/tags used to describe this content. [Expected Type]

Output: Text


Input: [Property] provider [Description] Specifies the person or organization that distributed the content. [Expected Type]

Output: Person or Organization


Input: [Property] breadcrumb [Description] A set of links that can help a user understand and navigate a website hierarchy. [Expected Type]

Output: Text


Input: [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Identifier]

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Identifier]

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Identifier]

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Identifier]

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that consists of entities from the complete model [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Identifier]

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Identifier]

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Value] terminology [Example] The localization had “Pen Drive” when corporate terminology specified that “USB Stick” was to be used. The localized text inconsistently used "Start" and "Begin". A text renders the Hungarian term recsegőhid as “buzzer bridge” in English (a literal translation), but the term to be used in English is “wedge block,” as specified in a terminology list supplied to the translator. [Scope] S or T [Notes] This value is not intended for simple typographical errors or word choice not related to defined terminologies. For example, a mistyping of “pin” as “pen” or the use of “imply” instead of “infer” (mistaking two commonly confused words) would not count as terminology issues and is best categorized as either spelling errors or mistranslations, depending on the nature of the issue. Terminology refers only to cases where incorrect choices about terms (either formal or commonly defined in a domain) are involved. [Description]

Output: An incorrect term or a term from the wrong domain was used or terms are used inconsistently.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] mistranslation [Example] The English source reads "An ape succeeded in grasping a banana lying outside its cage with the help of a stick" but the Italian translation reads "l'ape riuscì a prendere la banana posta tuori dall sua gabbia aiutandosi con un bastone" ("A bee succeeded...") [Scope] T [Notes] Issues related to translation of specific terms related to the domain or task-specific language are to be categorized as terminology issues. [Description]

Output: The content of the target mistranslates the content of the source.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] omission [Example] One or more segments found in the source that have been intended for translation are missing in the target. After an alignment, a verification tool flags the pairs of aligned segments where the target has no corresponding source because of incorrect segmentation or some alignment issue. In such case the 'omission' type may apply to the source entry. [Scope] S or T [Notes] This value is not to be used for missing whitespace or formatting codes, but instead has to be reserved for linguistic content. [Description]

Output: Necessary text has been omitted from the localization or source.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] untranslated [Example] The source segment reads "The Professor said to Smith that he would hear from his lawyer" but the Hungarian localization reads "A professzor azt mondta Smithnek, hogy he would hear from his lawyer." [Scope] T [Notes] omission takes precedence over untranslated. Omissions are distinct in that they address cases where text is not present, while untranslated addresses cases where text has been carried from the source untranslated. [Description]

Output: Content that has been intended for translation is left untranslated.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] addition [Example] The translated text contains a note from the translator to himself to look up a term; the note ought to have been deleted but was not. [Scope] T [Description]

Output: The translated text contains inappropriate additions.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] duplication [Example] A section of the target text was inadvertently copied twice in a copy and paste operation. [Scope] T [Description]

Output: Content has been duplicated improperly.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] inconsistency [Example] The text states that an event happened in 1912 in one location but in another states that it happened in 1812. The translated text uses different wording for multiple instances of a single regulatory notice that occurs in multiple locations in a series of manuals. [Scope] S or T [Description]

Output: The text is inconsistent with itself or is translated inconsistently (NB: not for use with terminology inconsistency).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] grammar [Example] The text reads "The guidelines says that users should use a static grounding strap." [Scope] S or T [Description]

Output: The text contains a grammatical error (including errors of syntax and morphology).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] legal [Example] The localized text is intended for use in Thailand but includes U.S. regulatory notices. A text translated into German contains comparative advertising claims that are not allowed by German law. [Scope] S or T [Description]

Output: The text is legally problematic (e.g., it is specific to the wrong legal system).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] register [Example] A financial text in U.S. English refers to dollars as "bucks". [Scope] S or T [Description]

Output: The text is written in the wrong linguistic register of uses slang or other language variants inappropriate to the text.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-specific-content [Example] A text translated for the Japanese market contains call center numbers in Texas and refers to special offers available only in the U.S. [Scope] S or T [Notes] Legally inappropriate material is to be classified as legal. [Description]

Output: The localization contains content that does not apply to the locale for which it was prepared.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-violation [Example] A text localized into German has dates in mm/dd/yyyy format instead of DD.MM.YYYY. A text for the Irish market uses American-style foot and inch measurements instead of centimeters. A text intended for a U.S.-based audience uses U.K. spellings such as “centre” and “colour.” [Scope] S or T [Notes] This value can be used for spelling errors only if they relate specifically to locale expectations (e.g., a text consistently uses British instead of U.S. spellings for a text intended for the U.S.). If these errors are not systematic (e.g., a text uses U.S. spellings but has a single instance of “centre”), they are instead to be counted as spelling errors. [Description]

Output: Text violates norms for the intended locale.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] style [Example] Company style guidelines dictate that all individuals be referred to as Mr. or Ms. with a family name, but the text refers to “Jack Smith”. [Scope] S or T [Description]

Output: The text contains stylistic errors.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] characters [Example] A text ought to have a '•' but instead has a '¥' sign. A German text erroneously uses û, ô, and â instead of the appropriate 'ü', 'ö', and 'ä'. A Japanese text has been garbled and appears with Devanagari characters. [Scope] S or T [Notes] Characters ought to be used in cases of garbling or systematic use of inappropriate characters, not for spelling issues where individual characters are replaced with incorrect one. [Description]

Output: The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] misspelling [Example] A German text misspells the word "Zustellung" as "Zustlelung". [Scope] S or T [Description]

Output: The text contains a misspelling.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] typographical [Example] An English text has the following sentence: "The man whom, we saw, was in the Military and carried it's insignias". [Scope] S or T [Description]

Output: The text has typographical errors such as omitted/incorrect punctuation, incorrect capitalization, etc.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] formatting [Example] Warnings in the text are supposed to be set in italic face, but instead appear in bold face. Margins of the text are narrower than specified. [Scope] S or T [Description]

Output: The text is formatted incorrectly.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] inconsistent-entities [Example] The name "Thaddeus Cahill" appears in an English source but is rendered as "Tamaš Cahill" in the Czech version. The date "February 9, 2007" appears in the source but the translated text has "2. September 2007". [Scope] S or T [Description]

Output: The source and target text contain different named entities (dates, times, place names, individual names, etc.)

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] numbers [Example] A source text states that an object is 120 cm long, but the target text says that it is 129 cm. long. [Scope] S or T [Notes] Some tools may correct for differences in units of measurement to reduce false positives (e.g., a tool might adjust for differences in values between inches and centimeters to avoid flagging numbers that seem to be different but are in fact equivalent). [Description]

Output: Numbers are inconsistent between source and target.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] markup [Example] The source segment has five markup tags but the target has only two. An opening tag in the text is missing a closing tag. [Scope] S or T [Description]

Output: There is an issue related to markup or a mismatch in markup between source and target.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] pattern-problem [Example] The tool disallows the regular expression pattern ['"”’][\.,] but the translated text contains "A leading “expert”, a political hack, claimed otherwise." A tool uses a regular expression to ensure that the content of an element is an IRI and flags what appears to be a malformed IRI. [Scope] S or T [Notes] Defining what is or is not an allowable pattern is up to the processing application and is beyond the scope of this specification. Best practice would be to use the Comment attribute to specify the pattern that led to the issue. [Description]

Output: The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] whitespace [Example] A source segment starts with six space characters but the corresponding target segment has two non-breaking spaces at the start. The text uses a run of 12 space characters instead of a tab character to align numbers in a table. Two space characters appear after a period even though only a single space is to be used. [Scope] S or T [Description]

Output: There is a mismatch in whitespace between source and target content or the text violates specific rules related to the use of whitespace.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] internationalization [Example] A line of programming code has embedded language-specific strings. A user interface element leaves no room for text expansion. A form allows only for U.S.-style postal addresses and expects five digit U.S. ZIP codes. [Scope] S or T [Notes] There are many kinds of internationalization issues. This value is therefore very heterogeneous in what it can refer to. [Description]

Output: There is an issue related to the internationalization of content.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] length [Example] The translation of a segment is five times as long as the source. [Scope] S or T [Notes] What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef. [Description]

Output: There is a significant difference in source and target length.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] non-conformance [Example] The sentence "The harbour connected which to printer is busy or configared not properly." would have poor conformance. [Scope] S or T [Notes] Non-conformance is determined through the use of multiple statistical measures of similarity to a corpus of known-good content. For example, in a system that uses classification techniques the poor conformance might be a function of combined incorrect terminology, wrong spelling and bad grammar, or other features as determined by the system. [Description]

Output: The content is deemed to show poor statistical conformance to a reference corpus. Higher severity values reflect poorer conformance.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] uncategorized [Example] A new version of a tool returns information on an issue that has not been previously checked and that is not yet classified. A text is defective in ways that defy categorization, such as the appearance of nonsense garbled text of unknown origin (e.g., a translation shows an unintelligible result and/or appears unrelated to the source material). [Scope] S or T [Notes] This value has the following uses: A tool can use it to pass through quality data from another tool in cases where the issues from the other tool are not classified (for example, a localization quality assurance tool interfaces with a third-party grammar checker). A tool’s issues are not yet assigned to values, and, until an updated assignment is made, they may be listed as uncategorized. In this case it is recommended that issues be assigned to appropriate values as soon as possible since uncategorized does not foster interoperability. uncategorized can be used where a portion of text is defective in a way that defies assignment to a value in either the originating system or in any other ITS localization quality markup to indicate that it is uncategorizable. [Description]

Output: The issue either has not been categorized or cannot be categorized.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] other [Scope] S or T [Notes] This value allows for the inclusion of any issues not included in the previously listed values. It is encouraged not to use this value for any tool- or model-specific issues that can be mapped to the values listed above. In addition, this value is not synonymous with uncategorized in that uncategorized issues may be assigned to another precise value, while other issues cannot. If a system has an "miscellaneous" or "other" value, it is better to map this to this value even if the specific instance of the issue might be mapped to another value. [Description]

Output: Any issue that cannot be assigned to any values listed above.

Internationalization Tag Set (ITS) Version 2.0


Input: [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Identifier]

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Identifier]

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Identifier]

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Identifier]

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that consists of entities from the complete model [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Identifier]

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Identifier]

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Description] Describes the structural and functional purpose of an element. A Role is also a concept. [Role]

Output: roletype

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] Generic type for widgets that can have a value [Role]

Output: input

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] Generic type for the inputs that allow free-form text as their value [Role]

Output: textbox

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] A form control that allows the user to make selections from a set of choices [Role]

Output: select

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] Represents a range of values that can be set by the user. [Role]

Output: range

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] A logical part of a DeliveryUnit (page or a document) [Role]

Output: section

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] A heading without level [Role]

Output: sectionhead

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Description] Browser or application window [Role]

Output: window

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Requirement] Alarm API [Source] SysApps Charter [Description]

Output: Applications can create alarms, notifying users

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Contacts API [Source] SysApps Charter [Description]

Output: Apps can add, remove and edit contacts

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Messaging API [Source] SysApps Charter [Description]

Output: Apps can send, receive and view SMS

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Telephony API [Source] SysApps Charter [Description]

Output: Apps can access the telephony capabilities of the underlyling platform: dial a number, pick up a call, route to voicemail, access the call log

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Raw Sockets API [Source] SysApps Charter [Description]

Output: Apps can create, manipulate and listen for low-level TCP and UDP connections

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Supports many device form factors [Source] SysApps Charter [Implications] The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model. [Description]

Output: Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] DAP API Support [Source] SysApps Charter [Implications] Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls [Description]

Output: All APIs defined by DAP should be accessible to system applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Minimal user prompting [Source] SysApps Charter [Implications] Some details of the expected user interactions may need to be specified in the security model or APIs [Description]

Output: Problems such as 'double prompting' should be avoided when integrating other APIs

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] HTML5 [Description]

Output: Applications consist of HTML, CSS and JavaScript

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Location [Description]

Output: Applications have access to geolocation data

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Communicate with other applications [Implications] Some kind of messaging will be supported [Description]

Output: Applications can communicate with other applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Communicate with pre-defined endpoints [Implications] Access remote domains will be possible [Description]

Output: Applications can communicate with pre-defined web addresses

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Valid across multiple platforms [Source] Compatibility of application packages [Description]

Output: Applications can run on any conformant platform, potentially including any device form factor

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Access control log [Source] webinos [Description]

Output: Allow access control decisions to be logged.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] API access rationale [Source] webinos [Description]

Output: Applications shall be able to explain why access to data or APIs is being requested.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application capability restriction [Source] webinos [Description]

Output: Applications shall access only its specified device features, extensions and content.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application intent [Source] webinos [Description]

Output: Applications shall specify its required functionality at install time or during updates.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application isolation [Source] webinos [Description]

Output: Applications shall be isolated from each other.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Application policy approval [Source] webinos [Description]

Output: Changes to existing application intentions and permissions shall be approved by the end user.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Authenticity check [Source] webinos [Description]

Output: Before being installed or updated, origin authenticity and integrity checks shall be performed by the runtime

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Certifier list [Source] webinos [Description]

Output: The list of authorities that certified an application shall be viewable by end-users.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Confidential credentials storage [Source] webinos [Description]

Output: The webinos runtime shall support the confidential storage of user credentials.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Credentials access restriction [Source] webinos [Description]

Output: Access to credentials storage shall be limited to a specific user, a specific device and a set of applications.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Data management rationale [Source] webinos [Description]

Output: applications shall be able to explain how collected sensitive data will be managed.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Default policy [Source] webinos [Description]

Output: A default security and privacy policy shall exist an be enforced on each conformant runtime

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Device-identity binding [Source] webinos [Description]

Output: Personal devices shall be bound to their owner's identities.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Device-identity binding revokation [Source] webinos [Description]

Output: The binding between personal devices and owner's identity shall be revokable.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Hierarchical policy enforcement [Source] webinos [Description]

Output: Runtimes can enforce multiple access control rules written by multiple stakeholders in a hierarchy.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Secure cache [Source] webinos [Description]

Output: Data cached by a runtime shall be securely stored to prevent disclosure and tampering by unauthorised entitites.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Secure storage [Source] webinos [Description]

Output: Application data shall be securely stored to prevent disclosure and tampering by unauthorised entities.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Trusted application source [Source] webinos [Implications] Apps must have provenance data attached to them [Description]

Output: When installing or using an application for the first time, the runtime shall establish that the user trusts the source of the application.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] App stores can revoke applications [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] App permissions can be changed remotely [Description]

Output: "An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app"

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] External trusted party can set app default permissions [Source] Extrapolated from B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] The user is not the only source of access control decisions. this also suggests a need for conflict resolution. [Description]

Output: B2G: "App store must be able to set the default permissions for an app".

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Installation [Source] B2G, webinos [Description]

Output: Applications must be installed before executed

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Owner override [Source] B2G (user), webinos (user) [Implications] Access control settings must be changeable [Description]

Output: The device owner must be able to override app settings and permissions (this may not be the user, but a corporate, for example)

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] App privilege visibility [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] There must be a standard way for applications to identify the permissions they have and lack [Description]

Output: Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Permission usability [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Description]

Output: Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Immunity to browser-based threats [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Non-browser security context: may be additional restrictions on HTML/JavaScript [Description]

Output: Apps should not be vulnerable to common web vulnerabilities when granted significant privileges

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Pre-installed app permissions [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Different 'levels' apply to SysApps - possibly 'roles' [Description]

Output: Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Access to files outside owned by the platform [Source] Mailing list: http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html [Implications] Need to provide both sandboxed and non-sandboxed storage [Description]

Output: Ability for a system application to access (read and write) files outside of that application's sandboxed storage area.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Supports many device form factors [Description] Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices [Source] SysApps Charter [Implications]

Output: The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] DAP API Support [Description] All APIs defined by DAP should be accessible to system applications [Source] SysApps Charter [Implications]

Output: Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Minimal user prompting [Description] Problems such as 'double prompting' should be avoided when integrating other APIs [Source] SysApps Charter [Implications]

Output: Some details of the expected user interactions may need to be specified in the security model or APIs

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Communicate with other applications [Description] Applications can communicate with other applications [Implications]

Output: Some kind of messaging will be supported

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Communicate with pre-defined endpoints [Description] Applications can communicate with pre-defined web addresses [Implications]

Output: Access remote domains will be possible

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Trusted application source [Description] When installing or using an application for the first time, the runtime shall establish that the user trusts the source of the application. [Source] webinos [Implications]

Output: Apps must have provenance data attached to them

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] App stores can revoke applications [Description] "An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app" [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications]

Output: App permissions can be changed remotely

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] External trusted party can set app default permissions [Description] B2G: "App store must be able to set the default permissions for an app". [Source] Extrapolated from B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications]

Output: The user is not the only source of access control decisions. this also suggests a need for conflict resolution.

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Owner override [Description] The device owner must be able to override app settings and permissions (this may not be the user, but a corporate, for example) [Source] B2G (user), webinos (user) [Implications]

Output: Access control settings must be changeable

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] App privilege visibility [Description] Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications]

Output: There must be a standard way for applications to identify the permissions they have and lack

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Immunity to browser-based threats [Description] Apps should not be vulnerable to common web vulnerabilities when granted significant privileges [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications]

Output: Non-browser security context: may be additional restrictions on HTML/JavaScript

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Pre-installed app permissions [Description] Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications]

Output: Different 'levels' apply to SysApps - possibly 'roles'

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Requirement] Access to files outside owned by the platform [Description] Ability for a system application to access (read and write) files outside of that application's sandboxed storage area. [Source] Mailing list: http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html [Implications]

Output: Need to provide both sandboxed and non-sandboxed storage

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Part] ItemID [Applies] Item [Description] Returns the unique identifier assigned to the item by the simulation when it was created. [Type]

Output: Attribute

SRML - Simulation Reference Markup Language


Input: [Part] Events [Applies] Item [Description] Returns the events currently scheduled for an item. [Type]

Output: Collection

SRML - Simulation Reference Markup Language


Input: [Part] ItemClass [Applies] Item [Description] Returns the ItemClass of the item. [Type]

Output: Attribute

SRML - Simulation Reference Markup Language


Input: [Part] Items [Applies] Item [Description] Refers to the sub items of the current item. [Type]

Output: Collection

SRML - Simulation Reference Markup Language


Input: [Part] Location [Applies] Item [Description] Refers to another item that represents the current location of the item. [Type]

Output: Attribute

SRML - Simulation Reference Markup Language


Input: [Part] Node [Applies] Item [Description] Returns the XML DOM node corresponding to the item. [Type]

Output: Attribute

SRML - Simulation Reference Markup Language


Input: [Part] Self [Applies] Item [Description] Returns a reference to the current item. In JavaScript, the keyword 'this' may also be used. In VBScript, the keyword 'Me' may also be used. [Type]

Output: Attribute

SRML - Simulation Reference Markup Language


Input: [Identifier] Individual [Comment] Must be supported. [Semantics]

Output: The Party is a single individual

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.4.2: Terms for the attribute “scope” of the entity Role


Input: [Identifier] Group [Comment] Must be supported. [Semantics]

Output: The Party represents a defined group with multiple individual members

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] All [Comment] For example, may be used to indicate all the users of a specific social network the party is a member of. Note that “group” scope is also assumed. [Semantics]

Output: All the collective individuals within a context

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] AllConnections [Comment] For example, may be used to indicate all “friends” of the Party. Note that “group” scope is also assumed. [Semantics]

Output: All the first-level connections of the Party

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] All2ndConnections [Comment] For example, may be used to indicate all “friends of friends” of the Party. Note that “group” scope is also assumed. [Semantics]

Output: All the second-level connections of the Party

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] AllGroups [Comment] For example, may be used to indicate all groups that the Party is a member of. Note that “group” scope is also assumed. [Semantics]

Output: All the group connections of the Party

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Agreement [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Semantics]

Output: Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Offer [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Semantics]

Output: Policy expressions that propose terms of usage from an Asset owner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Privacy [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Semantics]

Output: Policy expressions that stipulate the terms of usage over personal information.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Request [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Semantics]

Output: Policy expressions that propose terms of usage to an Asset owner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Set [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Semantics]

Output: Policy expressions that consists of entities from the complete model

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Ticket [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Semantics]

Output: Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Name] ExclusiveMode [Description] whether to do inclusive or exclusive dealing of namespaces. In exclusive mode the InclusiveNamespaces parameter can be specified listing the prefixes that are to be treated in an inclusive mode [Default] false [Values]

Output: true or false


Input: [Name] InclusiveNamespace [Description] list of prefixes to be treated inclusively. Special token #default indicates the default namespace. [Default] empty [Values]

Output: space separated list of prefixes


Input: [Name] IgnoreComments [Description] whether to ignore comments during canonicalization [Default] true [Values]

Output: true or false


Input: [Name] TrimTextNodes [Description] whether to trim (i.e. remove leading and trailing whitespaces) all text nodes when canonicalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text node descendants of that element are not trimmed regardless of the value of this parameter. [Default] false [Values]

Output: true or false


Input: [Name] Serialization [Description] whether to do the normal XML serialization (http://www.w3.org/2010/xml-c14n2#serializeXML), or do an EXI serialization (http://www.w3.org/2010/xml-c14n2#serializeEXI) - which is useful if the original document to be canonicalized is already in EXI format. [Default] serializeXML [Values]

Output: serializeXML or serializeEXI


Input: [Name] PrefixRewrite [Description] with none, prefixes are not changed, with sequential prefixes are changed to n1, n2, n3 ... and with derived, each prefix is changed to nSuffix, where the suffix is derived by doing a digest of the namespace URI. [Default] none [Values]

Output: none, sequential, derived


Input: [Name] SortAttributes [Description] whether the attributes need to be sorted before canonicalization. In some environments the order of attributes changes in transit so sorting is important. [Default] true [Values]

Output: true or false


Input: [Name] XmlAncestors [Description] where to inherit the simple inheritable attributes (xml:lang and xml:space) and combine the xml:base i.e. similar to Canonical XML 1.1 or to completely ignore xml attributes in ancestors similar to Exclusive Canonical XML 1.0 [Default] inherit [Values]

Output: inherit, none


Input: [Name] QNameAware [Description] set of nodes whose entire content must be processed as QName-valued or [CURIE]-valued for the purposes of canonicalization, including prefix rewriting and recognition of prefix "visible utilization" [Default] empty set [Values]

Output: an enumeration of qualified element names, qualified attribute names, and unqualified attribute names (identified by name, and parent qualified name)


Input: [Name] ExclusiveMode [Values] true or false [Description] whether to do inclusive or exclusive dealing of namespaces. In exclusive mode the InclusiveNamespaces parameter can be specified listing the prefixes that are to be treated in an inclusive mode [Default]

Output: false


Input: [Name] InclusiveNamespace [Values] space separated list of prefixes [Description] list of prefixes to be treated inclusively. Special token #default indicates the default namespace. [Default]

Output: empty


Input: [Name] IgnoreComments [Values] true or false [Description] whether to ignore comments during canonicalization [Default]

Output: true


Input: [Name] TrimTextNodes [Values] true or false [Description] whether to trim (i.e. remove leading and trailing whitespaces) all text nodes when canonicalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text node descendants of that element are not trimmed regardless of the value of this parameter. [Default]

Output: false


Input: [Name] Serialization [Values] serializeXML or serializeEXI [Description] whether to do the normal XML serialization (http://www.w3.org/2010/xml-c14n2#serializeXML), or do an EXI serialization (http://www.w3.org/2010/xml-c14n2#serializeEXI) - which is useful if the original document to be canonicalized is already in EXI format. [Default]

Output: serializeXML


Input: [Name] PrefixRewrite [Values] none, sequential, derived [Description] with none, prefixes are not changed, with sequential prefixes are changed to n1, n2, n3 ... and with derived, each prefix is changed to nSuffix, where the suffix is derived by doing a digest of the namespace URI. [Default]


Input: [Name] SortAttributes [Values] true or false [Description] whether the attributes need to be sorted before canonicalization. In some environments the order of attributes changes in transit so sorting is important. [Default]

Output: true


Input: [Name] XmlAncestors [Values] inherit, none [Description] where to inherit the simple inheritable attributes (xml:lang and xml:space) and combine the xml:base i.e. similar to Canonical XML 1.1 or to completely ignore xml attributes in ancestors similar to Exclusive Canonical XML 1.0 [Default]

Output: inherit


Input: [Name] QNameAware [Values] an enumeration of qualified element names, qualified attribute names, and unqualified attribute names (identified by name, and parent qualified name) [Description] set of nodes whose entire content must be processed as QName-valued or [CURIE]-valued for the purposes of canonicalization, including prefix rewriting and recognition of prefix "visible utilization" [Default]

Output: empty set


Input: [Additive?] yes ['animate'] yes ['animate Color'] no ['animate Transform'] no ['set']

Output: yes


Input: [Additive?] yes ['animate'] yes ['animate Color'] yes ['animate Transform'] no [Notes] Only RGB color values are additive. ['set']

Output: yes


Input: [Additive?] no ['animate'] no ['animate Color'] no ['animate Transform'] no ['set']

Output: no


Input: [Additive?] no ['animate'] yes ['animate Color'] no ['animate Transform'] no ['set']

Output: yes


Input: [Additive?] yes ['animate'] no ['animate Color'] no ['animate Transform'] yes [Notes] Additive means that a transformation is post-multiplied to the base set of transformations. ['set']

Output: no


Input: [Data type] All other data types used in animatable attributes and properties [Additive?] no ['animate'] yes ['animate Color'] no ['animate Transform'] no ['set']

Output: yes


Input: [Identifier] absolutePosition [Comment] For example, JPEG image must be positioned at 100×100 pixel location. This may be used to express [PLUS] semantics. [Semantics]

Output: A point defined with absolute coordinates

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.3.1: Terms for the attribute “name” of the entity Constraint


Input: [Identifier] absoluteSize [Comment] For example, JPEG image must be reproduced onto an area no larger than A0. This may be used to express [PLUS] semantics. [Semantics]

Output: The absolute dimension that the Asset may be resized

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] count [Comment] Should be a positive integer. [Semantics]

Output: The numeric count indicating the number of times the corresponding entity may be exercised

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] dateTime [Comment] Date and Time value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. The use of Timezone information is strongly recommended. [Semantics]

Output: The date (and optional time and timezone) representing a point in time or period

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] fileFormat [Comment] For example, this may be used to express [PLUS] semantics; only JPEG image may be distributed. [Semantics]

Output: The file format applicable to the Asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] industry [Comment] For example, publishing, financial. [Semantics]

Output: The defined industry sector applicable to the asset usage

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] language [Comment] For example, this may be used to express [PLUS] semantics; JPEG image may only be reproduced with Spanish text. Must use [BCP-47] codes. [Semantics]

Output: The natural language applicable to the asset usage

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] deliveryChannel [Comment] For example, the asset may be distributed only on mobile networks. [Semantics]

Output: The delivery channel used for storing or communicating the asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] elapsedTime [Comment] The start of the period is when the action is first exercised. [Semantics]

Output: A period of time in which the policy action can be exercised.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] event [Comment] For example, asset may be used at the “FIFA World Cup” only. To express events related to undertaking Duties, a specific event value has been defined: policyUsage – the time period whilst the policy is being exercised This will enable constraints to be expressed such as “event lt o:policyUsage” indicating before the policy is exercised. [Semantics]

Output: Specification of a defined event applicable to the asset usage

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] media [Comment] For example, electronic, print, advertising, marketing. This may be used to express [PLUS] semantics. [Semantics]

Output: The media type in which the asset may be used

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] meteredTime [Comment] Value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. For example “P30H” indicates a 30 hour period. [Semantics]

Output: The maximum period of metered usage time

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] payAmount [Comment] The dataType attribute may be used to indicate the type of the value (eg decimal) and the unit attribute to indicate the currency. May be used for compensation duties. [Semantics]

Output: The value of the financial payment

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] percentage [Comment] A numeric value from 0 to 100. For example, extract a maximum of 50% of the asset [Semantics]

Output: The amount (as a percentage) of the action applicable to the asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] product [Comment] For example, this may be used to express [PLUS] semantics; images may only be reproduced in the XYZ Magazine. [Semantics]

Output: The specified Product or Service name

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] purpose [Comment] For example, educational use. [P3P] Purpose values may also be used. [Semantics]

Output: Specification of a defined purpose applicable to the asset usage

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] recipient [Comment] The right operand must identify one or more specific parties or categories of party [Semantics]

Output: The party that receives the result of the Action on the Asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] relativePosition [Comment] For example, this may be used to express [PLUS] semantics; JPEG image must be positioned at the Top of the Page. [Semantics]

Output: A point defined with reference to another position

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] relativeSize [Comment] For example, this may be used to express [PLUS] semantics; JPEG image resized to maximum of 200%. [Semantics]

Output: The relative dimension that the Asset may be resized

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] resolution [Comment] For example, may be printed at 1200dpi. [Semantics]

Output: The resolution at which the asset may be used

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] spatial [Comment] The code value and code source must be represented. For example, the ISO-3166 Country Codes and the Getty Thesaurus of Geographic Names. A URI should be used to represent this value. [Semantics]

Output: A code representing a geospatial area

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] timeInterval [Comment] Interval value must conform to [ISO-8601] as represented in [W3CXMLSCHEMA]. For example, “P7D” indicates a 7 day period. [Semantics]

Output: Recurring period of time in which the usage may be exercised

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] systemDevice [Comment] For example, identifiable via the CPU or unique hardware address. [Semantics]

Output: An identifiable computing system

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] version [Comment] For example, Single Paperback, or Multiple Issues. This may be used to express [PLUS] semantics. [Semantics]

Output: The scope of versions for the asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] virtualLocation [Comment] For example, an Internet domain or IP address range [Semantics]

Output: Specification of a digital locale

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party is a single individual [Comment] Must be supported. [Identifier]

Output: Individual

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party represents a defined group with multiple individual members [Comment] Must be supported. [Identifier]

Output: Group

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] All the collective individuals within a context [Comment] For example, may be used to indicate all the users of a specific social network the party is a member of. Note that “group” scope is also assumed. [Identifier]

Output: All

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] All the first-level connections of the Party [Comment] For example, may be used to indicate all “friends” of the Party. Note that “group” scope is also assumed. [Identifier]

Output: AllConnections

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] All the second-level connections of the Party [Comment] For example, may be used to indicate all “friends of friends” of the Party. Note that “group” scope is also assumed. [Identifier]

Output: All2ndConnections

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] All the group connections of the Party [Comment] For example, may be used to indicate all groups that the Party is a member of. Note that “group” scope is also assumed. [Identifier]

Output: AllGroups

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Description] Applications can create alarms, notifying users [Source] SysApps Charter [Requirement]

Output: Alarm API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can add, remove and edit contacts [Source] SysApps Charter [Requirement]

Output: Contacts API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can send, receive and view SMS [Source] SysApps Charter [Requirement]

Output: Messaging API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can access the telephony capabilities of the underlyling platform: dial a number, pick up a call, route to voicemail, access the call log [Source] SysApps Charter [Requirement]

Output: Telephony API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps can create, manipulate and listen for low-level TCP and UDP connections [Source] SysApps Charter [Requirement]

Output: Raw Sockets API

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Supports a wide variety of devices including desktop & laptop computers, smart phones, tablets, TVs, cameras, and other connected devices [Source] SysApps Charter [Implications] The security model can make no assumptions about how the device will be used or shared between people and cannot assume a particular process model. [Requirement]

Output: Supports many device form factors

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] All APIs defined by DAP should be accessible to system applications [Source] SysApps Charter [Implications] Either DAP APIs will need to change slightly in the systems context or the security model must allow for API-specific access controls [Requirement]

Output: DAP API Support

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Problems such as 'double prompting' should be avoided when integrating other APIs [Source] SysApps Charter [Implications] Some details of the expected user interactions may need to be specified in the security model or APIs [Requirement]

Output: Minimal user prompting

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications consist of HTML, CSS and JavaScript [Requirement]

Output: HTML5

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications have access to geolocation data [Requirement]

Output: Location

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications can communicate with other applications [Implications] Some kind of messaging will be supported [Requirement]

Output: Communicate with other applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications can communicate with pre-defined web addresses [Implications] Access remote domains will be possible [Requirement]

Output: Communicate with pre-defined endpoints

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications can run on any conformant platform, potentially including any device form factor [Source] Compatibility of application packages [Requirement]

Output: Valid across multiple platforms

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Allow access control decisions to be logged. [Source] webinos [Requirement]

Output: Access control log

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall be able to explain why access to data or APIs is being requested. [Source] webinos [Requirement]

Output: API access rationale

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall access only its specified device features, extensions and content. [Source] webinos [Requirement]

Output: Application capability restriction

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall specify its required functionality at install time or during updates. [Source] webinos [Requirement]

Output: Application intent

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications shall be isolated from each other. [Source] webinos [Requirement]

Output: Application isolation

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Changes to existing application intentions and permissions shall be approved by the end user. [Source] webinos [Requirement]

Output: Application policy approval

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Before being installed or updated, origin authenticity and integrity checks shall be performed by the runtime [Source] webinos [Requirement]

Output: Authenticity check

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The list of authorities that certified an application shall be viewable by end-users. [Source] webinos [Requirement]

Output: Certifier list

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The webinos runtime shall support the confidential storage of user credentials. [Source] webinos [Requirement]

Output: Confidential credentials storage

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Access to credentials storage shall be limited to a specific user, a specific device and a set of applications. [Source] webinos [Requirement]

Output: Credentials access restriction

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] applications shall be able to explain how collected sensitive data will be managed. [Source] webinos [Requirement]

Output: Data management rationale

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] A default security and privacy policy shall exist an be enforced on each conformant runtime [Source] webinos [Requirement]

Output: Default policy

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Personal devices shall be bound to their owner's identities. [Source] webinos [Requirement]

Output: Device-identity binding

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The binding between personal devices and owner's identity shall be revokable. [Source] webinos [Requirement]

Output: Device-identity binding revokation

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Runtimes can enforce multiple access control rules written by multiple stakeholders in a hierarchy. [Source] webinos [Requirement]

Output: Hierarchical policy enforcement

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Data cached by a runtime shall be securely stored to prevent disclosure and tampering by unauthorised entitites. [Source] webinos [Requirement]

Output: Secure cache

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Application data shall be securely stored to prevent disclosure and tampering by unauthorised entities. [Source] webinos [Requirement]

Output: Secure storage

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] When installing or using an application for the first time, the runtime shall establish that the user trusts the source of the application. [Source] webinos [Implications] Apps must have provenance data attached to them [Requirement]

Output: Trusted application source

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] "An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app" [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] App permissions can be changed remotely [Requirement]

Output: App stores can revoke applications

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] B2G: "App store must be able to set the default permissions for an app". [Source] Extrapolated from B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] The user is not the only source of access control decisions. this also suggests a need for conflict resolution. [Requirement]

Output: External trusted party can set app default permissions

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Applications must be installed before executed [Source] B2G, webinos [Requirement]

Output: Installation

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] The device owner must be able to override app settings and permissions (this may not be the user, but a corporate, for example) [Source] B2G (user), webinos (user) [Implications] Access control settings must be changeable [Requirement]

Output: Owner override

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] There must be a standard way for applications to identify the permissions they have and lack [Requirement]

Output: App privilege visibility

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Requirement]

Output: Permission usability

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Apps should not be vulnerable to common web vulnerabilities when granted significant privileges [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Non-browser security context: may be additional restrictions on HTML/JavaScript [Requirement]

Output: Immunity to browser-based threats

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties [Source] B2G - https://wiki.mozilla.org/B2G_App_Security_Model [Implications] Different 'levels' apply to SysApps - possibly 'roles' [Requirement]

Output: Pre-installed app permissions

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Description] Ability for a system application to access (read and write) files outside of that application's sandboxed storage area. [Source] Mailing list: http://lists.w3.org/Archives/Public/public-sysapps/2012Nov/0003.html [Implications] Need to provide both sandboxed and non-sandboxed storage [Requirement]

Output: Access to files outside owned by the platform

Difference between revisions of "System Applications WG: Security Model" - W3C Wiki


Input: [Event Name] dragstart [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Contains source node unless a selection is being dragged, in which case it is empty; files returns any files included in the drag operation [effectAllowed] uninitialized [dropEffect] none [Default Action]

Output: Initiate the drag-and-drop operation


Input: [Event Name] drag [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action]

Output: Continue the drag-and-drop operation


Input: [Event Name] dragenter [Target] Immediate user selection or the body element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action]

Output: Reject immediate user selection as potential target element


Input: [Event Name] dragleave [Target] Previous target element [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action]


Input: [Event Name] dragover [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action]

Output: Reset the current drag operation to "none"


Input: [Event Name] drop [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] getData() returns data set in dragstart event; files returns any files included in the drag operation [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action]

Output: Varies


Input: [Event Name] dragend [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action]

Output: Varies


Input: [Semantics] The Assigner requires that the Assignee(s) accepts that the use of the Asset may be tracked [Comment] The collected information may be tracked by the Assigner, or may link to a Party with the role function “trackingParty”. [Identifier]

Output: acceptTracking

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.2.2: Terms for entity Action used with Duty


Input: [Semantics] The Assigner requires that the Assignee(s) attributes the Asset to the Assigner or an attributed Party. [Comment] May link to an Asset with the attribution information. May link to a Party with the role function “attributedParty”. [Identifier]

Output: attribute

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) compensates the Assigner (or other specified compensation Party) by some amount of value, if defined, for use of the Asset. [Comment] The compensation may use different types of things with a value: – the thing is expressed by the value (term) of the Constraint name – the value is expressed by operator, rightOperand, dataType and unit [Identifier]

Output: compensate

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) permanently removes all copies of the Asset. [Comment] Use a constraint to define under which conditions the Asset should be deleted. [Identifier]

Output: delete

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assignee requires that the Assigner(s) ensure(s) that the permission on the Asset is exclusive to the Assignee. [Identifier]

Output: ensureExclusivity

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) include(s) other related assets in the Asset. [Comment] For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required [Identifier]

Output: include

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) inform(s) the Assigner or an informed Party that an action has been performed on or in relation to the Asset. [Comment] May link to a Party with the role function “informedParty”. [Identifier]

Output: inform

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) grants the specified Policy to a third party for their use of the Asset. [Identifier]

Output: nextPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) obtains explicit consent from the Assigner or a consenting Party to perform the requested action in relation to the Asset. [Comment] Used as a Duty to ensure that the Assigner or a Party is authorized to approve such actions on a case-by-case basis. May link to a Party with the role function “consentingParty”. [Identifier]

Output: obtainConsent

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) has(ve) a person review the Policy applicable to the Asset. [Comment] Used when human intervention is required to review the Policy. May link to an Asset which represents the full Policy information. [Identifier]

Output: reviewPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) unload(s) and delete(s) the computer program Asset from a storage device and disable(s) its readiness for operation. [Comment] The Asset is no longer accessible to the Assignee(s). [Identifier]

Output: uninstall

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Assigner requires that the Assignee(s) apply(ies) a watermark as provided by the Assigner to the Asset. [Comment] It is recommended to embed a link to the watermark. [Identifier]

Output: watermark

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Type] Attribute [Applies] Item [Description] Returns the unique identifier assigned to the item by the simulation when it was created. [Part]

Output: ItemID

SRML - Simulation Reference Markup Language


Input: [Type] Collection [Applies] Item [Description] Returns the events currently scheduled for an item. [Part]

Output: Events

SRML - Simulation Reference Markup Language


Input: [Type] Attribute [Applies] Item [Description] Returns the ItemClass of the item. [Part]

Output: ItemClass

SRML - Simulation Reference Markup Language


Input: [Type] Collection [Applies] Item [Description] Refers to the sub items of the current item. [Part]

Output: Items

SRML - Simulation Reference Markup Language


Input: [Type] Attribute [Applies] Item [Description] Refers to another item that represents the current location of the item. [Part]

Output: Location

SRML - Simulation Reference Markup Language


Input: [Type] Attribute [Applies] Item [Description] Returns the XML DOM node corresponding to the item. [Part]

Output: Node

SRML - Simulation Reference Markup Language


Input: [Type] Attribute [Applies] Item [Description] Returns a reference to the current item. In JavaScript, the keyword 'this' may also be used. In VBScript, the keyword 'Me' may also be used. [Part]

Output: Self

SRML - Simulation Reference Markup Language


Input: [Identifier] Agreement [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Semantics]

Output: Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Offer [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Semantics]

Output: Policy expressions that propose terms of usage from an Asset owner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Privacy [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Semantics]

Output: Policy expressions that stipulate the terms of usage over personal information.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Request [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Semantics]

Output: Policy expressions that propose terms of usage to an Asset owner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Set [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Semantics]

Output: Policy expressions that consists of entities from the complete model

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Ticket [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Semantics]

Output: Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Name] ExclusiveMode [Values] true or false [Default] false [Description]

Output: whether to do inclusive or exclusive dealing of namespaces. In exclusive mode the InclusiveNamespaces parameter can be specified listing the prefixes that are to be treated in an inclusive mode


Input: [Name] InclusiveNamespace [Values] space separated list of prefixes [Default] empty [Description]

Output: list of prefixes to be treated inclusively. Special token #default indicates the default namespace.


Input: [Name] IgnoreComments [Values] true or false [Default] true [Description]

Output: whether to ignore comments during canonicalization


Input: [Name] TrimTextNodes [Values] true or false [Default] false [Description]

Output: whether to trim (i.e. remove leading and trailing whitespaces) all text nodes when canonicalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text node descendants of that element are not trimmed regardless of the value of this parameter.


Input: [Name] Serialization [Values] serializeXML or serializeEXI [Default] serializeXML [Description]

Output: whether to do the normal XML serialization (http://www.w3.org/2010/xml-c14n2#serializeXML), or do an EXI serialization (http://www.w3.org/2010/xml-c14n2#serializeEXI) - which is useful if the original document to be canonicalized is already in EXI format.


Input: [Name] PrefixRewrite [Values] none, sequential, derived [Default] none [Description]

Output: with none, prefixes are not changed, with sequential prefixes are changed to n1, n2, n3 ... and with derived, each prefix is changed to nSuffix, where the suffix is derived by doing a digest of the namespace URI.


Input: [Name] SortAttributes [Values] true or false [Default] true [Description]

Output: whether the attributes need to be sorted before canonicalization. In some environments the order of attributes changes in transit so sorting is important.


Input: [Name] XmlAncestors [Values] inherit, none [Default] inherit [Description]

Output: where to inherit the simple inheritable attributes (xml:lang and xml:space) and combine the xml:base i.e. similar to Canonical XML 1.1 or to completely ignore xml attributes in ancestors similar to Exclusive Canonical XML 1.0


Input: [Name] QNameAware [Values] an enumeration of qualified element names, qualified attribute names, and unqualified attribute names (identified by name, and parent qualified name) [Default] empty set [Description]

Output: set of nodes whose entire content must be processed as QName-valued or [CURIE]-valued for the purposes of canonicalization, including prefix rewriting and recognition of prefix "visible utilization"


Input: [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former. [Identifier]

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment] Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party. [Identifier]

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment] Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner. [Identifier]

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment] Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party. [Identifier]

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that consists of entities from the complete model [Comment] The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party. [Identifier]

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] Policy expressions that stipulate the terms of usage and is redeemable by any Party who currently holds the Ticket in their possession [Comment] May contain the Party entity with Assigner role and the Party entity with Assignee role. A Ticket (or Voucher) may be anonymous or personalised, where the holder of that Ticket may remain unknown or has to be identified. The holder, or if known, the Assignee, is being granted the terms of the Ticket from the Assigner (in known). [Identifier]

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Event Name] dragstart [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Contains source node unless a selection is being dragged, in which case it is empty; files returns any files included in the drag operation [effectAllowed] uninitialized [Default Action] Initiate the drag-and-drop operation [dropEffect]


Input: [Event Name] drag [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [Default Action] Continue the drag-and-drop operation [dropEffect]


Input: [Event Name] dragenter [Target] Immediate user selection or the body element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [Default Action] Reject immediate user selection as potential target element [dropEffect]

Output: Based on effectAllowed value


Input: [Event Name] dragleave [Target] Previous target element [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [Default Action] None [dropEffect]


Input: [Event Name] dragover [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [Default Action] Reset the current drag operation to "none" [dropEffect]

Output: Based on effectAllowed value


Input: [Event Name] drop [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] getData() returns data set in dragstart event; files returns any files included in the drag operation [effectAllowed] Same as last event [Default Action] Varies [dropEffect]

Output: Current drag operation


Input: [Event Name] dragend [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [Default Action] Varies [dropEffect]

Output: Current drag operation


Input: [Special operation] Getters [Keyword] "getter" [Purpose]

Output: Defines behavior for when an object is indexed for property retrieval.


Input: [Special operation] Setters [Keyword] "setter" [Purpose]

Output: Defines behavior for when an object is indexed for property assignment.


Input: [Special operation] Creators [Keyword] "creator" [Purpose]

Output: Defines behavior for when an object is indexed for property creation.


Input: [Special operation] Deleters [Keyword] "deleter" [Purpose]

Output: Defines behavior for when an object is indexed for property deletion.


Input: [Special operation] Callers [Keyword] "caller" [Purpose]

Output: Defines behavior for when an object is called as if it were a function.


Input: [Special operation] Stringifiers [Keyword] "stringifier" [Purpose]

Output: Defines how an object is converted into a DOMString.


Input: [Part] ItemID [Type] Attribute [Applies] Item [Description]

Output: Returns the unique identifier assigned to the item by the simulation when it was created.

SRML - Simulation Reference Markup Language


Input: [Part] Events [Type] Collection [Applies] Item [Description]

Output: Returns the events currently scheduled for an item.

SRML - Simulation Reference Markup Language


Input: [Part] ItemClass [Type] Attribute [Applies] Item [Description]

Output: Returns the ItemClass of the item.

SRML - Simulation Reference Markup Language


Input: [Part] Items [Type] Collection [Applies] Item [Description]

Output: Refers to the sub items of the current item.

SRML - Simulation Reference Markup Language


Input: [Part] Location [Type] Attribute [Applies] Item [Description]

Output: Refers to another item that represents the current location of the item.

SRML - Simulation Reference Markup Language


Input: [Part] Node [Type] Attribute [Applies] Item [Description]

Output: Returns the XML DOM node corresponding to the item.

SRML - Simulation Reference Markup Language


Input: [Part] Self [Type] Attribute [Applies] Item [Description]

Output: Returns a reference to the current item. In JavaScript, the keyword 'this' may also be used. In VBScript, the keyword 'Me' may also be used.

SRML - Simulation Reference Markup Language


Input: [Identifier] Agreement [Semantics] Policy expressions that are formal contracts (or licenses) stipulating all the terms of usage and all the parties involved. [Comment]

Output: Must contain at least the Party entity with Assigner role and a Party with Assignee role. The latter being granted the terms of the Agreement from the former.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Offer [Semantics] Policy expressions that propose terms of usage from an Asset owner [Comment]

Output: Must contain a Party entity with Assigner role. The Offer may contain a Party entity with Assignee role, but does not grant any privileges to that Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Privacy [Semantics] Policy expressions that stipulate the terms of usage over personal information. [Comment]

Output: Must contain at least the Party entity with Assigner role and a Party with Assignee role. Must also contain a Duty on the assignee related to obligations towards managing the assigner’s Asset containing personal information. The Assignee is being granted the terms of the Privacy policy from the Assigner.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Request [Semantics] Policy expressions that propose terms of usage to an Asset owner [Comment]

Output: Must contain a Party entity with Assignee role. The Request may also contain the Party entity with Assigner role if this is known. No privileges are granted to any Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] Set [Semantics] Policy expressions that consists of entities from the complete model [Comment]

Output: The Set is aimed at scenarios where there is an open criteria for the semantics of the policy expressions and typically refined by other systems/profiles that process the information at a later time. No privileges are granted to any Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group