Input: [Name] text-decoration [Values] none | [ underline || overline || line-through || blink ] [Applies to] text content elements [Inh.] no (see prose) [Percentages] N/A [Media] visual [Anim.] yes [Initial value]


Input: [Name] text-rendering [Values] auto | optimizeSpeed | optimizeLegibility | geometricPrecision [Applies to] ‘text’ elements [Inh.] yes [Percentages] N/A [Media] visual [Anim.] yes [Initial value]

Output: auto


Input: [Name] unicode-bidi [Values] normal | embed | bidi-override [Applies to] text content elements [Inh.] no [Percentages] N/A [Media] visual [Anim.] no [Initial value]

Output: normal


Input: [Name] vector-effect [Values] non-scaling-stroke | none [Applies to] graphics elements [Inh.] no [Percentages] N/A [Media] visual [Anim.] yes [Initial value]


Input: [Name] visibility [Values] visible | hidden | collapse [Applies to] graphics elements (including the ‘text’ element) and text sub-elements (i.e., ‘tspan’, ‘textPath’ and ‘a’) [Inh.] yes [Percentages] N/A [Media] visual [Anim.] yes [Initial value]

Output: visible


Input: [Name] word-spacing [Values] normal | [Applies to] text content elements [Inh.] yes [Percentages] N/A [Media] visual [Anim.] yes [Initial value]

Output: normal


Input: [Name] white-space [Values] normal | pre | nowrap | pre-wrap | pre-line [Applies to] text content elements [Inh.] yes [Percentages] N/A [Media] visual [Anim.] yes [Initial value]

Output: normal


Input: [Name] writing-mode [Values] lr-tb | rl-tb | tb-rl | lr | rl | tb [Applies to] ‘text’ elements [Inh.] yes [Percentages] N/A [Media] visual [Anim.] no [Initial value]

Output: lr-tb


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

Output: Alarm API

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


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

Output: Contacts API

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


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

Output: Messaging API

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


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

Output: Telephony API

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


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

Output: Raw Sockets API

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


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

Output: Supports many device form factors

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


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

Output: DAP API Support

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


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

Output: Minimal user prompting

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


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

Output: HTML5

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


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

Output: Location

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


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

Output: Communicate with other applications

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


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

Output: Communicate with pre-defined endpoints

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


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

Output: Valid across multiple platforms

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


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

Output: Access control log

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


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

Output: API access rationale

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


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

Output: Application capability restriction

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


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

Output: Application intent

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


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

Output: Application isolation

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


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

Output: Application policy approval

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


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

Output: Authenticity check

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


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

Output: Certifier list

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


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

Output: Confidential credentials storage

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


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

Output: Credentials access restriction

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


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

Output: Data management rationale

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


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

Output: Default policy

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


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

Output: Device-identity binding

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


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

Output: Device-identity binding revokation

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


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

Output: Hierarchical policy enforcement

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


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

Output: Secure cache

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


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

Output: Secure storage

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


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

Output: Trusted application source

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


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

Output: App stores can revoke applications

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


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

Output: External trusted party can set app default permissions

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


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

Output: Installation

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


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

Output: Owner override

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


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

Output: App privilege visibility

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


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

Output: Permission usability

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


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

Output: Immunity to browser-based threats

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


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

Output: Pre-installed app permissions

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


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

Output: Access to files outside owned by the platform

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


Input: [Component] FTCaseOption [Default initial value] case insensitive overwriteable overwriteable by prolog [Consistency rules] Value must be case insensitive or case sensitive. [Scope]

Output: lexical

Static Context Components


Input: [Component] FTDiacriticsOption [Default initial value] diacritics insensitive overwriteable overwriteable by prolog [Consistency rules] Value must be diacritics insensitive or diacritics sensitive. [Scope]

Output: lexical

Static Context Components


Input: [Component] FTStemOption [Default initial value] without stemming overwriteable overwriteable by prolog [Consistency rules] Value must be without stemming or with stemming. [Scope]

Output: lexical

Static Context Components


Input: [Component] FTThesaurusOption [Default initial value] without thesaurus overwriteable overwriteable by prolog (refer to default to augment) [Consistency rules] Value must be part of the statically known thesauri. [Scope]

