Input: [Event Identifier] click [Description] Occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: mousedown, mouseup, click. If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition. [Animation event name] click [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] mousedown [Description] Occurs when the pointing device button is pressed over an element. [Animation event name] mousedown [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] mouseup [Description] Occurs when the pointing device button is released over an element. [Animation event name] mouseup [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] mouseover [Description] Occurs when the pointing device is moved onto an element. [Animation event name] mouseover [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] mousemove [Description] Occurs when the pointing device is moved while it is over an element. [Animation event name] mousemove [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] mouseout [Description] Occurs when the pointing device is moved away from an element. [Animation event name] mouseout [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] textInput [Description] One or more characters have been entered. [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] TextEvent [DOM3 event category]

Output: TextEvent


Input: [Event Identifier] keydown [Description] A key is pressed down. (The normative definition of this event is the description in the DOM3 Events specification.) [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] KeyboardEvent [DOM3 event category]

Output: KeyboardEvent


Input: [Event Identifier] keyup [Description] A key is released. (The normative definition of this event is the description in the DOM3 Events specification.) [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] KeyboardEvent [DOM3 event category]

Output: KeyboardEvent


Input: [Event Identifier] load [Description] The event is triggered at the point at which the user agent finishes loading the element and any dependent resources (such as images, style sheets, or scripts). In the case the element references a script, the event will be raised only after an attempt to interpret the script has been made. Dependent resources that fail to load will not prevent this event from firing if the element that referenced them is still accessible via the DOM unless they are designated as externalResourcesRequired. The event is independent of the means by which the element was added to DOM tree. [Animation event name] load [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [DOM3 event category]

Output: BasicEvent


Input: [Event Identifier] SVGLoad [Description] This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the load event, but the load event must be sent before the SVGLoad event. [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [DOM3 event category]


Input: [Event Identifier] resize [Description] Occurs when a document view is being resized. This event is only applicable to 'svg' elements and is dispatched after the resize operation has taken place. The target of the event is the 'svg' element. [Animation event name] resize [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [DOM3 event category]

Output: BasicEvent


Input: [Event Identifier] SVGResize [Description] This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the resize event, but the resize event must be sent before the SVGResize event. [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [DOM3 event category]


Input: [Event Identifier] scroll [Description] Occurs when a document view is being shifted along the X or Y or both axis, either through a direct user interaction or any change on the currentTranslate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the shift modification has taken place. The target of the event is the 'svg' element. [Animation event name] scroll [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [DOM3 event category]

Output: BasicEvent


Input: [Event Identifier] SVGScroll [Description] This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the scroll event, but the scroll event must be sent before the SVGScroll event. [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [DOM3 event category]


Input: [Event Identifier] SVGZoom [Description] Occurs when the zoom level of a document view is being changed, either through a direct user interaction or any change to the currentScale property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the zoom level modification has taken place. The target of the event is the 'svg' element. [Animation event name] zoom [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [DOM3 event category]


Input: [Event Identifier] SVGRotate [Description] Occurs when the rotation of a document view is being changed, either through a direct user interaction or any change to the currentRotate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the rotation modification has taken place. The target of the event is the 'svg' element. [Animation event name] rotate [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [DOM3 event category]


Input: [Event Identifier] beginEvent [Description] Occurs when a Timed Element begins. For details, see the description of the Events and event model in SMIL 2.1. [Animation event name] beginEvent [Bubbling phase] Yes [Cancel -able] No [uDOM interface] TimeEvent [DOM3 event category]


Input: [Event Identifier] endEvent [Description] Occurs when a Timed Element ends. For details, see the description of the Events and event model in SMIL 2.1. [Animation event name] endEvent [Bubbling phase] Yes [Cancel -able] No [uDOM interface] TimeEvent [DOM3 event category]


Input: [Event Identifier] repeatEvent [Description] Occurs when a Timed Element repeats. It is raised each time the element repeats, after the first iteration. For details, see the description of the Events and event model in SMIL 2.1. [Animation event name] repeatEvent [Bubbling phase] Yes [Cancel -able] No [uDOM interface] TimeEvent [DOM3 event category]


Input: [Event Identifier] SVGMousewheel [Description] Occurs when a rotational input device has been activated. [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] WheelEvent [DOM3 event category]

Output: MouseEvent


Input: [Event Identifier] SVGPreload [Description] A load operation has begun. [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] ProgressEvent [DOM3 event category]


Input: [Event Identifier] SVGLoadProgress [Description] Progress has occurred in loading a given resource. [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] ProgressEvent [DOM3 event category]


Input: [Event Identifier] SVGPostload [Description] A load operation has completed. [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] ProgressEvent [DOM3 event category]


Input: [Event Identifier] SVGTimer [Description] Occurs when the specified timer interval has elapsed for a timer. This event is triggered only by 'running' timers in the current global execution context of the SVG document (i.e. for timers which have been instantiated via the SVGGlobal interface and started via the start() method of the Timer interface). The target of the event is the 'timer' object itself. The event processing is limited to the target phase. [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [DOM3 event category]


Input: [Event Identifier] SVGConnectionConnected [Description] Occurs when a connection has been established. No context information is available. [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [DOM3 event category]


Input: [Event Identifier] SVGConnectionClosed [Description] Occurs when a connection has been closed. No context information is available [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [DOM3 event category]


Input: [Event Identifier] SVGConnectionError [Description] Occurs when an error happens during the lifetime of a connection. Additional context information is available in the errorCode field. [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [DOM3 event category]


Input: [Event Identifier] SVGConnectionDataSent [Description] Occurs when data has been successfully transmitted. No context information is available. [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [DOM3 event category]


Input: [Event Identifier] SVGConnectionDataReceived [Description] Occurs when data has been received on the connection. Additional context information is available on the receivedData field. [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [DOM3 event category]


Input: [0] Scope [Interest] Determined by Charter [Community] Determined by scope statement [Business] Application of technology to business context; requirements and use cases; input to standards process [Working]

Output: Determined by Charter

Comparison of Group Types | Community and Business Groups


Input: [0] Creation process [Interest] Director proposes charter to Membership [Community] Proposal is complete [Business] Proposal is complete [Working]

Output: Director proposes charter to Membership

Comparison of Group Types | Community and Business Groups


Input: [0] Duration [Interest] Limited by charter, may be extended [Community] Unlimited [Business] Unlimited [Working]

Output: Limited by charter, may be extended

Comparison of Group Types | Community and Business Groups


Input: [0] Primary Deliverable [Interest] Note [Community] Community Group Report (e.g., a technology innovation from a small set of developers). Community Groups Reports are not standards-track documents. [Business] Business Group Report (e.g., use cases or requirements of a particular industry to be provided as input to a Working Group). Business Groups Reports are not standards-track documents. [Working]

Output: Standards-track and supporting

Comparison of Group Types | Community and Business Groups


Input: [0] Staff Contact [Interest] Yes [Community] No [Business] Consulting role (e.g,. share expertise, but not likely to attend meetings regularly). But determined by W3C Management on a case-by-case basis. [Working]

Output: Yes

Comparison of Group Types | Community and Business Groups


Input: [0] Other Staff Interactions [Interest] Background support and coordination (for some) [Community] Monitoring, Outreach [Business] One project review with Team annually Light Monitoring by staff Liaison role as needed Communications of final reports through W3C news channels and to W3C Membership [Working]

Output: Background support and coordination

Comparison of Group Types | Community and Business Groups


Input: [0] Other Coordination [Interest] Via Coordination Groups [Community] Ad-hoc (e.g., organized by Community Development Lead) [Business] Direct Chair-to-Chair connectivity for Business Groups developing material intended as input to a Working Group. [Working]

Output: Via Coordination Groups

Comparison of Group Types | Community and Business Groups


Input: [0] Fee to participate or organize [Interest] Membership or Invited Expert (no fee) [Community] None [Business] Annual fees [Working]

Output: Membership or Invited Expert (no fee)

Comparison of Group Types | Community and Business Groups


Input: [0] Visibility of comms. [Interest] Generally Public [Community] Public (with non-Public for admin) [Business] Public or non-Public [Working]

Output: Public or Member

Comparison of Group Types | Community and Business Groups


Input: [0] Patent Licensing Commitment for this Group’s Deliverables [Interest] No [Community] Defined in section 3 of W3C Community Contributor License Agreement (CLA) or Final Specification Agreement [Business] Defined in section 3 of W3C Community Contributor License Agreement (CLA) or Final Specification Agreement [Working]

Output: Defined for Recommendation track documents in Section 3 of W3C Patent Policy

Comparison of Group Types | Community and Business Groups


Input: [0] Patent Disclosure Obligation [Interest] Defined in Section 6 of W3C Patent Policy [Community] Defined in Section 6 of W3C Patent Policy; no new obligations under CLA/FSA [Business] Defined in Section 6 of W3C Patent Policy; no new obligations under CLA/FSA [Working]

Output: Defined in Section 6 of W3C Patent Policy

Comparison of Group Types | Community and Business Groups


Input: [0] Copyright for documents [Interest] W3C Document License [Community] W3C Community Contributor License Agreement (CLA), Final Specification Agreement [Business] W3C Community Contributor License Agreement (CLA), Final Specification Agreement or W3C Document License [Working]

Output: W3C Document License

Comparison of Group Types | Community and Business Groups


Input: [0] Copyright for software [Interest] W3C Software License [Community] Group determines, but expectation is compatibility with Open Source Software Licenses. [Business] Group determines, but expectation is compatibility with Open Source Software Licenses. [Working]

Output: W3C Software License

Comparison of Group Types | Community and Business Groups


Input: [0] Chair selection [Interest] Appointed by Director [Community] Group determines [Business] Group determines [Working]

Output: Appointed by Director

Comparison of Group Types | Community and Business Groups


Input: [0] Reporting requirement [Interest] None [Community] None [Business] Public reporting expected periodically if group operates primarily internally. [Working]

Output: Heartbeat requirement

Comparison of Group Types | Community and Business Groups


Input: [0] Access to Member site [Interest] Depends on charter [Community] No [Business] No [Working]

Output: Depends on charter

Comparison of Group Types | Community and Business Groups


Input: [0] Decision-making based on consensus [Interest] Required where applicable [Community] Recommended where applicable [Business] Recommended where applicable [Working]

Output: Required

Comparison of Group Types | Community and Business Groups


Input: [0] Expectations regarding scope overlap with other groups [Interest] Actively avoided [Community] Acceptable but not recommended [Business] Acceptable but not recommended [Working]

Output: Actively avoided

Comparison of Group Types | Community and Business Groups


Input: [anyURI Name] Success [Description] The operation succeeded. [Final]

Output: Final

XML Key Management Specification (XKMS 2.0)


Input: [anyURI Name] VersionMismatch [Description] The service does not support the protocol version specified in the request. [Final]

Output: Final

XML Key Management Specification (XKMS 2.0)


Input: [anyURI Name] Sender [Description] An error occurred that was due to the message sent by the sender. [Final]

Output: Final

XML Key Management Specification (XKMS 2.0)


Input: [anyURI Name] Receiver [Description] An error occurred at the receiver. [Final]

Output: Final

XML Key Management Specification (XKMS 2.0)


Input: [anyURI Name] Represent [Description] The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two-phase protocol. [Final]

Output: Not Final

XML Key Management Specification (XKMS 2.0)


Input: [anyURI Name] Pending [Description] The request has been accepted for processing and the service will return the result asynchronously. [Final]

Output: Not Final

XML Key Management Specification (XKMS 2.0)


Input: [User Action/External Input] User presses button on steering wheel [Action on Device] Service is initiated and GPS satellite detection begins [Event Handler] App server returns initial page to device [Resulting Action] Welcome prompts are played. Authentication dialog is initiated (may be initiated via speaker identification or key identification). [Event Description]

Output: HTTP Request to app server


Input: [User Action/External Input] User interacts in an authentication dialog [Action on Device] Device executes authentication dialog using local ASR processing [Event Handler] App server returns initial page to device including user preferences [Resulting Action] User is prompted for a destination (if additional services are availble after authentication, assume that user selects driving direction application) [Event Description]

Output: HTTP Request to app server which includes user credentials


Input: [User Action/External Input] Initial GPS Input [Action on Device] N/A [Event Handler] Device handles location information [Resulting Action] Device updates map on graphical display (assumes all maps are stored locally on device) [Event Description]

Output: GPS_Data_In Event


Input: [User Action/External Input] User selects option to change volume of on-board unit using touch display. [Action on Device] N/A [Event Handler] Touch screen detects and processes input [Resulting Action] Volume indicator changes on screen. Volume of speech output is changed [Event Description]

Output: Touch_screen_event (includes x, y coordinates)


Input: [User Action/External Input] User presses button on steering wheel [Action on Device] Device initiates connection to ASR server [Event Handler] ASR Server receives request and establishes connection [Resulting Action] "listening" icon appears on display (utterances prior to establishing the connection are buffered) [Event Description]

Output: Start_Listening Event


Input: [User Action/External Input] User says destination address (may improve recognition accuracy by sending grammar constraints to server based on a local dialog with the user instead of allowing any address from the start) [Action on Device] N/A [Event Handler] ASR Server processes speech and returns results to device [Resulting Action] Device processes results and plays confirmation dialog to user while highlighting destination and route on graphical display [Event Description]


Input: [User Action/External Input] User confirms destination [Action on Device] Device performs ASR Processing locally. Upon confirmation, destination info is sent to app server [Event Handler] App Server processes input and returns data to device [Resulting Action] Device processes results and updates graphical display with route and directions highlighting next step [Event Description]

Output: HTTP Request is sent to app server (includes current location and destination information)


Input: [User Action/External Input] GPS Input at regular intervals [Action on Device] N/A [Event Handler] Device processes location data and checks if location milestone is hit [Resulting Action] Device updates map on graphical display (assumes all maps are stored locally on device) and highlights current step. When milestone is hit, next instruction is played to user [Event Description]

Output: GPS_Data_In Event


Input: [User Action/External Input] GPS Input at regular intervals (indicating driver is off course) [Action on Device] N/A [Event Handler] Device processes location data and determines that user is off course [Resulting Action] Map on graphical display is updated and textual message is displayed indicating that route is not correct. Prompt is played from the device indicating that route is being recalculated [Event Description]

Output: GPS_Data_In Event


Input: [User Action/External Input] N/A [Action on Device] Route request is sent to app server including new location data [Event Handler] App Server processes input and returns data to device [Resulting Action] Device processes results and updates graphical display with route and directions highlighting next step [Event Description]

Output: HTTP Request is sent to app server (includes current location and destination information)


Input: [User Action/External Input] Alert received on device based on traffic conditions [Action on Device] N/A [Event Handler] Device processes event and initiates dialog to determine if route should be recalculated [Resulting Action] User is informed of traffic conditions and asked whether route should be recalculated. [Event Description]

Output: Route_Change Alert


Input: [User Action/External Input] User requests recalculation of route based on current traffic conditions [Action on Device] Device performs ASR Processing locally. Upon confirmation, destination info is sent to app server [Event Handler] App Server processes input and returns data to device [Resulting Action] Device processes results and updates graphical display with route and directions highlighting next step [Event Description]

Output: HTTP Request is sent to app server (includes current location and destination information)


Input: [User Action/External Input] User presses button on steering wheel [Action on Device] Connection to ASR server is established [Event Handler] ASR Server receives request and establishes connection [Resulting Action] User hears acknowledgement prompt for continuation, and "listening" icon appears on display [Event Description]

Output: Start_Listening Event


Input: [User Action/External Input] User requests new destination by destination type while still depressing button on steering wheel (may improve recognition accuracy by sending grammar constraints to server based on a local dialog with the user) [Action on Device] N/A [Event Handler] ASR Server processes speech and returns results to device [Resulting Action] Device processes results and plays confirmation dialog to user while highlighting destination and route on graphical display [Event Description]


Input: [User Action/External Input] User confirms destination via a multiple interaction dialog to determine exact destination [Action on Device] Device executes dialog based on user responses (using local ASR Processing) and accesses app server as needed [Event Handler] App server responds with appropriate dialog [Resulting Action] User interacts in a dialog and selects destination. User is asked whether this is a new destination [Event Description]

Output: HTTP requests to app server for dialog and data specific to user response


Input: [User Action/External Input] User indicates that this is a stop on the way to original destination [Action on Device] Devices sends updated destination information to app server [Event Handler] App Server processes input and returns data to device [Resulting Action] Device processes results and updates graphical display with new route and directions highlighting next step [Event Description]

Output: HTTP Request for updated directions (based on current location, detour destination, and ultimate destination)


Input: [Disabilitites] Can’t see small items [Mobile device limitations]

Output: Small physical screen


Input: [Disabilitites] Narrow vision [Mobile device limitations]

Output: Zoom interface


Input: [Disabilitites] Color-blindness [Mobile device limitations]

Output: Lightning conditions


Input: [Disabilitites] Motricity troubles [Mobile device limitations]

Output: No mouse, limited keyboard


Input: [Disabilitites] Hearing problems [Mobile device limitations]

Output: Can’t use sound (e.g. socially)


Input: [Disabilitites] Attention disorder [Mobile device limitations]

Output: Limited attention span


Input: [Disabilitites] AT and plug-ins [Mobile device limitations]

Output: Limited plug-ins support


Input: [Disabilitites] Can’t see images [Mobile device limitations]

Output: Download images on demand


Input: [0] Types of Messages [Abstract] Identified [Portable] Identified [Concrete]

Output: Identified


Input: [0] Message Structure [Abstract] Not Defined [Portable] Defined [Concrete]

Output: Defined


Input: [0] Conditions [Abstract] Identified [Portable] Identified [Concrete]

Output: Identified


Input: [0] Condition evaluation rules [Abstract] Not defined [Portable] Defined as far as possible [Concrete]

Output: Defined as far as possible


Input: [0] Technology used [Abstract] Not defined [Portable] Defined [Concrete]

Output: Defined


Input: [0] Message Endpoint Data [Abstract] Not defined [Portable] Not Defined [Concrete]

Output: Defined


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

Table 2.2.2: Terms for entity Action used with Duty


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: [User Action/External Input] User presses button on steering wheel [Action on Device] Service is initiated and GPS satellite detection begins [Event Description] HTTP Request to app server [Event Handler] App server returns initial page to device [Resulting Action]

Output: Welcome prompts are played. Authentication dialog is initiated (may be initiated via speaker identification or key identification).


Input: [User Action/External Input] User interacts in an authentication dialog [Action on Device] Device executes authentication dialog using local ASR processing [Event Description] HTTP Request to app server which includes user credentials [Event Handler] App server returns initial page to device including user preferences [Resulting Action]

Output: User is prompted for a destination (if additional services are availble after authentication, assume that user selects driving direction application)


Input: [User Action/External Input] Initial GPS Input [Action on Device] N/A [Event Description] GPS_Data_In Event [Event Handler] Device handles location information [Resulting Action]

Output: Device updates map on graphical display (assumes all maps are stored locally on device)


Input: [User Action/External Input] User selects option to change volume of on-board unit using touch display. [Action on Device] N/A [Event Description] Touch_screen_event (includes x, y coordinates) [Event Handler] Touch screen detects and processes input [Resulting Action]

Output: Volume indicator changes on screen. Volume of speech output is changed


Input: [User Action/External Input] User presses button on steering wheel [Action on Device] Device initiates connection to ASR server [Event Description] Start_Listening Event [Event Handler] ASR Server receives request and establishes connection [Resulting Action]

Output: "listening" icon appears on display (utterances prior to establishing the connection are buffered)


Input: [User Action/External Input] User says destination address (may improve recognition accuracy by sending grammar constraints to server based on a local dialog with the user instead of allowing any address from the start) [Action on Device] N/A [Event Description] N/A [Event Handler] ASR Server processes speech and returns results to device [Resulting Action]

Output: Device processes results and plays confirmation dialog to user while highlighting destination and route on graphical display


Input: [User Action/External Input] User confirms destination [Action on Device] Device performs ASR Processing locally. Upon confirmation, destination info is sent to app server [Event Description] HTTP Request is sent to app server (includes current location and destination information) [Event Handler] App Server processes input and returns data to device [Resulting Action]

Output: Device processes results and updates graphical display with route and directions highlighting next step


Input: [User Action/External Input] GPS Input at regular intervals [Action on Device] N/A [Event Description] GPS_Data_In Event [Event Handler] Device processes location data and checks if location milestone is hit [Resulting Action]

Output: Device updates map on graphical display (assumes all maps are stored locally on device) and highlights current step. When milestone is hit, next instruction is played to user


Input: [User Action/External Input] GPS Input at regular intervals (indicating driver is off course) [Action on Device] N/A [Event Description] GPS_Data_In Event [Event Handler] Device processes location data and determines that user is off course [Resulting Action]

Output: Map on graphical display is updated and textual message is displayed indicating that route is not correct. Prompt is played from the device indicating that route is being recalculated


Input: [User Action/External Input] N/A [Action on Device] Route request is sent to app server including new location data [Event Description] HTTP Request is sent to app server (includes current location and destination information) [Event Handler] App Server processes input and returns data to device [Resulting Action]

Output: Device processes results and updates graphical display with route and directions highlighting next step


Input: [User Action/External Input] Alert received on device based on traffic conditions [Action on Device] N/A [Event Description] Route_Change Alert [Event Handler] Device processes event and initiates dialog to determine if route should be recalculated [Resulting Action]

Output: User is informed of traffic conditions and asked whether route should be recalculated.


Input: [User Action/External Input] User requests recalculation of route based on current traffic conditions [Action on Device] Device performs ASR Processing locally. Upon confirmation, destination info is sent to app server [Event Description] HTTP Request is sent to app server (includes current location and destination information) [Event Handler] App Server processes input and returns data to device [Resulting Action]

Output: Device processes results and updates graphical display with route and directions highlighting next step


Input: [User Action/External Input] User presses button on steering wheel [Action on Device] Connection to ASR server is established [Event Description] Start_Listening Event [Event Handler] ASR Server receives request and establishes connection [Resulting Action]

Output: User hears acknowledgement prompt for continuation, and "listening" icon appears on display


Input: [User Action/External Input] User requests new destination by destination type while still depressing button on steering wheel (may improve recognition accuracy by sending grammar constraints to server based on a local dialog with the user) [Action on Device] N/A [Event Description] N/A [Event Handler] ASR Server processes speech and returns results to device [Resulting Action]

Output: Device processes results and plays confirmation dialog to user while highlighting destination and route on graphical display


Input: [User Action/External Input] User confirms destination via a multiple interaction dialog to determine exact destination [Action on Device] Device executes dialog based on user responses (using local ASR Processing) and accesses app server as needed [Event Description] HTTP requests to app server for dialog and data specific to user response [Event Handler] App server responds with appropriate dialog [Resulting Action]

Output: User interacts in a dialog and selects destination. User is asked whether this is a new destination


Input: [User Action/External Input] User indicates that this is a stop on the way to original destination [Action on Device] Devices sends updated destination information to app server [Event Description] HTTP Request for updated directions (based on current location, detour destination, and ultimate destination) [Event Handler] App Server processes input and returns data to device [Resulting Action]

Output: Device processes results and updates graphical display with new route and directions highlighting next step


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


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: [Final] Final [Description] The operation succeeded. [QName Local Name]

Output: Success

XML Key Management Specification (XKMS 2.0)


Input: [Final] Final [Description] The service does not support the protocol version specified in the request. [QName Local Name]

Output: VersionMismatch

XML Key Management Specification (XKMS 2.0)


Input: [Final] Final [Description] An error occurred that was due to the message sent by the sender. [QName Local Name]

Output: Sender

XML Key Management Specification (XKMS 2.0)


Input: [Final] Final [Description] An error occurred at the receiver. [QName Local Name]

Output: Receiver

XML Key Management Specification (XKMS 2.0)


Input: [Final] Not Final [Description] The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two phase protocol [QName Local Name]

Output: Represent

XML Key Management Specification (XKMS 2.0)


Input: [Final] Not Final [Description] The request has been accepted for processing and the service will return the result asynchronously [QName Local Name]

Output: Pending

XML Key Management Specification (XKMS 2.0)


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

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


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [0] Types of Messages [Abstract] Identified [Concrete] Identified [Portable]

Output: Identified


Input: [0] Message Structure [Abstract] Not Defined [Concrete] Defined [Portable]

Output: Defined


Input: [0] Conditions [Abstract] Identified [Concrete] Identified [Portable]

Output: Identified


Input: [0] Condition evaluation rules [Abstract] Not defined [Concrete] Defined as far as possible [Portable]

Output: Defined as far as possible


Input: [0] Technology used [Abstract] Not defined [Concrete] Defined [Portable]

Output: Defined


Input: [0] Message Endpoint Data [Abstract] Not defined [Concrete] Defined [Portable]

Output: Not Defined


Input: [Identifier] eq [Semantics]

Output: The “Equals” operator indicating that a given value equals the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.3.2: Terms for the attribute “operator” of the entity Constraint


Input: [Identifier] gt [Semantics]

Output: The “Greater Than” operator indicating that a given value is greater than the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] gteq [Semantics]

Output: The “Greater Than or Equal To” operator indicating that a given value is greater than or equal to the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] hasPart [Semantics]

Output: The “Has Part” operator indicating that a given value contains the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isA [Semantics]

Output: The “Is A” operator indicating that a given value is an instance of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isAllOf [Semantics]

Output: The “Is All Of” operator indicating that a given value is all of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isAnyOf [Semantics]

Output: The “Is Any Of” operator indicating that a given value is any of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isNoneOf [Semantics]

Output: The “Is None Of” operator indicating that a given value is none of the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] isPartOf [Semantics]

Output: The “Is Part Of” operator indicating that a given value is contained by the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] lt [Semantics]

Output: The “Less Than” operator indicating that a given value is less than the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] lteq [Semantics]

Output: The “Less Than or Equal To” operator indicating that a given value is less than or equal to the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] neq [Semantics]

Output: The “Not Equal To” operator indicating that a given value is not equal to the rightOperand of the Constraint

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Individual

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

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


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

Output: Group

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: All

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: AllConnections

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: All2ndConnections

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: AllGroups

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [0] Types of Messages [Portable] Identified [Concrete] Identified [Abstract]

Output: Identified


Input: [0] Message Structure [Portable] Defined [Concrete] Defined [Abstract]

Output: Not Defined


Input: [0] Conditions [Portable] Identified [Concrete] Identified [Abstract]

Output: Identified


Input: [0] Condition evaluation rules [Portable] Defined as far as possible [Concrete] Defined as far as possible [Abstract]

Output: Not defined


Input: [0] Technology used [Portable] Defined [Concrete] Defined [Abstract]

Output: Not defined


Input: [0] Message Endpoint Data [Portable] Not Defined [Concrete] Defined [Abstract]

Output: Not defined


Input: [Patterns] RDF terms [Query Forms] SELECT [Other] BINDINGS [Modifiers]

Output: DISTINCT


Input: [Patterns] Property path expression [Query Forms] CONSTRUCT [Other] SERVICE [Modifiers]

Output: REDUCED


Input: [Patterns] Property path patterns [Query Forms] DESCRIBE [Modifiers]

Output: Projection


Input: [Patterns] Groups [Query Forms] ASK [Modifiers]

Output: ORDER BY


Input: [Patterns] OPTIONAL [Modifiers]

Output: LIMIT


Input: [Patterns] UNION [Modifiers]

Output: OFFSET


Input: [Patterns] GRAPH [Modifiers]

Output: Select expressions


Input: [Event Identifier] DOMFocusIn [Description] Occurs when an element receives focus. [DOM3 event category] UIEvent [Animation event name] focusin [Bubbling phase] Yes [uDOM interface] UIEvent [Cancel -able]

Output: No


Input: [Event Identifier] DOMFocusOut [Description] Occurs when an element loses focus. [DOM3 event category] UIEvent [Animation event name] focusout [Bubbling phase] Yes [uDOM interface] UIEvent [Cancel -able]

Output: No


Input: [Event Identifier] DOMActivate [Description] Occurs when an element is activated, for instance, through a mouse click or a keypress. [DOM3 event category] UIEvent [Animation event name] activate [Bubbling phase] Yes [uDOM interface] UIEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] click [Description] Occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: mousedown, mouseup, click. If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition. [DOM3 event category] MouseEvent [Animation event name] click [Bubbling phase] Yes [uDOM interface] MouseEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] mousedown [Description] Occurs when the pointing device button is pressed over an element. [DOM3 event category] MouseEvent [Animation event name] mousedown [Bubbling phase] Yes [uDOM interface] MouseEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] mouseup [Description] Occurs when the pointing device button is released over an element. [DOM3 event category] MouseEvent [Animation event name] mouseup [Bubbling phase] Yes [uDOM interface] MouseEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] mouseover [Description] Occurs when the pointing device is moved onto an element. [DOM3 event category] MouseEvent [Animation event name] mouseover [Bubbling phase] Yes [uDOM interface] MouseEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] mousemove [Description] Occurs when the pointing device is moved while it is over an element. [DOM3 event category] MouseEvent [Animation event name] mousemove [Bubbling phase] Yes [uDOM interface] MouseEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] mouseout [Description] Occurs when the pointing device is moved away from an element. [DOM3 event category] MouseEvent [Animation event name] mouseout [Bubbling phase] Yes [uDOM interface] MouseEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] textInput [Description] One or more characters have been entered. [DOM3 event category] TextEvent [Animation event name] none [Bubbling phase] Yes [uDOM interface] TextEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] keydown [Description] A key is pressed down. (The normative definition of this event is the description in the DOM3 Events specification.) [DOM3 event category] KeyboardEvent [Animation event name] none [Bubbling phase] Yes [uDOM interface] KeyboardEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] keyup [Description] A key is released. (The normative definition of this event is the description in the DOM3 Events specification.) [DOM3 event category] KeyboardEvent [Animation event name] none [Bubbling phase] Yes [uDOM interface] KeyboardEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] load [Description] The event is triggered at the point at which the user agent finishes loading the element and any dependent resources (such as images, style sheets, or scripts). In the case the element references a script, the event will be raised only after an attempt to interpret the script has been made. Dependent resources that fail to load will not prevent this event from firing if the element that referenced them is still accessible via the DOM unless they are designated as externalResourcesRequired. The event is independent of the means by which the element was added to DOM tree. [DOM3 event category] BasicEvent [Animation event name] load [Bubbling phase] No [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] SVGLoad [Description] This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the load event, but the load event must be sent before the SVGLoad event. [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] resize [Description] Occurs when a document view is being resized. This event is only applicable to 'svg' elements and is dispatched after the resize operation has taken place. The target of the event is the 'svg' element. [DOM3 event category] BasicEvent [Animation event name] resize [Bubbling phase] Yes [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] SVGResize [Description] This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the resize event, but the resize event must be sent before the SVGResize event. [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] scroll [Description] Occurs when a document view is being shifted along the X or Y or both axis, either through a direct user interaction or any change on the currentTranslate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the shift modification has taken place. The target of the event is the 'svg' element. [DOM3 event category] BasicEvent [Animation event name] scroll [Bubbling phase] Yes [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] SVGScroll [Description] This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the scroll event, but the scroll event must be sent before the SVGScroll event. [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] SVGZoom [Description] Occurs when the zoom level of a document view is being changed, either through a direct user interaction or any change to the currentScale property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the zoom level modification has taken place. The target of the event is the 'svg' element. [DOM3 event category] none [Animation event name] zoom [Bubbling phase] No [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] SVGRotate [Description] Occurs when the rotation of a document view is being changed, either through a direct user interaction or any change to the currentRotate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the rotation modification has taken place. The target of the event is the 'svg' element. [DOM3 event category] none [Animation event name] rotate [Bubbling phase] No [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] beginEvent [Description] Occurs when a Timed Element begins. For details, see the description of the Events and event model in SMIL 2.1. [DOM3 event category] none [Animation event name] beginEvent [Bubbling phase] Yes [uDOM interface] TimeEvent [Cancel -able]

