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: [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] Initiate the drag-and-drop operation [Event Name]

Output: dragstart


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

Output: drag


Input: [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] Reject immediate user selection as potential target element [Event Name]

Output: dragenter


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

Output: dragleave


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

Output: dragover


Input: [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] Varies [Event Name]

Output: drop


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

Output: dragend


Input: [Event Name] dragstart [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] Initiate the drag-and-drop operation [Target]

Output: Source node


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

Output: Source node


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

Output: Immediate user selection or the body element


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

Output: Previous target element


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

Output: Current target element


Input: [Event Name] drop [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] Varies [Target]

Output: Current target element


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

Output: Source node


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

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


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: [Event handler] onabort [Event handler event type]

Output: abort


Input: [Event handler] oncancel [Event handler event type]

Output: cancel


Input: [Event handler] oncanplay [Event handler event type]

Output: canplay


Input: [Event handler] oncanplaythrough [Event handler event type]

Output: canplaythrough


Input: [Event handler] onchange [Event handler event type]

Output: change


Input: [Event handler] onclick [Event handler event type]

Output: click


Input: [Event handler] onclose [Event handler event type]

Output: close


Input: [Event handler] oncontextmenu [Event handler event type]

Output: contextmenu


Input: [Event handler] oncuechange [Event handler event type]

Output: cuechange


Input: [Event handler] ondblclick [Event handler event type]

Output: dblclick


Input: [Event handler] ondrag [Event handler event type]

Output: drag


Input: [Event handler] ondragend [Event handler event type]

Output: dragend


Input: [Event handler] ondragenter [Event handler event type]

Output: dragenter


Input: [Event handler] ondragexit [Event handler event type]

Output: dragexit


Input: [Event handler] ondragleave [Event handler event type]

Output: dragleave


Input: [Event handler] ondragover [Event handler event type]

Output: dragover


Input: [Event handler] ondragstart [Event handler event type]

Output: dragstart


Input: [Event handler] ondrop [Event handler event type]

Output: drop


Input: [Event handler] ondurationchange [Event handler event type]

Output: durationchange


Input: [Event handler] onemptied [Event handler event type]

Output: emptied


Input: [Event handler] onended [Event handler event type]

Output: ended


Input: [Event handler] oninput [Event handler event type]

Output: input


Input: [Event handler] oninvalid [Event handler event type]

Output: invalid


Input: [Event handler] onkeydown [Event handler event type]

Output: keydown


Input: [Event handler] onkeypress [Event handler event type]

Output: keypress


Input: [Event handler] onkeyup [Event handler event type]

Output: keyup


Input: [Event handler] onloadeddata [Event handler event type]

Output: loadeddata


Input: [Event handler] onloadedmetadata [Event handler event type]

Output: loadedmetadata


Input: [Event handler] onloadstart [Event handler event type]

Output: loadstart


Input: [Event handler] onmousedown [Event handler event type]

Output: mousedown


Input: [Event handler] onmouseenter [Event handler event type]

Output: mouseenter


Input: [Event handler] onmouseleave [Event handler event type]

Output: mouseleave


Input: [Event handler] onmousemove [Event handler event type]

Output: mousemove


Input: [Event handler] onmouseout [Event handler event type]

Output: mouseout


Input: [Event handler] onmouseover [Event handler event type]

Output: mouseover


Input: [Event handler] onmouseup [Event handler event type]

Output: mouseup


Input: [Event handler] onmousewheel [Event handler event type]

Output: mousewheel


Input: [Event handler] onpause [Event handler event type]

Output: pause


Input: [Event handler] onplay [Event handler event type]

Output: play


Input: [Event handler] onplaying [Event handler event type]

Output: playing


Input: [Event handler] onprogress [Event handler event type]

Output: progress


Input: [Event handler] onratechange [Event handler event type]

Output: ratechange


Input: [Event handler] onreset [Event handler event type]

Output: reset


Input: [Event handler] onseeked [Event handler event type]

Output: seeked


Input: [Event handler] onseeking [Event handler event type]

Output: seeking


Input: [Event handler] onselect [Event handler event type]

Output: select


Input: [Event handler] onshow [Event handler event type]

Output: show


Input: [Event handler] onsort [Event handler event type]

Output: sort