Output: lexical

Static Context Components


Input: [Component] Statically known thesauri [Default initial value] none augmentable cannot be augmented or overwritten by prolog [Consistency rules] Each URI uniquely identifies a thesaurus list. [Scope]

Output: module

Static Context Components


Input: [Component] FTStopWordOption [Default initial value] without stopwords overwriteable overwriteable by prolog (refer to default to augment) [Consistency rules] Value must be part of the statically known stop word lists. [Scope]

Output: lexical

Static Context Components


Input: [Component] Statically known stop word lists [Default initial value] none augmentable cannot be augmented or overwritten by prolog [Consistency rules] Each URI uniquely identifies a stop word list. [Scope]

Output: module

Static Context Components


Input: [Component] FTLanguageOption [Default initial value] no language is selected overwriteable overwriteable by prolog [Consistency rules] Value must be castable to "xs:language" or "none". [Scope]

Output: lexical

Static Context Components


Input: [Component] FTWildCardOption [Default initial value] without wildcards no overwriteable by prolog [Consistency rules] Value must be without wildcards or without wildcards. [Scope]

Output: lexical

Static Context Components


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

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

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


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

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

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


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

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

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


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

Output: Some kind of messaging will be supported

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


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

Output: Access remote domains will be possible

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


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

Output: Apps must have provenance data attached to them

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


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

Output: App permissions can be changed remotely

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


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

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

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


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

Output: Access control settings must be changeable

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


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

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

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


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

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

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


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

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

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


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

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

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


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

Output: Applications can create alarms, notifying users

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


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

Output: Apps can add, remove and edit contacts

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


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

Output: Apps can send, receive and view SMS

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


Input: [Requirement] HTML5 [Description]

Output: Applications consist of HTML, CSS and JavaScript

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


Input: [Requirement] Location [Description]

Output: Applications have access to geolocation data

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


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

Output: Applications can communicate with other applications

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


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

Output: Applications can communicate with pre-defined web addresses

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


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

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

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


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

Output: Allow access control decisions to be logged.

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


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

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

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


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

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

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


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

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

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


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

Output: Applications shall be isolated from each other.

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

Output: Applications must be installed before executed

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


Input: [WSC Clause] I [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] II [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] IIa [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] IV [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] V [Opera] Conforms Optional [Firefox] Does Not Conform Optional [Chrome]

Output: Does Not Conform Optional