Output: No


Input: [Event Identifier] endEvent [Description] Occurs when a Timed Element ends. For details, see the description of the Events and event model in SMIL 2.1. [DOM3 event category] none [Animation event name] endEvent [Bubbling phase] Yes [uDOM interface] TimeEvent [Cancel -able]

Output: No


Input: [Event Identifier] repeatEvent [Description] Occurs when a Timed Element repeats. It is raised each time the element repeats, after the first iteration. For details, see the description of the Events and event model in SMIL 2.1. [DOM3 event category] none [Animation event name] repeatEvent [Bubbling phase] Yes [uDOM interface] TimeEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGMousewheel [Description] Occurs when a rotational input device has been activated. [DOM3 event category] MouseEvent [Animation event name] none [Bubbling phase] Yes [uDOM interface] WheelEvent [Cancel -able]

Output: Yes


Input: [Event Identifier] SVGPreload [Description] A load operation has begun. [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [uDOM interface] ProgressEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGLoadProgress [Description] Progress has occurred in loading a given resource. [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [uDOM interface] ProgressEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGPostload [Description] A load operation has completed. [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [uDOM interface] ProgressEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGTimer [Description] Occurs when the specified timer interval has elapsed for a timer. This event is triggered only by 'running' timers in the current global execution context of the SVG document (i.e. for timers which have been instantiated via the SVGGlobal interface and started via the start() method of the Timer interface). The target of the event is the 'timer' object itself. The event processing is limited to the target phase. [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] Event [Cancel -able]

Output: No


Input: [Event Identifier] SVGConnectionConnected [Description] Occurs when a connection has been established. No context information is available. [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] ConnectionEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGConnectionClosed [Description] Occurs when a connection has been closed. No context information is available [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] ConnectionEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGConnectionError [Description] Occurs when an error happens during the lifetime of a connection. Additional context information is available in the errorCode field. [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] ConnectionEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGConnectionDataSent [Description] Occurs when data has been successfully transmitted. No context information is available. [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] ConnectionEvent [Cancel -able]

Output: No


Input: [Event Identifier] SVGConnectionDataReceived [Description] Occurs when data has been received on the connection. Additional context information is available on the receivedData field. [DOM3 event category] none [Animation event name] none [Bubbling phase] No [uDOM interface] ConnectionEvent [Cancel -able]

Output: No


Input: [Expected Values] alternativeText Visual [Description] alternative text is provided for visual content (e.g., the HTML alt attribute). [Augmented Access Mode]

Output: Textual


Input: [Expected Values] longDescription Visual [Description] descriptions are provided for image-based visual content and/or complex structures such as tables, mathematics, diagrams or charts. [Augmented Access Mode]

Output: Textual


Input: [Expected Values] ChemML laTex MathML Visual [Description] The use of one of these specific ASCII/XML encodings for mathematics or chemistry. These can have extensions specified, but are rarely needed. [Augmented Access Mode]

Output: Textual


Input: [Expected Values] transcript Auditory [Description] The addition of a separate transcript to convey the meaning of the audio. [Augmented Access Mode]

Output: Textual


Input: [Expected Values] captions Auditory [Description] The addition of synchronized text (captions) to convey the meaning of the audio. Note that while many captions may be implemented as textual in the transport, users think of them as being a visual appearance. [Augmented Access Mode]

Output: Visual


Input: [Expected Values] signLanguage Auditory [Description] The presentation of audio in sign language in the visual presentation. The most likely extension is an ISO 639 sign language code such as /sgn-en-us for American Sign Language. [Augmented Access Mode]

Output: Visual


Input: [Expected Values] audioDescription Visual [Description] Audio descriptions are available (e.g., via the HTML5 track element). Common extensions are for the various "onImage" refinements noted above. [Augmented Access Mode]

Output: Auditory


Input: [Expected Values] braille Visual or Textual [Description] braille content or alternative is available (e.g., eBraille or print braille). This can have extensions for the different types of braille (/ASCII, /unicode, /music, /math, /chem or /nemeth) as well as /grade1 and /grade2 (contracted) or other nomenclature: we are sure that the community will contribute more suggestions.) [Augmented Access Mode]

Output: Tactile


Input: [Expected Values] tactileGraphic Visual [Description] tactile graphics have been provided, as described in the BANA Guidelines and Standards for Tactile Graphics. [Augmented Access Mode]

Output: Tactile


Input: [Expected Values] tactileObject Visual [Description] tactile 3D objects have been defined and a 3D object or instructions to build one are available. [Augmented Access Mode]

Output: Tactile


Input: [Working] Determined by Charter [Interest] Determined by Charter [Community] Determined by scope statement [Business] Application of technology to business context; requirements and use cases; input to standards process [0]

Output: Scope

Comparison of Group Types | Community and Business Groups


Input: [Working] Director proposes charter to Membership [Interest] Director proposes charter to Membership [Community] Proposal is complete [Business] Proposal is complete [0]

Output: Creation process

Comparison of Group Types | Community and Business Groups


Input: [Working] Limited by charter, may be extended [Interest] Limited by charter, may be extended [Community] Unlimited [Business] Unlimited [0]

Output: Duration

Comparison of Group Types | Community and Business Groups


Input: [Working] Standards-track and supporting [Interest] Note [Community] Community Group Report (e.g., a technology innovation from a small set of developers). Community Groups Reports are not standards-track documents. [Business] Business Group Report (e.g., use cases or requirements of a particular industry to be provided as input to a Working Group). Business Groups Reports are not standards-track documents. [0]

Output: Primary Deliverable

Comparison of Group Types | Community and Business Groups


Input: [Working] Yes [Interest] Yes [Community] No [Business] Consulting role (e.g,. share expertise, but not likely to attend meetings regularly). But determined by W3C Management on a case-by-case basis. [0]

Output: Staff Contact

Comparison of Group Types | Community and Business Groups


Input: [Working] Background support and coordination [Interest] Background support and coordination (for some) [Community] Monitoring, Outreach [Business] One project review with Team annually Light Monitoring by staff Liaison role as needed Communications of final reports through W3C news channels and to W3C Membership [0]

Output: Other Staff Interactions

Comparison of Group Types | Community and Business Groups


Input: [Working] Via Coordination Groups [Interest] Via Coordination Groups [Community] Ad-hoc (e.g., organized by Community Development Lead) [Business] Direct Chair-to-Chair connectivity for Business Groups developing material intended as input to a Working Group. [0]

Output: Other Coordination

Comparison of Group Types | Community and Business Groups


Input: [Working] Membership or Invited Expert (no fee) [Interest] Membership or Invited Expert (no fee) [Community] None [Business] Annual fees [0]

Output: Fee to participate or organize

Comparison of Group Types | Community and Business Groups


Input: [Working] Public or Member [Interest] Generally Public [Community] Public (with non-Public for admin) [Business] Public or non-Public [0]

Output: Visibility of comms.

Comparison of Group Types | Community and Business Groups


Input: [Working] Defined for Recommendation track documents in Section 3 of W3C Patent Policy [Interest] No [Community] Defined in section 3 of W3C Community Contributor License Agreement (CLA) or Final Specification Agreement [Business] Defined in section 3 of W3C Community Contributor License Agreement (CLA) or Final Specification Agreement [0]

Output: Patent Licensing Commitment for this Group’s Deliverables

Comparison of Group Types | Community and Business Groups


Input: [Working] Defined in Section 6 of W3C Patent Policy [Interest] Defined in Section 6 of W3C Patent Policy [Community] Defined in Section 6 of W3C Patent Policy; no new obligations under CLA/FSA [Business] Defined in Section 6 of W3C Patent Policy; no new obligations under CLA/FSA [0]

Output: Patent Disclosure Obligation

Comparison of Group Types | Community and Business Groups


Input: [Working] W3C Document License [Interest] W3C Document License [Community] W3C Community Contributor License Agreement (CLA), Final Specification Agreement [Business] W3C Community Contributor License Agreement (CLA), Final Specification Agreement or W3C Document License [0]

Output: Copyright for documents

Comparison of Group Types | Community and Business Groups


Input: [Working] W3C Software License [Interest] W3C Software License [Community] Group determines, but expectation is compatibility with Open Source Software Licenses. [Business] Group determines, but expectation is compatibility with Open Source Software Licenses. [0]

Output: Copyright for software

Comparison of Group Types | Community and Business Groups


Input: [Working] Appointed by Director [Interest] Appointed by Director [Community] Group determines [Business] Group determines [0]

Output: Chair selection

Comparison of Group Types | Community and Business Groups


Input: [Working] Heartbeat requirement [Interest] None [Community] None [Business] Public reporting expected periodically if group operates primarily internally. [0]

Output: Reporting requirement

Comparison of Group Types | Community and Business Groups


Input: [Working] Depends on charter [Interest] Depends on charter [Community] No [Business] No [0]

Output: Access to Member site

Comparison of Group Types | Community and Business Groups


Input: [Working] Required [Interest] Required where applicable [Community] Recommended where applicable [Business] Recommended where applicable [0]

Output: Decision-making based on consensus

Comparison of Group Types | Community and Business Groups


Input: [Working] Actively avoided [Interest] Actively avoided [Community] Acceptable but not recommended [Business] Acceptable but not recommended [0]

Output: Expectations regarding scope overlap with other groups

Comparison of Group Types | Community and Business Groups


Input: [QName Local Name] Success [Final] Final [Description]

Output: The operation succeeded.

XML Key Management Specification (XKMS 2.0)


Input: [QName Local Name] VersionMismatch [Final] Final [Description]

Output: The service does not support the protocol version specified in the request.

XML Key Management Specification (XKMS 2.0)


Input: [QName Local Name] Sender [Final] Final [Description]

Output: An error occurred that was due to the message sent by the sender.

XML Key Management Specification (XKMS 2.0)


Input: [QName Local Name] Receiver [Final] Final [Description]

Output: An error occurred at the receiver.

XML Key Management Specification (XKMS 2.0)


Input: [QName Local Name] Represent [Final] Not Final [Description]

Output: The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two phase protocol

XML Key Management Specification (XKMS 2.0)


Input: [QName Local Name] Pending [Final] Not Final [Description]

Output: The request has been accepted for processing and the service will return the result asynchronously

XML Key Management Specification (XKMS 2.0)


Input: [Attribute Name] src [Valid Values] a local URI referencing a MediaStream [Additional considerations] N.B. Revocation of the URI does not count as a change to this field. [Attribute Type]

Output: DOMString

Legal values for the properties of a media element bound to a MediaStream


Input: [Attribute Name] currentSrc [Valid Values] a local URI referencing a MediaStream [Additional considerations] - [Attribute Type]

Output: DOMString


Input: [Attribute Name] preload [Valid Values] none [Additional considerations] A MediaStream cannot be preloaded. [Attribute Type]

Output: DOMString


Input: [Attribute Name] buffered [Valid Values] buffered.length MUST return 1. buffered.start(0) MUST return 0. buffered.end(0) MUST return 0. [Additional considerations] A MediaStream cannot be preloaded. Therefore, the amount buffered is always an empty TimeRange. [Attribute Type]

Output: TimeRanges


Input: [Attribute Name] currentTime [Valid Values] Any positive integer. The initial value is 0 and the values increments linearly in real time whenever the stream is playing. [Additional considerations] The value is the current stream position, in seconds. The UA MUST ignore attempts to set this attribute. [Attribute Type]

Output: double


Input: [Attribute Name] duration [Valid Values] Infinity [Additional considerations] A MediaStream does not have a pre-defined duration. If the underlying MediaStream is destroyed, the UA MUST set this property to the value of the last known currentTime. [Attribute Type]

Output: double


Input: [Attribute Name] seeking [Valid Values] false [Additional considerations] A MediaStream is not seekable. Therefore, this attribute MUST always have the value false. [Attribute Type]

Output: boolean


Input: [Attribute Name] defaultPlaybackRate [Valid Values] 1.0 [Additional considerations] A MediaStream is not seekable. Therefore, this attribute MUST always have the value 1.0 and any attempt to alter it MUST fail. [Attribute Type]

Output: double


Input: [Attribute Name] playbackRate [Valid Values] 1.0 [Additional considerations] A MediaStream is not seekable. Therefore, this attribute MUST always have the value 1.0 and any attempt to alter it MUST fail. [Attribute Type]

Output: double


Input: [Attribute Name] played [Valid Values] played.length MUST return 1. played.start(0) MUST return 0. played.end(0) MUST return the last known currentTime. [Additional considerations] A MediaStream's timeline always consists of a single range, starting at 0 and extending up to the currentTime. [Attribute Type]

Output: TimeRanges


Input: [Attribute Name] seekable [Valid Values] seekable.length MUST return 0. seekable.start() MUST return currentTime. seekable.end() MUST return currentTime. [Additional considerations] A MediaStream is not seekable. [Attribute Type]

Output: TimeRanges


Input: [Attribute Name] startDate [Valid Values] Not-a-Number (NaN) [Additional considerations] A MediaStream does not specify a timeline offset. [Attribute Type]

Output: Date


Input: [Attribute Name] loop [Valid Values] false [Additional considerations] A MediaStream has no defined end and therefore cannot be looped. [Attribute Type]

Output: boolean


Input: [Model Aspect] End-point basics [Linked Data Platform (LDP)]

Output: A LDP server exposes at least one URI to a container-type resource. A client can learn about the container and its contents (members), by simply fetching the container. If only the non-member information is needed, a client can request only that. If a client needs to know if it can create things in this container, then usual HTTP methods can be used such as HEAD or OPTIONS to learn about which verbs are permitted on the request URI. Need: It might be useful to define a common property for external vocabularies to use to indicate the end-point, take for example: Alternative: LDP provides no new facilities for web clients to acquire URLs to Containers. Web clients might use out of band knowledge, home resources, POWDER, emailing a friend a link, or any other mechanism deemed appropriate by the application's needs. It is possible for a server to expose a single Container as a home resource, which web clients GET and examine to locate other resources (including other Containers). It is also possible for that same home resource to be serialized and provided to a client as a document. LDP assumes that each client is able to obtain whatever URLs it needs through non-LDP means, and restricts itself to an interaction model for Containers and their members.

Difference between revisions of "ISSUE-37" - Linked Data Platform


Input: [Model Aspect] Container basics [Linked Data Platform (LDP)]

Output: A container has a URI where you can start interacting with the container, at the most basic level you can GET a list of members, and for containers with many members it is likely the response is broken into pages. Through HTTP HEAD/OPTIONS introspection, a client can learn which HTTP verbs are permitted on this. Since LDP containers are described using RDF constructs, a LDP server may allow clients to POST the representation of the container to create it. Need: How are the acceptable content-types communicated via HTTP headers? Alternative: Before asking 'how' acceptable content-types are communicated, we need to agree that doing so is required (should it be in-scope for LDP - part of ISSUE-21 perhaps). In the simplest case, once the client "knows" it is dealing with a conformant LDP Container it does know (at least) that Turtle is supported. If communicating supported content-types is in-scope, then a syntax needs to be defined (either new, or re-used). Potential re-use choices might include (and these are not necessarily mutually exclusive, although to keep clients simple it would help to have at least one required method if it is in-scope): atom:accept predicate(s) on a container Link: <>; rel="self"; type="one acceptable media type value" Linking itself to a POWDER document - I don't see any POWDER syntax covering media types, but it might be possible to re-use atom:accept in this context. Aside: If we do place it in-scope, we have the same question about members, so it might be that we talk about this introspection at the LDPR level and let LDPCs "inherit" it from LDPRs. LDPRs might leave everything optional, and LDPC requires one particular method while allowing others, for example.

Difference between revisions of "ISSUE-37" - Linked Data Platform


Input: [Model Aspect] Creating container members (resources) [Linked Data Platform (LDP)]

Output: Any kind of resource can be listed in a container, and everything that is in a container is represented by a member. Members follow the standardized metadata model defined by RDF. If a client has POSTed a "media resource" (pretty much anything other than RDF) to a container URI, which has one of the media types that the container accepts, the server accepts this media resource and creates the resource, which will then represent this media resource when you list the container contents. The interesting aspect of this setup is that you POST one thing, its representation gets converted by the server to some appropriate storage and its membership added to the container. email: there is only one container, and what you POST determines whether it's self-contained or not. if the POSTed resource contains all data (... in XML), it's what we now call "composition". if the POSTed resource contains a link to "external content" ( in XML), it's what we now call "aggregation". Servers might try to be smart about populating additional data fields for the resource, for example creation date and who created it. They also might consider come properties to be "server managed", i.e. read-only from any client's point of view. ISSUE-11 questions how much the LDP spec constrains them.

Difference between revisions of "ISSUE-37" - Linked Data Platform


Input: [Model Aspect] Member (resource) identity [Linked Data Platform (LDP)]

Output: A container is a set of members and (perhaps) non-member properties, and thus contains a list of members (entries) representing each individual member. The model uses a URI to represent the identity of each member resource, which will be used for identification globally. The identification of the member as an entry, will be represented as using a simple RDF statement: rdfs:member . Note: some proposals on the mailing list for ISSUE-34 include the use of different membership predicates like ldp:owns or ldp:contains in place of rdfs:member. If accepted, those predicates might cover some of the ground for ISSUE-21 (affordances).

Difference between revisions of "ISSUE-37" - Linked Data Platform


Input: [Model Aspect] Interacting with container members [Linked Data Platform (LDP)]

Output: Members are listed when GETting a container, and their data is exposed through regular RDF mechanisms. If members are editable, a client can introspect via HEAD/OPTIONs to see if PUT, PATCH or DELETE verbs are permitted. A server may provide some member data or just a reference to it in the response of a request for container information.

Difference between revisions of "ISSUE-37" - Linked Data Platform


Input: [Model Aspect] Interacting with containers (composition) [Linked Data Platform (LDP)]

Output: Bringing into existence: typically containers just exist, though some servers may allow creation of containers by POSTing a representation of a container to an already-existing container. Removing from existence (DELETEing): containers are like any other HTTP web resource, they have a URI which a server may accept a DELETE request on. The question becomes, what happens to the members when a container is DELETEd? Based on resolution for ISSUE-25, in order for the container to be deleted all its members must also be deleted. There have been proposals for another model of containers, which may or may not have this rule, see ISSUE-34. Removing a member from a container: simply update the container's membership by PATCHing it with a statement to remove the membership triple. The resource still exists, its ownership is unknown (or perhaps a concept of a "default" container?). Adding an existing member to a container: potentially not allowed (ISSUE-25 resolution) Moving a member from one container to another: potentially not allowed (ISSUE-25 resolution) Alternative: PATCH to remove a member is not allowed; the client must DELETE the member to remove it from the container.

Difference between revisions of "ISSUE-37" - Linked Data Platform


Input: [Attribute Name] src [Attribute Type] DOMString [Valid Values] a local URI referencing a MediaStream [Additional considerations]

Output: N.B. Revocation of the URI does not count as a change to this field.


Input: [Attribute Name] currentSrc [Attribute Type] DOMString [Valid Values] a local URI referencing a MediaStream [Additional considerations]


Input: [Attribute Name] preload [Attribute Type] DOMString [Valid Values] none [Additional considerations]

Output: A MediaStream cannot be preloaded.


Input: [Attribute Name] buffered [Attribute Type] TimeRanges [Valid Values] buffered.length MUST return 1. buffered.start(0) MUST return 0. buffered.end(0) MUST return 0. [Additional considerations]

Output: A MediaStream cannot be preloaded. Therefore, the amount buffered is always an empty TimeRange.


Input: [Attribute Name] currentTime [Attribute Type] double [Valid Values] Any positive integer. The initial value is 0 and the values increments linearly in real time whenever the stream is playing. [Additional considerations]

Output: The value is the current stream position, in seconds. The UA MUST ignore attempts to set this attribute.


Input: [Attribute Name] duration [Attribute Type] double [Valid Values] Infinity [Additional considerations]

Output: A MediaStream does not have a pre-defined duration. If the underlying MediaStream is destroyed, the UA MUST set this property to the value of the last known currentTime.


Input: [Attribute Name] seeking [Attribute Type] boolean [Valid Values] false [Additional considerations]

Output: A MediaStream is not seekable. Therefore, this attribute MUST always have the value false.


Input: [Attribute Name] defaultPlaybackRate [Attribute Type] double [Valid Values] 1.0 [Additional considerations]

Output: A MediaStream is not seekable. Therefore, this attribute MUST always have the value 1.0 and any attempt to alter it MUST fail.


Input: [Attribute Name] playbackRate [Attribute Type] double [Valid Values] 1.0 [Additional considerations]

Output: A MediaStream is not seekable. Therefore, this attribute MUST always have the value 1.0 and any attempt to alter it MUST fail.


Input: [Attribute Name] played [Attribute Type] TimeRanges [Valid Values] played.length MUST return 1. played.start(0) MUST return 0. played.end(0) MUST return the last known currentTime. [Additional considerations]

Output: A MediaStream's timeline always consists of a single range, starting at 0 and extending up to the currentTime.


Input: [Attribute Name] seekable [Attribute Type] TimeRanges [Valid Values] seekable.length MUST return 0. seekable.start() MUST return currentTime. seekable.end() MUST return currentTime. [Additional considerations]

Output: A MediaStream is not seekable.


Input: [Attribute Name] startDate [Attribute Type] Date [Valid Values] Not-a-Number (NaN) [Additional considerations]

Output: A MediaStream does not specify a timeline offset.


Input: [Attribute Name] loop [Attribute Type] boolean [Valid Values] false [Additional considerations]

Output: A MediaStream has no defined end and therefore cannot be looped.


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

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Final] Final [Description] The operation succeeded. [QName Local Name]

Output: Success

XML Key Management Specification (XKMS 2.0)


Input: [Final] Final [Description] The service does not support the protocol version specified in the request. [QName Local Name]

Output: VersionMismatch

XML Key Management Specification (XKMS 2.0)


Input: [Final] Final [Description] An error occurred that was due to the message sent by the sender. [QName Local Name]

Output: Sender

XML Key Management Specification (XKMS 2.0)


Input: [Final] Final [Description] An error occurred at the receiver. [QName Local Name]

Output: Receiver

XML Key Management Specification (XKMS 2.0)


Input: [Final] Not Final [Description] The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two phase protocol [QName Local Name]

Output: Represent

XML Key Management Specification (XKMS 2.0)


Input: [Final] Not Final [Description] The request has been accepted for processing and the service will return the result asynchronously [QName Local Name]

Output: Pending

XML Key Management Specification (XKMS 2.0)


Input: [Name] event [Required] false [Attribute Constraints] Must not occur with 'eventexpr'. If the type is http://www.w3.org/TR/scxml/#SCXMLEventProcessor, either this attribute or 'eventexpr' must be present. [Type] EventType.datatype [Default Value] none [Description]

Output: A string indicating the name of message being generated. See E Schema for details on the data type.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] eventexpr [Required] false [Attribute Constraints] Must not occur with 'event'. If the type is http://www.w3.org/TR/scxml/#SCXMLEventProcessor, either this attribute or 'event' must be present. [Type] Value expression [Default Value] none [Description]