Input: [Event handler] onstalled [Event handler event type]

Output: stalled


Input: [Event handler] onsubmit [Event handler event type]

Output: submit


Input: [Event handler] onsuspend [Event handler event type]

Output: suspend


Input: [Event handler] ontimeupdate [Event handler event type]

Output: timeupdate


Input: [Event handler] onvolumechange [Event handler event type]

Output: volumechange


Input: [Event handler] onwaiting [Event handler event type]

Output: waiting


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: [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: [Event Name] dragstart [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] uninitialized [dropEffect] none [Default Action] Initiate the drag-and-drop operation [dataTransfer]

Output: Contains source node unless a selection is being dragged, in which case it is empty; files returns any files included in the drag operation


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

Output: Empty


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

Output: Empty


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

Output: Empty


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

Output: Empty


Input: [Event Name] drop [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [dataTransfer]

Output: getData() returns data set in dragstart event; files returns any files included in the drag operation


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

Output: Empty


Input: [Description] Updated to use the http://www.w3.org/2001/XMLSchema namespace [Class]

Output: Namespace

Changes to Encoding Schema


Input: [Description] Value of targetNamespace attribute changed to http://www.w3.org/2001/06/soap-encoding [Class]

Output: Namespace

Changes to Encoding Schema


Input: [Description] Changed type of the root attribute from restriction of boolean that only allowed 0 or 1 as lexical values to the standard boolean in the http://www.w3.org/2001/XMLSchema namespace. The lexical forms 0, 1, false, true are now allowed. [Class]

Output: Semantic

Changes to Encoding Schema


Input: [Description] Added processContents="lax" to all element and attribute wildcards [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Changed base64 simple type to be a vacuous restriction of the base64Binary type in the http://www.w3.org/2001/XMLSchema namespace [Class]

Output: Syntax

Changes to Encoding Schema


Input: [Description] Updated all complex type definitions with simple base types to new syntax [Class]

Output: Syntax

Changes to Encoding Schema


Input: [Description] Added to all complex type definitions derived implicitly from the ur-type [Class]

Output: Syntax

Changes to Encoding Schema


Input: [Description] Added to all named model group definitions [Class]

Output: Syntax

Changes to Encoding Schema


Input: [Description] Removed the timeDuration datatype [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Added duration datatype derived by extension from the duration datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Removed the timeInstant datatype [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Added dateTime datatype derived by extension from the dateTime datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added gYearMonth datatype derived by extension from the gYearMonth datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added gYear datatype derived by extension from the gYear datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added gMonthDay datatype derived by extension from the gMonthDay datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added gDay datatype derived by extension from the gDay datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Removed the binary datatype [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Added hexBinary datatype derived by extension from the hexBinary datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added base64Binary datatype derived by extension from the base64Binary datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Removed the uriReference datatype [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Added anyURI datatype derived by extension from the anyURI datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added normalizedString datatype derived by extension from the normalizedString datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added token datatype derived by extension from the token datatype in the http://www.w3.org/2001/XMLSchema namespace. [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added explicit namespace="##any" to all element and attribute wildcards which did not previously have an explicit namespace attribute [Class]

Output: Clarification

Changes to Encoding Schema


Input: [Description] Where possible comments have been changed into annotations [Class]

Output: Style

Changes to Encoding Schema


Input: [Description] Added element declaration for anyType [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Removed the ur-type element declaration and complexType definition [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Removed the NOTATION element declaration and complexType definition [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Removed global attribute declarations for attributes associated with sparse arrays. [Class]

Output: Deletion

Changes to Encoding Schema


Input: [Description] Added arraySize global attribute decl and associated type definitions [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Added itemType global attribute decl [Class]

Output: Addition

Changes to Encoding Schema


Input: [Description] Amended arrayAttribute attribute group removing sparse array attributes and adding arraySize and itemType attributes. [Class]

Output: Change

Changes to Encoding Schema


Input: [Description] Changed arraySize type to allow nonNegativeIntegers instead of positiveIntegers [Class]

Output: Change

Changes to Encoding Schema


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


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: [0] The cells in [1] this table [2]

Output: should go


Input: [0] green when [1] you hover [2]

Output: the pointing


Input: [0] The rows in [1] this table [2]

Output: should go


Input: [0] dark green [1] when the [2]

Output: pointing device


Input: [0] is over the [1] five pixel [2]

Output: border spacing


Input: [0] Including here, [2]

Output: blank cells.


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

Output: yes


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

Output: yes


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

Output: no


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

Output: yes


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

Output: no


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

Output: yes


Input: [Level] 1. [testability of specification]

Output: Working Group plans regular specification reviews for testability, following Specification Guidelines


Input: [Level] 2. [extent of test materials] Working Group commits that test suite for the specification, not necessarily complete and thorough, will exist before specification becomes Recommendation. [testability of specification]

Output: In addition to the regular specifications reviews mentioned in the previous level, Working Group commits to develop a set of test assertions, not necessarily complete, before beginning development of a test suite.


Input: [Level] 3. [extent of test materials] In addition to the commitment of the previous level, a Working Group ensures that the test suite produced is reviewed by the Working Group or externally and the review process meets the criteria established in this document. [testability of specification]

Output: In addition to regular specification reviews, a Working Group aims to have numerous normative use cases in the body of the Recommendation.


Input: [Level] 4. [extent of test materials] Working Group commits to establish and maintain the test cases contribution and review process and will produce and review the test suite, not necessarily complete and thorough, before the specification becomes Recommendation. [testability of specification]

Output: Same as above.


Input: [Level] 5. [extent of test materials] Same as above [testability of specification]

Output: In addition to the commitments from the previous level, Working Group will derive the list of testable assertions as an addendum to specification by the time it becomes Recommendation.


Input: [Level] 6. [extent of test materials] In addition to the commitment for the previous level, a Working Group insists on a complete test suite before corresponding standard becomes Recommendation. [testability of specification]

Output: Same as above


Input: [Level] 7. [extent of test materials] In addition to the commitment for the previous level, Working Group plans to maintain the test suite even after Specification becomes recommendation. Working Group plans to support versioning and errata in the test suite and review appeals. [testability of specification]

Output: Same as above


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: [Level] 2. [testability of specification] In addition to the regular specifications reviews mentioned in the previous level, Working Group commits to develop a set of test assertions, not necessarily complete, before beginning development of a test suite. [extent of test materials]

Output: Working Group commits that test suite for the specification, not necessarily complete and thorough, will exist before specification becomes Recommendation.


Input: [Level] 3. [testability of specification] In addition to regular specification reviews, a Working Group aims to have numerous normative use cases in the body of the Recommendation. [extent of test materials]

Output: In addition to the commitment of the previous level, a Working Group ensures that the test suite produced is reviewed by the Working Group or externally and the review process meets the criteria established in this document.


Input: [Level] 4. [testability of specification] Same as above. [extent of test materials]

Output: Working Group commits to establish and maintain the test cases contribution and review process and will produce and review the test suite, not necessarily complete and thorough, before the specification becomes Recommendation.


Input: [Level] 5. [testability of specification] In addition to the commitments from the previous level, Working Group will derive the list of testable assertions as an addendum to specification by the time it becomes Recommendation. [extent of test materials]

Output: Same as above


Input: [Level] 6. [testability of specification] Same as above [extent of test materials]

Output: In addition to the commitment for the previous level, a Working Group insists on a complete test suite before corresponding standard becomes Recommendation.


Input: [Level] 7. [testability of specification] Same as above [extent of test materials]

Output: In addition to the commitment for the previous level, Working Group plans to maintain the test suite even after Specification becomes recommendation. Working Group plans to support versioning and errata in the test suite and review appeals.


Input: [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] false [Name]

Output: ExclusiveMode


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

Output: InclusiveNamespace


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

Output: IgnoreComments


Input: [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] false [Name]

Output: TrimTextNodes


Input: [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] serializeXML [Name]

Output: Serialization


Input: [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] none [Name]

Output: PrefixRewrite


Input: [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] true [Name]

Output: SortAttributes


Input: [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] inherit [Name]

Output: XmlAncestors


Input: [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] empty set [Name]

Output: QNameAware


Input: [Role] roletype [Description]

Output: Describes the structural and functional purpose of an element. A Role is also a concept.

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] input [Description]

Output: Generic type for widgets that can have a value

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] textbox [Description]

Output: Generic type for the inputs that allow free-form text as their value

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] select [Description]

Output: A form control that allows the user to make selections from a set of choices

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] range [Description]

Output: Represents a range of values that can be set by the user.

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] section [Description]

Output: A logical part of a DeliveryUnit (page or a document)

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] sectionhead [Description]

Output: A heading without level

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Role] window [Description]

Output: Browser or application window

Roles for Accessible Rich Internet Applications (ARIA)

Base Roles


Input: [Identifier] acceptTracking [Semantics] The Assigner requires that the Assignee(s) accepts that the use of the Asset may be tracked [Comment]

Output: The collected information may be tracked by the Assigner, or may link to a Party with the role function “trackingParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.2.2: Terms for entity Action used with Duty


Input: [Identifier] attribute [Semantics] The Assigner requires that the Assignee(s) attributes the Asset to the Assigner or an attributed Party. [Comment]

Output: May link to an Asset with the attribution information. May link to a Party with the role function “attributedParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] compensate [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]

Output: 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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] delete [Semantics] The Assigner requires that the Assignee(s) permanently removes all copies of the Asset. [Comment]

Output: Use a constraint to define under which conditions the Asset should be deleted.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] include [Semantics] The Assigner requires that the Assignee(s) include(s) other related assets in the Asset. [Comment]

Output: For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] inform [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]