Input: [WSC Clause] VI [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] VII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] VIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] IX [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] X [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XIII [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Does Not Conform Optional


Input: [WSC Clause] XIV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XV [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] XVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XVII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XIX [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XX [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] XXI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXIII [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] XXIV [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Does Not Conform Optional


Input: [WSC Clause] XXV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXVII [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] XXVIII [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] XXIX [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] XXX [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] XXXI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXIV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXVII [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] XXXVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XXXIX [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XL [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLI [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] XLII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLIV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLVII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XLIX [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] L [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LI [Opera] Does Not Conform Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LII [Opera] Does Not Conform Advanced [Firefox] Conforms Advanced [Chrome]

Output: Does Not Conform Advanced


Input: [WSC Clause] LIII [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LIV [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LV [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] LVI [Opera] Does Not Conform Optional [Firefox] Does Not Conform Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] LVII [Opera] Does Not Conform Optional [Firefox] Conforms Optional [Chrome]

Output: Does Not Conform Optional


Input: [WSC Clause] LVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LIX [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LX [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXIII [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] LXIV [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] LXV [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXVII [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXVIII [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] LXIX [Opera] Conforms Optional [Firefox] Does Not Conform Optional [Chrome]

Output: Does Not Conform Optional


Input: [WSC Clause] LXX [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXXI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXII [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXXIII [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXXIV [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXXV [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] LXXVI [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] LXXVII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXIX [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXX [Opera] Does Not Conform Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXXXI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXXII [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] LXXXIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXXIV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXXV [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] LXXXVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXXVII [Opera] Conforms Optional [Firefox] Conforms Optional [Chrome]

Output: Conforms Optional


Input: [WSC Clause] LXXXVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] LXXXIX [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] XC [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCII [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] XCIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCIV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCVI [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCVII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCVIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] XCIX [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] C [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] CI [Opera] NA [Firefox] NA [Chrome]


Input: [WSC Clause] CII [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] CIII [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] CIV [Opera] Conforms Basic [Firefox] Conforms Basic [Chrome]

Output: Conforms Basic


Input: [WSC Clause] CV [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


Input: [WSC Clause] CVI [Opera] Conforms Advanced [Firefox] Conforms Advanced [Chrome]

Output: Conforms Advanced


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

Output: yes


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

Output: yes


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

Output: no


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

Output: yes


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

Output: no


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

Output: yes


Input: [Test Case] G.1.a [Link To Spec] G.1 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: enabled and disabled pseudo-classes


Input: [Test Case] G.1.b [Link To Spec] G.1 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: required and optional pseudo-classes


Input: [Test Case] G.1.c [Link To Spec] G.1 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: valid and invalid pseudo-classes


Input: [Test Case] G.1.d [Link To Spec] G.1 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: read-only and read-write pseudo-classes


Input: [Test Case] G.1.e [Link To Spec] G.1 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: out-of-range and in-range pseudo-classes


Input: [Test Case] G.2.a [Link To Spec] G.2 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: value pseudo-element


Input: [Test Case] G.2.b [Link To Spec] G.2 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: repeat-item pseudo-element


Input: [Test Case] G.2.c [Link To Spec] G.2 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: repeat-index pseudo-element


Input: [Test Case] G.2.d [Link To Spec] G.2 [Normative For XForms Basic] false [Normative For XForms Full] false [Description]

Output: repeat-index precedence over repeat-item


Input: [Event name] loadstart [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState equals LOADING [Dispatched when...]

Output: The user agent begins fetching the media data, synchronously during the load() method call.


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState is more than EMPTY and less than LOADED [Dispatched when...]

Output: The user agent is fetching media data.


Input: [Event name] loadedmetadata [Interface] Event [Preconditions] networkState equals LOADED_METADATA [Dispatched when...]

Output: The user agent is fetching media data, and the media resource's metadata has just been received.


Input: [Event name] loadedfirstframe [Interface] Event [Preconditions] networkState equals LOADED_FIRST_FRAME [Dispatched when...]

Output: The user agent is fetching media data, and the media resource's first frame has just been received.


Input: [Event name] load [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState equals LOADED [Dispatched when...]

Output: The user agent finishes downloading the entire media resource.


Input: [Event name] abort [Interface] ProgressEvent [PROGRESS] [Preconditions] error is an object with the code MEDIA_ERR_ABORTED. networkState equals either EMPTY or LOADED, depending on when the download was aborted. [Dispatched when...]

Output: The user agent stops fetching the media data before it is completely downloaded. This can be fired synchronously during the load() method call.


Input: [Event name] error [Interface] ProgressEvent [PROGRESS] [Preconditions] error is an object with the code MEDIA_ERR_NETWORK_ERROR or higher. networkState equals either EMPTY or LOADED, depending on when the download was aborted. [Dispatched when...]

Output: An error occurs while fetching the media data.


Input: [Event name] emptied [Interface] Event [Preconditions] networkState is EMPTY; all the DOM attributes are in their initial states. [Dispatched when...]

Output: A media element whose networkState was previously not in the EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was reinvoked, in which case it is fired synchronously during the load() method call).


Input: [Event name] stalled [Interface] ProgressEvent [Dispatched when...]

Output: The user agent is trying to fetch media data, but data is unexpectedly not forthcoming.


Input: [Event name] play [Interface] Event [Preconditions] paused is newly false. [Dispatched when...]

Output: Playback has begun. Fired after the play method has returned.


Input: [Event name] pause [Interface] Event [Preconditions] paused is newly true. [Dispatched when...]

Output: Playback has been paused. Fired after the pause method has returned.


Input: [Event name] waiting [Interface] Event [Preconditions] readyState is either DATA_UNAVAILABLE or CAN_SHOW_CURRENT_FRAME, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors. [Dispatched when...]

Output: Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course.


Input: [Event name] seeking [Interface] Event [Dispatched when...]

Output: The seeking DOM attribute changed to true and the seek operation is taking long enough that the user agent has time to fire the event.


Input: [Event name] seeked [Interface] Event [Dispatched when...]

Output: The seeking DOM attribute changed to false.


Input: [Event name] timeupdate [Interface] Event [Dispatched when...]

Output: The current playback position changed in an interesting way, for example discontinuously.


Input: [Event name] ended [Interface] Event [Preconditions] currentTime equals the effective end; ended is true. [Dispatched when...]

Output: Playback has stopped because the end of the media resource was reached.


Input: [Event name] dataunavailable [Interface] Event [Preconditions] The readyState attribute is newly equal to DATA_UNAVAILABLE. [Dispatched when...]

Output: The user agent cannot render the data at the current playback position because data for the current frame is not immediately available.


Input: [Event name] canshowcurrentframe [Interface] Event [Preconditions] The readyState attribute is newly equal to CAN_SHOW_CURRENT_FRAME. [Dispatched when...]

Output: The user agent cannot render the data after the current playback position because data for the next frame is not immediately available.


Input: [Event name] canplay [Interface] Event [Preconditions] The readyState attribute is newly equal to CAN_PLAY. [Dispatched when...]

Output: The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content.


Input: [Event name] canplaythrough [Interface] Event [Preconditions] The readyState attribute is newly equal to CAN_PLAY_THROUGH. [Dispatched when...]

Output: The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering.


Input: [Event name] ratechange [Interface] Event [Dispatched when...]

Output: Either the defaultPlaybackRate or the playbackRate attribute has just been updated.


Input: [Event name] durationchange [Interface] Event [Dispatched when...]

Output: The duration attribute has just been updated.


Input: [Event name] volumechange [Interface] Event [Dispatched when...]

Output: Either the volume attribute or the muted attribute has changed. Fired after the relevant attribute's setter has returned.


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

Output: yes


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

Output: yes


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

Output: no


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

Output: yes


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

Output: no


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

Output: yes


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

Output: Textual

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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

Output: Textual

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


Input: [Expected Values] captions Auditory [Description] The addition of synchronized text (closed 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

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


Input: [Expected Values] signLanguage Auditory [Description] The presentation of audio in sign language in the visual presentation. The most likely extension is /sgn-en-us or other ISO 639 sign language code. [Augmented Access Mode]

Output: Visual

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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, /music, /math, /chem or /nemeth) (also consider /contracted and /gradeII or other nomenclature... pretty open) [Augmented Access Mode]

Output: Tactile

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


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

Difference between revisions of "WebSchemas/Accessibility" - W3C Wiki


Input: [media type] xml-stylesheet PI and link [text/html] recognized as HTML [application/xhtml+xml] not supported [text/xml] recognized as XML, parsing failed [application/xml]

Output: recognized as XML, parsing failed

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] link only [text/html] recognized as HTML [application/xhtml+xml] not supported [text/xml] recognized as XML, parsing failed [application/xml]

Output: recognized as XML, parsing failed

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] xml-stylesheet PI only [text/html] recognized as HTML, xml-stylesheet PI was not recognized [application/xhtml+xml] not supported [text/xml] recognized as XML, parsing failed [application/xml]

Output: recognized as XML, parsing failed

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] without xmlns [text/html] recognized as HTML [application/xhtml+xml] not supported [text/xml] recognized as XML, parsing failed [application/xml]

Output: recognized as XML, parsing failed

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] without DOCTYPE [text/html] recognized as HTML [application/xhtml+xml] not supported [text/xml] type 1 error occured, browser crashed [application/xml]

Output: type 1 error occured, browser crashed

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] without DOCTYPE and xmlns [text/html] recognized as HTML [application/xhtml+xml] not supported [text/xml] type 1 error occured, browser crashed [application/xml]

Output: type 1 error occured, browser crashed

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] Broken XHTML [text/html] recognized as HTML, well-formedness error was not checked [application/xhtml+xml] not supported [text/xml] failed correctly [application/xml]

Output: failed correctly

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [media type] HTML 4 [text/html] recognized as HTML [application/xhtml+xml] not supported [text/xml] failed correctly while parsing the DTD [application/xml]

Output: failed correctly while parsing the DTD

XHTML media type test - results: Microsoft Internet Explorer 5.1.4/Mac


Input: [Property] additionalType [Expected Type] URL [Description]

Output: An additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] description [Expected Type] Text [Description]

Output: A short description of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] image [Expected Type] URL [Description]

Output: URL of an image of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] name [Expected Type] Text [Description]

Output: The name of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] url [Expected Type] URL [Description]

Output: URL of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] alternativeHeadline [Expected Type] Text [Description]

Output: A secondary title of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] inLanguage [Expected Type] Language [Description]

Output: The language of the content. Please use one of the language codes from the IETF BCP 47 standard.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] dateCreated [Expected Type] Date [Description]

Output: The date on which the content was created (in ISO 8601 date format).

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] dateModified [Expected Type] Date [Description]

Output: The date on which the content was most recently modified (in ISO 8601 date format).

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] keywords [Expected Type] Text [Description]

Output: The keywords/tags used to describe this content.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] provider [Expected Type] Person or Organization [Description]

Output: Specifies the person or organization that distributed the content.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] breadcrumb [Expected Type] Text [Description]

Output: A set of links that can help a user understand and navigate a website hierarchy.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] entryID [Expected Type] Text [Description]

Output: The identifier of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] isEntryOf [Expected Type] BiologicalDatabase [Description]