Output: A dynamic alternative to 'event'. If this attribute is present, the SCXML Processor MUST evaluate it when the parent element is evaluated and treat the result as if it had been entered as the value of 'event'.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] target [Required] false [Attribute Constraints] Must not occur with 'targetexpr' [Type] URI [Default Value] none [Valid Values] A valid target URI [Description]

Output: The unique identifier of the message target that the platform should send the event to. See 6.2.4 The Target of Send for details.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] targetexpr [Required] false [Attribute Constraints] Must not occur with 'target' [Type] Value expression [Default Value] none [Valid Values] An expression evaluating to a valid target URI [Description]

Output: A dynamic alternative to 'target'. If this attribute is present, the SCXML Processor MUST evaluate it when the parent element is evaluated and treat the result as if it had been entered as the value of 'target'.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] type [Required] false [Attribute Constraints] Must not occur with 'typeexpr' [Type] URI [Default Value] none [Description]

Output: The URI that identifies the transport mechanism for the message. See 6.2.5 The Type of Send for details.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] typeexpr [Required] false [Attribute Constraints] Must not occur with 'type' [Type] value expression [Default Value] none [Description]

Output: A dynamic alternative to 'type'. If this attribute is present, the SCXML Processor MUST evaluate it when the parent element is evaluated and treat the result as if it had been entered as the value of 'type'.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] id [Required] false [Attribute Constraints] Must not occur with 'idlocation'. [Type] xml:ID [Default Value] none [Valid Values] Any valid token [Description]