Output: May link to a Party with the role function “informedParty”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] obtainConsent [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]

Output: 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”.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] reviewPolicy [Semantics] The Assigner requires that the Assignee(s) has(ve) a person review the Policy applicable to the Asset. [Comment]

Output: Used when human intervention is required to review the Policy. May link to an Asset which represents the full Policy information.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] uninstall [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]

Output: The Asset is no longer accessible to the Assignee(s).

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: It is recommended to embed a link to the watermark.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Value] terminology [Description] An incorrect term or a term from the wrong domain was used or terms are used inconsistently. [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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] mistranslation [Description] The content of the target mistranslates the content of the source. [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]

Output: Issues related to translation of specific terms related to the domain or task-specific language are to be categorized as terminology issues.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] omission [Description] Necessary text has been omitted from the localization or source. [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]

Output: This value is not to be used for missing whitespace or formatting codes, but instead has to be reserved for linguistic content.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] untranslated [Description] Content that has been intended for translation is left 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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-specific-content [Description] The localization contains content that does not apply to the locale for which it was prepared. [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]

Output: Legally inappropriate material is to be classified as legal.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] locale-violation [Description] Text violates norms for the intended locale. [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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] characters [Description] The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears. [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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] numbers [Description] Numbers are inconsistent between source and target. [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]