Output: Indicates the database to which the entry belongs.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] taxon [Expected Type] BiologicalDatabaseEntry or Text [Description]

Output: The taxonomy information of the entry.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] seeAlso [Expected Type] BiologicalDatabaseEntry or URL [Description]

Output: Reference to another resource.

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] reference [Expected Type] Text [Description]

Output: The identifier of the reference, such as PMID, DOI, and PMCID. For example: .

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Attribute Type] CDATA [Definition]

Output: Character data


Input: [Attribute Type] ID [Definition]

Output: A document-unique identifier


Input: [Attribute Type] IDREF [Definition]

Output: A reference to a document-unique identifier


Input: [Attribute Type] IDREFS [Definition]

Output: A space-separated list of references to document-unique identifiers


Input: [Attribute Type] NAME [Definition]

Output: A name with the same character constraints as ID above


Input: [Attribute Type] NMTOKEN [Definition]

Output: A name composed of only name tokens as defined in XML 1.0 [XML]


Input: [Attribute Type] NMTOKENS [Definition]

Output: One or more whitespace separated NMTOKEN values


Input: [Attribute Type] PCDATA [Definition]

Output: Processed character data


Input: [Component] FTCaseOption [Default initial value] case insensitive overwriteable [Scope] lexical [Consistency rules] Value must be case insensitive or case sensitive.