Output: A string literal to be used as the identifier for this instance of . See 3.14 IDs for details.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] idlocation [Required] false [Attribute Constraints] Must not occur with 'id'. [Type] Location expression [Default Value] none [Valid Values] Any valid location expression [Description]

Output: Any location expression evaluating to a data model location in which a system-generated id can be stored. See below for details.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] delay [Required] false [Attribute Constraints] Must not occur with 'delayexpr' or when the attribute 'target' has the value "_internal". [Type] Duration.datatype [Default Value] None [Valid Values] A time designation as defined in CSS2 [CSS2] format [Description]

Output: Indicates how long the processor should wait before dispatching the message. See E Schema for details on the data type.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] delayexpr [Required] false [Attribute Constraints] Must not occur with 'delay' or when the attribute 'target' has the value "_internal". [Type] Value expression [Default Value] None [Valid Values] A value expression which returns a time designation as defined in CSS2 [CSS2] format [Description]

Output: A dynamic alternative to 'delay'. If this attribute is present, the SCXML Processor MUST evaluate it when the parent element is evaluated and treat the result as if it had been entered as the value of 'delay'.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Name] namelist [Required] false [Attribute Constraints] Must not be specified in conjunction with element. [Type] List of location expressions [Default Value] none [Valid Values] List of data model locations [Description]