Output: 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).

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] pattern-problem [Description] The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content). [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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] internationalization [Description] There is an issue related to the internationalization of content. [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]

Output: There are many kinds of internationalization issues. This value is therefore very heterogeneous in what it can refer to.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] length [Description] There is a significant difference in source and target length. [Example] The translation of a segment is five times as long as the source. [Scope] S or T [Notes]

Output: What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] non-conformance [Description] The content is deemed to show poor statistical conformance to a reference corpus. Higher severity values reflect poorer 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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] uncategorized [Description] The issue either has not been categorized or cannot be categorized. [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]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Value] other [Description] Any issue that cannot be assigned to any values listed above. [Scope] S or T [Notes]

Output: 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.

Internationalization Tag Set (ITS) Version 2.0


Input: [Level] -1 [Preserves]

Output: Preserves only a subset of the XPath data model Level -1 defines the class of candidates that preserve a subset of the XPath 1.0 data model. For example, a candidate might not preserve namespace prefixes.

Efficient XML Interchange Measurements Note

Table 1: The Fidelity Scale for Classification of EXI Candidates


Input: [Level] 0 [Preserves]

Output: Preserves the XPath data model Level 0 defines the class of candidates that preserve the XPath 1.0 data model. Such preservation includes the root node, elements, text nodes, attributes (not including namespace declarations), namespaces, processing instructions and comments. Unexpanded entities, the document type declaration and the internal subset are not preserved. This level corresponds to a common denominator in XML processing, it is equivalent to the SOAP XML subset with the addition of processing instructions and comments.

Efficient XML Interchange Measurements Note


Input: [Level] 1 [Preserves]