Output: overwriteable by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] FTDiacriticsOption [Default initial value] diacritics insensitive overwriteable [Scope] lexical [Consistency rules] Value must be diacritics insensitive or diacritics sensitive.

Output: overwriteable by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] FTStemOption [Default initial value] without stemming overwriteable [Scope] lexical [Consistency rules] Value must be without stemming or with stemming.

Output: overwriteable by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] FTThesaurusOption [Default initial value] without thesaurus overwriteable [Scope] lexical [Consistency rules] Value must be part of the statically known thesauri.

Output: overwriteable by prolog (refer to default to augment)

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] Statically known thesauri [Default initial value] none augmentable [Scope] module [Consistency rules] Each URI uniquely identifies a thesaurus list.

Output: cannot be augmented or overwritten by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] FTStopWordOption [Default initial value] without stopwords overwriteable [Scope] lexical [Consistency rules] Value must be part of the statically known stop word lists.

Output: overwriteable by prolog (refer to default to augment)

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] Statically known stop word lists [Default initial value] none augmentable [Scope] module [Consistency rules] Each URI uniquely identifies a stop word list.

Output: cannot be augmented or overwritten by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] FTLanguageOption [Default initial value] no language is selected overwriteable [Scope] lexical [Consistency rules] Value must be castable to "xs:language" or "none".