Output: A space-separated list of one or more data model locations to be included as attribute/value pairs with the message. (The name of the location is the attribute and the value stored at the location is the value.) See 5.9.2 Location Expressions for details.

State Chart XML (SCXML): State Machine Notation for Control Abstraction


Input: [Term] issuedby [Type] RDF Data Property [Introduced] Section 2.2 [Notes]

Output: Sub property of dcterms:creator and foaf:maker.

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Term] matchesregex [Type] RDF Data Property [Introduced] Section 2.2 [Notes]

Output: RDF/OWL tools must understand the POWDER Semantic Extension to process the semantics of this property.

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Term] notknownto [Type] RDF Data Property [Introduced] Section 3 [Notes]

Output: Property used by a POWDER Processor that it does not have any information about a particular IRI

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Term] Processor [Type] RDF Class [Introduced] Section 3 [Notes]

Output: The class of POWDER Processors

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Term] describedby [Type] RDF Data Property [Introduced] Section 4.1.3 [Notes]

Output: An RDF property that links a described resource to a POWDER document. For use with RDFa and other rich formats.

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Term] Document [Type] RDF Class [Introduced] Section 4.1.3 [Notes]

Output: The class of POWDER documents

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Term] authenticate [Type] RDF Data Property [Introduced] Section 5.1 [Notes]