Output: Preserves the XML Information Set Level 1 defines the class of candidates that preserve the XML Information Set data model. The XML Information Set preserves more of the information represented in the document type declaration and internal subset than the XPath 1.0 data model but not all information, such as attribute and element declarations, is preserved. The [all declarations processed] property of the Document Information Item is not, strictly speaking, part of the Infoset [XML Infoset] and therefore does not need to be preserved. NOTE: A candidate can fully support level 1, level 2, and the preservation of the complete internal subset by including and encoding the internal subset as a string, thereby leaving it up to the decoder to optionally process it.

Efficient XML Interchange Measurements Note


Input: [Level] 2 [Preserves]

Output: Preserves the the XML Information Set and all declarations Level 2 defines the class of candidates that preserve the XML Information Set data model, as in level 1, in addition to all information that is not purely syntactic. Such additional information will include the attribute, element and entity declarations. This level covers the preservation of all information represented by an XML document but does not accede to supporting purely syntactic constructs. NOTE: A candidate can fully support level 2 by including and encoding the internal subset as a string, and thus leaving it up to the decoder to optionally process it.

Efficient XML Interchange Measurements Note


Input: [Level] 3 [Preserves]

Output: Preservation of syntactic sugar of the XML document Level 3 defines the class of candidates that preserves all information represented by an XML document, as in level 2, in additional to some but not all syntactic information. NOTE: Full syntactic information is supported by level 4. Such preservation includes but is not limited to: CDATA Sections resolved external entity reference boundaries (when an entity is resolved a candidate will flag the part in the produced infoset where the information included from it starts and ends) the use of single or double quotes characters for quoted strings white space in markup the difference between empty element variants the order of attributes.

Efficient XML Interchange Measurements Note


Input: [Level] 4 [Preserves]

Output: Preservation of bytes Level 4 defines the class of candidates that preserve the XML document byte-per-byte. NOTE: This is the simple level supported by generic encodings such as gzip.

Efficient XML Interchange Measurements Note


Input: [Keyword] "getter" [Purpose] Defines behavior for when an object is indexed for property retrieval. [Special operation]

Output: Getters


Input: [Keyword] "setter" [Purpose] Defines behavior for when an object is indexed for property assignment. [Special operation]

Output: Setters


Input: [Keyword] "creator" [Purpose] Defines behavior for when an object is indexed for property creation. [Special operation]

Output: Creators


Input: [Keyword] "deleter" [Purpose] Defines behavior for when an object is indexed for property deletion. [Special operation]

Output: Deleters


Input: [Keyword] "caller" [Purpose] Defines behavior for when an object is called as if it were a function. [Special operation]

Output: Callers


Input: [Keyword] "stringifier" [Purpose] Defines how an object is converted into a DOMString. [Special operation]

Output: Stringifiers


Input: [Identifier] acceptTracking [Comment] The collected information may be tracked by the Assigner, or may link to a Party with the role function “trackingParty”. [Semantics]

Output: The Assigner requires that the Assignee(s) accepts that the use of the Asset may be tracked

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] attribute [Comment] May link to an Asset with the attribution information. May link to a Party with the role function “attributedParty”. [Semantics]

Output: The Assigner requires that the Assignee(s) attributes the Asset to the Assigner or an attributed Party.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] compensate [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 [Semantics]

Output: 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.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] delete [Comment] Use a constraint to define under which conditions the Asset should be deleted. [Semantics]

Output: The Assigner requires that the Assignee(s) permanently removes all copies of the Asset.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] ensureExclusivity [Semantics]

Output: The Assignee requires that the Assigner(s) ensure(s) that the permission on the Asset is exclusive to the Assignee.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] include [Comment] For example; Bio picture must be included in the attribution. Use of the Asset relation attribute is required [Semantics]

Output: The Assigner requires that the Assignee(s) include(s) other related assets in the Asset.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] inform [Comment] May link to a Party with the role function “informedParty”. [Semantics]

Output: 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.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] nextPolicy [Semantics]

Output: The Assigner requires that the Assignee(s) grants the specified Policy to a third party for their use of the Asset.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] obtainConsent [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”. [Semantics]

Output: 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.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] reviewPolicy [Comment] Used when human intervention is required to review the Policy. May link to an Asset which represents the full Policy information. [Semantics]