Output: overwriteable by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [Component] FTWildCardOption [Default initial value] without wildcards no [Scope] lexical [Consistency rules] Value must be without wildcards or without wildcards.

Output: overwriteable by prolog

Static Context Components

Can be overwritten or augmented by a query?


Input: [WSC Clause] I [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] II [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] IIa [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] IV [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] V [Chrome] Does Not Conform Optional [Firefox] Does Not Conform Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] VI [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] VII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] VIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] IX [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] X [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XIII [Chrome] Does Not Conform Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] XIV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XV [Chrome] Conforms Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] XVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XVII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XIX [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XX [Chrome] Conforms Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] XXI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXIII [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] XXIV [Chrome] Does Not Conform Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] XXV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXVII [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] XXVIII [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] XXIX [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] XXX [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] XXXI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXIV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXVII [Chrome] Conforms Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] XXXVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XXXIX [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XL [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLI [Chrome] Conforms Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] XLII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLIV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLVII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XLIX [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] L [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LI [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Does Not Conform Advanced


Input: [WSC Clause] LII [Chrome] Does Not Conform Advanced [Firefox] Conforms Advanced [Opera]

Output: Does Not Conform Advanced


Input: [WSC Clause] LIII [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LIV [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LV [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] LVI [Chrome] Conforms Optional [Firefox] Does Not Conform Optional [Opera]

Output: Does Not Conform Optional


Input: [WSC Clause] LVII [Chrome] Does Not Conform Optional [Firefox] Conforms Optional [Opera]

Output: Does Not Conform Optional


Input: [WSC Clause] LVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LIX [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LX [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXIII [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] LXIV [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] LXV [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXVII [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXVIII [Chrome] Conforms Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] LXIX [Chrome] Does Not Conform Optional [Firefox] Does Not Conform Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] LXX [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXXI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXII [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXXIII [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXXIV [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXXV [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] LXXVI [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] LXXVII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXIX [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXX [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Does Not Conform Advanced


Input: [WSC Clause] LXXXI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXXII [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] LXXXIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXXIV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXXV [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] LXXXVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXXVII [Chrome] Conforms Optional [Firefox] Conforms Optional [Opera]

Output: Conforms Optional


Input: [WSC Clause] LXXXVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] LXXXIX [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] XC [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCII [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] XCIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCIV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCVI [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCVII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCVIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] XCIX [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] C [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] CI [Chrome] NA [Firefox] NA [Opera]


Input: [WSC Clause] CII [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] CIII [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] CIV [Chrome] Conforms Basic [Firefox] Conforms Basic [Opera]

Output: Conforms Basic


Input: [WSC Clause] CV [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [WSC Clause] CVI [Chrome] Conforms Advanced [Firefox] Conforms Advanced [Opera]

Output: Conforms Advanced


Input: [Value] copy: [Description]

Output: A duplicate of the source object will be dropped into the target.

Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0

Values of aria-dropeffect


Input: [Value] move: [Description]

Output: The source object will be removed from its current location and dropped into the target.

Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0

Values of aria-dropeffect


Input: [Value] link: [Description]

Output: A reference or shortcut to the dragged object will be created in the target object.

Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0

Values of aria-dropeffect


Input: [Value] execute: [Description]

Output: A function supported by the drop target is executed, using the drag source as an input.

Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0

Values of aria-dropeffect


Input: [Value] popup: [Description]

Output: There is a popup menu or dialog that allows the user to choose one of the drag operations (copy, move, link, execute) and any other drag functionality, such as cancel.

Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0

Values of aria-dropeffect


Input: [Value] none (default): [Description]

Output: No operation can be performed; effectively cancels the drag operation if an attempt is made to drop on this object. Ignored if combined with any other token value. e.g. 'none copy' is equivalent to a 'copy' value.

Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0

Values of aria-dropeffect


Input: [name] accesskey [values] list of key labels [description]

Output: A key label or list of key labels with which to associate the element; each key label represents a keyboard shortcut which UAs can use to activate the element or give focus to the element. An ordered set of unique space-separated tokens, each of which must be exactly one Unicode code point in length.

Table of Core Attributes


Input: [name] class [values] set of space-separated tokens [description]

Output: A name of a classification, or list of names of classifications, to which the element belongs.

Table of Core Attributes


Input: [name] contenteditable [values] "true" or "false" or "" (empty string) or empty [description]

Output: Specifies whether the contents of the element are editable.

Table of Core Attributes


Input: [name] contextmenu [values] ID reference [description]

Output: The value of the id attribute on the menu with which to associate the element as a context menu.

Table of Core Attributes


Input: [name] dir [values] "ltr" or "rtl" [description]

Output: Specifies the element’s text directionality.

Table of Core Attributes


Input: [name] draggable [values] "true" or "false" [description]

Output: Specifies whether the element is draggable.

Table of Core Attributes


Input: [name] hidden [values] "hidden" or "" (empty string) or empty [description]

Output: Specifies that the element represents an element that is not yet, or is no longer, relevant.

Table of Core Attributes


Input: [name] id [values] ID [description]

Output: A unique identifier for the element. There must not be multiple elements in a document that have the same id value. Any string, with the following restrictions: 1. must be at least one character long 2. must not contain any space characters

Table of Core Attributes


Input: [name] lang [values] language tag [description]

Output: Specifies the primary language for the contents of the element and for any of the element’s attributes that contain text. A valid language tag, as defined in [BCP47].

Table of Core Attributes


Input: [name] spellcheck [values] "true" or "false" or "" (empty string) or empty [description]

Output: Specifies whether the element represents an element whose contents are subject to spell checking and grammar checking.

Table of Core Attributes


Input: [name] style [values] string [description]

Output: Specifies zero or more CSS declarations that apply to the element [CSS].

Table of Core Attributes


Input: [name] tabindex [values] integer [description]

Output: Specifies whether the element represents an element that is is focusable (that is, an element which is part of the sequence of focusable elements in the document), and the relative order of the element in the sequence of focusable elements in the document.

Table of Core Attributes


Input: [name] title [values] normal character data [description]

Output: Advisory information associated with the element.

Table of Core Attributes


Input: [Unicode] E4AF [Description] open face letter A [Name]

Output: Aopf


Input: [Unicode] E4B0 [Description] open face letter B [Name]

Output: Bopf


Input: [Unicode] 2102 [Description] open face letter C [Name]

Output: Copf


Input: [Unicode] E4B1 [Description] open face letter D [Name]

Output: Dopf


Input: [Unicode] E4B2 [Description] open face letter E [Name]

Output: Eopf


Input: [Unicode] E4B3 [Description] open face letter F [Name]

Output: Fopf


Input: [Unicode] E4B4 [Description] open face letter G [Name]

Output: Gopf


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: [Property] backface-visibility [Values] visible | hidden [Initial] visible [Applies to] transformable elements [Inh.] no [Media] visual [Percentages]


Input: [Property] perspective [Values] none | [Initial] none [Applies to] transformable elements [Inh.] no [Media] visual [Percentages]


Input: [Property] perspective-origin [Values] [ | | left | center | right | top | bottom] | [ [ | | left | center | right ] && [ | | top | center | bottom ] ] [Initial] 50% 50% [Applies to] transformable elements [Inh.] no [Media] visual [Percentages]

Output: refer to the size of the element's bounding box


Input: [Property] transform [Values] none | [ ]* [Initial] none [Applies to] transformable elements [Inh.] no [Media] visual [Percentages]

Output: refer to the size of the element's bounding box


Input: [Property] transform-origin [Values] [ | | left | center | right | top | bottom] | [ [ | | left | center | right ] && [ | | top | center | bottom ] ] ? [Initial] 0 0 for SVG elements without associated CSS layout box, 50% 50% for all other elements [Applies to] transformable elements [Inh.] no [Media] visual [Percentages]

Output: refer to the size of the element's bounding box


Input: [Property] transform-style [Values] flat | preserve-3d [Initial] flat [Applies to] transformable elements [Inh.] no [Media] visual [Percentages]


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

Output: URL

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: URL

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: URL

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Language

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Date

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Date

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Person or Organization

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


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

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] isEntryOf [Description] Indicates the database to which the entry belongs. [Expected Type]

Output: BiologicalDatabase

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] taxon [Description] The taxonomy information of the entry. [Expected Type]

Output: BiologicalDatabaseEntry or Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] seeAlso [Description] Reference to another resource. [Expected Type]

Output: BiologicalDatabaseEntry or URL

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Property] reference [Description] The identifier of the reference, such as PMID, DOI, and PMCID. For example: . [Expected Type]

Output: Text

Difference between revisions of "WebSchemas/BioDatabases" - W3C Wiki


Input: [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent begins fetching the media data, synchronously during the load() method call. [Preconditions] networkState equals LOADING [Event name]

Output: loadstart


Input: [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is fetching media data. [Preconditions] networkState is more than EMPTY and less than LOADED [Event name]

Output: progress


Input: [Interface] Event [Dispatched when...] The user agent is fetching media data, and the media resource's metadata has just been received. [Preconditions] networkState equals LOADED_METADATA [Event name]

Output: loadedmetadata


Input: [Interface] Event [Dispatched when...] The user agent is fetching media data, and the media resource's first frame has just been received. [Preconditions] networkState equals LOADED_FIRST_FRAME [Event name]

Output: loadedfirstframe


Input: [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent finishes downloading the entire media resource. [Preconditions] networkState equals LOADED [Event name]

Output: load


Input: [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent stops fetching the media data before it is completely downloaded. This can be fired synchronously during the load() method call. [Preconditions] error is an object with the code MEDIA_ERR_ABORTED. networkState equals either EMPTY or LOADED, depending on when the download was aborted. [Event name]

Output: abort


Input: [Interface] ProgressEvent [PROGRESS] [Dispatched when...] An error occurs while fetching the media data. [Preconditions] error is an object with the code MEDIA_ERR_NETWORK_ERROR or higher. networkState equals either EMPTY or LOADED, depending on when the download was aborted. [Event name]

Output: error


Input: [Interface] Event [Dispatched when...] A media element whose networkState was previously not in the EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was reinvoked, in which case it is fired synchronously during the load() method call). [Preconditions] networkState is EMPTY; all the DOM attributes are in their initial states. [Event name]

Output: emptied


Input: [Interface] ProgressEvent [Dispatched when...] The user agent is trying to fetch media data, but data is unexpectedly not forthcoming. [Event name]

Output: stalled


Input: [Interface] Event [Dispatched when...] Playback has begun. Fired after the play method has returned. [Preconditions] paused is newly false. [Event name]

Output: play


Input: [Interface] Event [Dispatched when...] Playback has been paused. Fired after the pause method has returned. [Preconditions] paused is newly true. [Event name]

Output: pause


Input: [Interface] Event [Dispatched when...] Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. [Preconditions] readyState is either DATA_UNAVAILABLE or CAN_SHOW_CURRENT_FRAME, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors. [Event name]

Output: waiting


Input: [Interface] Event [Dispatched when...] The seeking DOM attribute changed to true and the seek operation is taking long enough that the user agent has time to fire the event. [Event name]

Output: seeking


Input: [Interface] Event [Dispatched when...] The seeking DOM attribute changed to false. [Event name]

Output: seeked


Input: [Interface] Event [Dispatched when...] The current playback position changed in an interesting way, for example discontinuously. [Event name]

Output: timeupdate


Input: [Interface] Event [Dispatched when...] Playback has stopped because the end of the media resource was reached. [Preconditions] currentTime equals the effective end; ended is true. [Event name]

Output: ended


Input: [Interface] Event [Dispatched when...] The user agent cannot render the data at the current playback position because data for the current frame is not immediately available. [Preconditions] The readyState attribute is newly equal to DATA_UNAVAILABLE. [Event name]

Output: dataunavailable


Input: [Interface] Event [Dispatched when...] The user agent cannot render the data after the current playback position because data for the next frame is not immediately available. [Preconditions] The readyState attribute is newly equal to CAN_SHOW_CURRENT_FRAME. [Event name]

Output: canshowcurrentframe


Input: [Interface] Event [Dispatched when...] The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. [Preconditions] The readyState attribute is newly equal to CAN_PLAY. [Event name]

Output: canplay