Output: An RDF property that links a dcterms:Agent or foaf:Agent class to a resource describing how to authenticate its DRs.

Protocol for Web Description Resources (POWDER): Description Resources


Input: [Keyword] hidden [State] Hidden [Data type] An arbitrary string [Control type]


Input: [Keyword] text [State] Text [Data type] Text with no line breaks [Control type]

Output: A text field


Input: [Keyword] search [State] Search [Data type] Text with no line breaks [Control type]

Output: Search field


Input: [Keyword] tel [State] Telephone [Data type] Text with no line breaks [Control type]

Output: A text field


Input: [Keyword] url [State] URL [Data type] An absolute URL [Control type]

Output: A text field


Input: [Keyword] email [State] E-mail [Data type] An e-mail address or list of e-mail addresses [Control type]

Output: A text field


Input: [Keyword] password [State] Password [Data type] Text with no line breaks (sensitive information) [Control type]

Output: A text field that obscures data entry


Input: [Keyword] datetime [State] Date and Time [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC [Control type]

Output: A date and time control


Input: [Keyword] date [State] Date [Data type] A date (year, month, day) with no time zone [Control type]

Output: A date control


Input: [Keyword] month [State] Month [Data type] A date consisting of a year and a month with no time zone [Control type]

Output: A month control


Input: [Keyword] week [State] Week [Data type] A date consisting of a week-year number and a week number with no time zone [Control type]

Output: A week control


Input: [Keyword] time [State] Time [Data type] A time (hour, minute, seconds, fractional seconds) with no time zone [Control type]

Output: A time control


Input: [Keyword] datetime-local [State] Local Date and Time [Data type] A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone [Control type]

Output: A date and time control


Input: [Keyword] number [State] Number [Data type] A numerical value [Control type]

Output: A text field or spinner control


Input: [Keyword] range [State] Range [Data type] A numerical value, with the extra semantic that the exact value is not important [Control type]

Output: A slider control or similar


Input: [Keyword] color [State] Color [Data type] An sRGB color with 8-bit red, green, and blue components [Control type]

Output: A color well


Input: [Keyword] checkbox [State] Checkbox [Data type] A set of zero or more values from a predefined list [Control type]

Output: A checkbox


Input: [Keyword] radio [State] Radio Button [Data type] An enumerated value [Control type]

Output: A radio button


Input: [Keyword] file [State] File Upload [Data type] Zero or more files each with a MIME type and optionally a file name [Control type]

Output: A label and a button


Input: [Keyword] submit [State] Submit Button [Data type] An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission [Control type]

Output: A button


Input: [Keyword] image [State] Image Button [Data type] A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission [Control type]

Output: Either a clickable image, or a button


Input: [Keyword] reset [State] Reset Button [Data type] n/a [Control type]

Output: A button


Input: [Keyword] button [State] Button [Data type] n/a [Control type]

Output: A button


Input: [State] Hidden [Data type] An arbitrary string [Control type] n/a [Keyword]

Output: hidden


Input: [State] Text [Data type] Text with no line breaks [Control type] A text field [Keyword]

Output: text


Input: [State] Search [Data type] Text with no line breaks [Control type] Search field [Keyword]

Output: search


Input: [State] Telephone [Data type] Text with no line breaks [Control type] A text field [Keyword]

Output: tel


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

Output: url


Input: [State] E-mail [Data type] An e-mail address or list of e-mail addresses [Control type] A text field [Keyword]

Output: email


Input: [State] Password [Data type] Text with no line breaks (sensitive information) [Control type] A text field that obscures data entry [Keyword]

Output: password