Output: The Assigner requires that the Assignee(s) has(ve) a person review the Policy applicable to the Asset.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] uninstall [Comment] The Asset is no longer accessible to the Assignee(s). [Semantics]

Output: 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.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] watermark [Comment] It is recommended to embed a link to the watermark. [Semantics]

Output: The Assigner requires that the Assignee(s) apply(ies) a watermark as provided by the Assigner to the Asset.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Description] An incorrect term or a term from the wrong domain was used or terms are used inconsistently. [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. [Value]

Output: terminology

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The content of the target mistranslates the content of the source. [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. [Value]

Output: mistranslation

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Necessary text has been omitted from the localization or source. [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. [Value]

Output: omission

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Content that has been intended for translation is left 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. [Value]

Output: untranslated

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The translated text contains inappropriate additions. [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 [Value]

Output: addition

Internationalization Tag Set (ITS) Version 2.0


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

Output: duplication

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text is inconsistent with itself or is translated inconsistently (NB: not for use with terminology 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 [Value]

Output: inconsistency

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text contains a grammatical error (including errors of syntax and morphology). [Example] The text reads "The guidelines says that users should use a static grounding strap." [Scope] S or T [Value]

Output: grammar

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text is legally problematic (e.g., it is specific to the wrong legal system). [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 [Value]

Output: legal

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text is written in the wrong linguistic register of uses slang or other language variants inappropriate to the text. [Example] A financial text in U.S. English refers to dollars as "bucks". [Scope] S or T [Value]

Output: register

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The localization contains content that does not apply to the locale for which it was prepared. [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. [Value]

Output: locale-specific-content

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Text violates norms for the intended locale. [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. [Value]

Output: locale-violation

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text contains stylistic errors. [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 [Value]

Output: style

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears. [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. [Value]

Output: characters

Internationalization Tag Set (ITS) Version 2.0


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

Output: misspelling

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text has typographical errors such as omitted/incorrect punctuation, incorrect capitalization, etc. [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 [Value]

Output: typographical

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text is formatted incorrectly. [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 [Value]

Output: formatting

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The source and target text contain different named entities (dates, times, place names, individual names, etc.) [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 [Value]

Output: inconsistent-entities

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Numbers are inconsistent between source and target. [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). [Value]

Output: numbers

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] There is an issue related to markup or a mismatch in markup between source and target. [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 [Value]

Output: markup

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content). [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. [Value]

Output: pattern-problem

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] There is a mismatch in whitespace between source and target content or the text violates specific rules related to the use of 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 [Value]

Output: whitespace

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] There is an issue related to the internationalization of content. [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. [Value]

Output: internationalization

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] There is a significant difference in source and target 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. [Value]

Output: length

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The content is deemed to show poor statistical conformance to a reference corpus. Higher severity values reflect poorer 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. [Value]

Output: non-conformance

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The issue either has not been categorized or cannot be categorized. [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. [Value]

Output: uncategorized

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Any issue that cannot be assigned to any values listed above. [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. [Value]

Output: other

Internationalization Tag Set (ITS) Version 2.0


Input: [0] GET [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict, GSP returns undefined [LDP Collection = GSP endpoint] No conflict, GSP returns undefined [LDP Collection = GSP graph]

Output: No conflict

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] HEAD [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP graph]

Output: No conflict; added LDP headers

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] OPTIONS [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP graph]

Output: No conflict; added LDP headers

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] PUT [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] Conflict [LDP Collection = GSP endpoint] Conflict [LDP Collection = GSP graph]

Output: No conflict

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] POST [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] Conflict [LDP Collection = GSP endpoint] Conflict [LDP Collection = GSP graph]

Output: No conflict? Different functionality is to be expected, but do not influence each other

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] DELETE [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict [LDP Collection = GSP endpoint] No conflict [LDP Collection = GSP graph]

Output: No conflict

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] PATCH [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict [LDP Collection = GSP endpoint] No conflict [LDP Collection = GSP graph]

Output: Conflict; changes through GSP can break consistency in LDPC

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [Definition] Character data [Attribute Type]

Output: CDATA

Building XHTML Modules - Defining Abstract Modules


Input: [Definition] A document-unique identifier [Attribute Type]

Output: ID

Building XHTML Modules - Defining Abstract Modules