Input: [Part] 5 [Document] RDF-Based Semantics defines the meaning of OWL 2 ontologies via an extension of the RDF Semantics. [Type]

Output: Core Specification


Input: [Part] 6 [Document] Conformance provides requirements for OWL 2 tools and a set of test cases to help determine conformance. [Type]

Output: Core Specification


Input: [Part] 7 [Document] Profiles defines three sub-languages of OWL 2 that offer important advantages in particular applications scenarios. [Type]

Output: Specification


Input: [Part] 8 [Document] OWL 2 Primer provides an approachable introduction to OWL 2, including orientation for those coming from other disciplines. [Type]

Output: For Users


Input: [Part] 9 [Document] OWL 2 New Features and Rationale provides an overview of the main new features of OWL 2 and motivates their inclusion in the language. [Type]

Output: For Users


Input: [Part] 10 [Document] OWL 2 Quick Reference Guide provides a brief guide to the constructs of OWL 2, noting the changes from OWL 1. [Type]

Output: For Users


Input: [Part] 11 [Document] XML Serialization defines an XML syntax for exchanging OWL 2 ontologies, suitable for use with XML tools like schema-based editors and XQuery/XPath. [Type]

Output: Specification


Input: [Part] 12 [Document] Manchester Syntax (WG Note) defines an easy-to-read, but less formal, syntax for OWL 2 that is used in some OWL 2 user interface tools and is also used in the Primer. [Type]

Output: Specification


Input: [Part] 13 [Document] Data Range Extension: Linear Equations (WG Note) specifies an optional extension to OWL 2 which supports advanced constraints on the values of properties. [Type]

Output: Specification


Input: [Notation] {$ rule text $} [Interpretation]

Output: Emit the rule text substituting any occurrence of variables from the binding map. The outer {$ $} can be omitted in cases where there is no ambiguity.

Difference between revisions of "OWLRL" - RIF


Input: [Notation] for(?elt in ?list) { template } [Interpretation]

Output: ?list is a variable in the pattern which is bound to an RDF List. The for operator iterates over each element of the ?list in turn replacing the binding map for the ?elt variable with the next list entry and processes the enclosed template in the context of that new binding map.

Difference between revisions of "OWLRL" - RIF


Input: [Notation] for(?elt in ?list, != ?other) { template } [Interpretation]

Output: ?list is a variable in the pattern which is bound to an RDF List. The for operator iterates over each element of the ?list in turn, skipping any element identical to ?other, replacing the binding map for the ?elt variable with the next list entry and processes the enclosed template in the context of that new binding map.

Difference between revisions of "OWLRL" - RIF


Input: [Notation] $length(?list)$ [Interpretation]

Output: Used within a template this will be replaced by the length the RDFList bound to ?list.

Difference between revisions of "OWLRL" - RIF


Input: [Notation] $i$ [Interpretation]

Output: Used within a for(?elt in ?list){ template } this will be replaced by the index of the current ?elt.

Difference between revisions of "OWLRL" - RIF


Input: [Notation] $i+1$ [Interpretation]

Output: Used within a for(?elt in ?list){ template } this will be replaced by the index of the current ?elt, plus 1.

Difference between revisions of "OWLRL" - RIF


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

Output: acceptTracking

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.2.2: Terms for entity Action used with Duty


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

Output: attribute

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: compensate

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: delete

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: ensureExclusivity

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: include

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: inform

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: nextPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: obtainConsent

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: reviewPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: uninstall

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: watermark

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Erratum] E1 [Bugzilla] 4372 [Description] This erratum places constraints on the type of string that is valid for the doctype-public attribute of xsl:output. [Category]

Output: substantive


Input: [Erratum] E2 [Bugzilla] 4557 [Description] This erratum corrects an editorial error concerning the number of phases of serialization. [Category]

Output: editorial


Input: [Erratum] E3 [Bugzilla] 5066 [Description] This erratum corrects an editorial error concerning the currently registered XHTML media types. [Category]

Output: editorial


Input: [Erratum] E4 [Bugzilla] 5433 [Description] This erratum clarifies how descendant elements of an XML island must be serialized according to the HTML output method. [Category]

Output: substantive


Input: [Erratum] E5 [Bugzilla] 5439 [Description] This erratum aligns the description of the effect of the include-content-type serialization parameter of the HTML output method with that of the XHTML output method. [Category]

Output: substantive


Input: [Erratum] E6 [Bugzilla] 5458 [Description] This erratum ensures that the sequence normalization process preserves any type annotations associated with nodes in the input sequence. [Category]

Output: substantive


Input: [Erratum] E7 [Bugzilla] 5300 [Description] This erratum clarifies how elements with empty content models are to be serialized under the HTML and XHTML output methods. [Category]

Output: substantive


Input: [Erratum] E8 [Bugzilla] 5441 [Description] This erratum ensures that Unicode normalization applies to all characters that might be adjacent in the serialized result produced by the text output method, including those that are in text nodes that are separated by element nodes in the data model instance. [Category]

Output: substantive


Input: [Erratum] E9 [Bugzilla] 5993 [Description] This erratum makes previously non-normative text that describes how the xhtml and html output methods must behave if the indent parameter has the value yes into normative text. [Category]

Output: substantive


Input: [Erratum] E10 [Bugzilla] 6466 [Description] This erratum specifies the syntactic constraints on the values of the doctype-public and doctype-system serialization parameters. [Category]

Output: substantive


Input: [Erratum] E11 [Bugzilla] 6376 [Description] This erratum makes clear which parts of the recommendation are not considered to be normative. [Category]

Output: editorial


Input: [Property] namespace name [EXI event types]

Output: AT

Mapping of the attribute information item properties to EXI event types


Input: [Property] local name [EXI event types]

Output: AT


Input: [Property] prefix [EXI event types]

Output: AT


Input: [Property] normalized value [EXI event types]

Output: The value of AT


Input: [Property] specified [EXI event types]

Output: True if the item maps to AT, otherwise false


Input: [Property] attribute type [EXI event types]

Output: Computed based on AT and DT


Input: [Property] references [EXI event types]

Output: Computed based on attribute type and value of AT


Input: [Property] owner element [EXI event types]

Output: Computed based on the last SE event encountered that did not get a matching EE event


Input: [BASE] SELECT [PREFIX] CONSTRUCT [3] ASK [2]

Output: DESCRIBE


Input: [BASE] ORDER BY [PREFIX] LIMIT [3] DISTINCT [4] REDUCED [2]

Output: OFFSET


Input: [BASE] FROM [PREFIX] FROM NAMED [2]

Output: WHERE


Input: [BASE] GRAPH [PREFIX] OPTIONAL [3] FILTER [4] a [2]

Output: UNION


Input: [BASE] STR [PREFIX] LANG [3] DATATYPE [4] BOUND [5] sameTERM [2]

Output: LANGMATCHES


Input: [BASE] isURI [PREFIX] isIRI [3] REGEX [4] true [5] false [2]

Output: isLITERAL


Input: [0] Value [1] Description [2] Example [3] Scope [4]

Output: Notes

Internationalization Tag Set (ITS) Version 2.0


Input: [0] terminology [1] An incorrect term or a term from the wrong domain was used or terms are used inconsistently. [2] The localization had â€œPen Driveâ€ when corporate terminology specified that â€œUSB Stickâ€ was to be used. The localization text inconsistently used "Start" and "Begin". A text renders the Hungarian term recsegÅ‘Ã©k as â€œbuzzer bridgeâ€ in English to translate (a literal translation), but the term used in English should be â€œwedge block,â€ as specified in a terminology list supplied to the translator. [3] S or T [4]

Output: This value MUST NOT be used for simple typographical errors or word choice not related to defined terminologies. For example, a mistyping of â€œpinâ€ as â€œpenâ€ or the use of â€œimplyâ€ instead of â€œinferâ€ (mistaking two commonly confused words) would not count as terminology issues and should be categorized as either spelling errors or mistranslations, depending on the nature of the issue. Terminology refers only to cases where incorrect choices about terms (either formal or commonly defined in a domain) are involved.

Internationalization Tag Set (ITS) Version 2.0


Input: [0] mistranslation [1] The content of the target mistranslates the content of the source. [2] The English source reads "An ape succeeded in grasping a banana lying outside its cage with the help of a stick" but the Italian translation reads "l'ape riuscÃ¬ a prendere la banana posta tuori dall sua gabbia aiutandosi con un bastone" ("A bee succeeded...") [3] T [4]

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

Internationalization Tag Set (ITS) Version 2.0


Input: [0] omission [1] Necessary text has been omitted from the localization or source. [2] One or more segments found in the source that should have been translated are missing in the target. [3] S or T [4]

Output: This type should not be used for missing whitespace or formatting codes, but instead should be reserved for linguistic content.

Internationalization Tag Set (ITS) Version 2.0


Input: [0] untranslated [1] Content that should have been translated was left untranslated. [2] The source segment reads "The Professor said to Smith that he would hear from his lawyer" but the Hungarian localization reads "A professzor azt modta Smithnek, hogy he would hear from his lawyer." [3] T [4]

Output: omission takes precedence over untranslated . Omissions are distinct in that they address cases where text is not present, while untranslated addresses cases where text has been carried from the source untranslated.

Internationalization Tag Set (ITS) Version 2.0


Input: [0] locale-specific-content [1] The localization contains content that does not apply to the locale for which it was prepared. [2] A text translated for the Japanese market contains call center numbers in Texas and refers to special offers available only in the U.S. [3] S or T [4]

Output: Legally inappropriate material should be classified as legal .

Internationalization Tag Set (ITS) Version 2.0


Input: [0] locale-violation [1] Text violates norms for the intended locale. [2] A text localized into German has dates in YYYY-MM-DD format instead of in DD.MM.YYYY. A text for the Irish market uses American-style foot and inch measurements instead of centimeters. A text intended for a U.S.-based audience uses U.K. spellings such as â€œcentreâ€ and â€œcolour.â€ [3] S or T [4]

Output: This category should be used for spelling errors only if they relate specifically to locale expectations (e.g., a text consitently uses British instead of U.S. spellings for a text intended for the U.S.). If these errors are not systematic (e.g., a text uses U.S. spellings but has a single instance of â€œcentreâ€), they should instead be counted as spelling errors.

Internationalization Tag Set (ITS) Version 2.0


Input: [0] numbers [1] Numbers are inconsistent between source and target. [2] A source text states that an object is 120 cm long, but the target text says it is 129 cm. long. [3] S or T [4]

Output: Some tools may correct for differences in units of measurement to reduce false positives.

Internationalization Tag Set (ITS) Version 2.0


Input: [0] internationalization [1] There is an issue related to the internationalization of content. [2] A line of programming code has embedded language-specific strings. A user interface element leaves no room for text expansion. A form allows only for U.S.-style postal addresses and expects five digit U.S. ZIP codes. [3] S or T [4]

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

Internationalization Tag Set (ITS) Version 2.0


Input: [0] length [1] There is a significant difference in source and target length. [2] The translation of a segment is five times as long as the source. [3] T or S [4]

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

Internationalization Tag Set (ITS) Version 2.0


Input: [0] uncategorized [1] The issue has not been categorized. [2] A new version of a tool returns information on an issue that has not been previously checked and that is not yet classified. [3] S or T [4]

Output: This category has two uses: A tool can use it to pass through quality data from another tool in cases where the issues from the other tool are not classified (for example, a localization quality assurance tool interfaces with a third-party grammar checker). A tool's issues are not yet assigned to categories, and, until an updated assignment is made, they may be listed as uncategorized . In this case it is recommended that issues be assigned to appropriate categories as soon as possible since uncategorized does not foster interoperability.

Internationalization Tag Set (ITS) Version 2.0


Input: [0] other [1] Any issue that cannot be assigned to any values listed above. [3] S or T [4]

Output: This category allows for the inclusion of any issues not included in the previously listed values. This value MUST NOT be used for any tool- or model-specific issues that can be mapped to the values listed above. In addition, this value is not synonymous with uncategorized in that uncategorized issues may be assigned to another precise value, while other issues cannot. If a system has an "miscellaneous" or "other" category, it MUST be mapped to this value even if the specific instance of the issue might be mapped to another category.

Internationalization Tag Set (ITS) Version 2.0


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

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

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


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

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [1] Description [2] Example [3] Scope [4] Notes [0]

Output: Value

Internationalization Tag Set (ITS) Version 2.0


Input: [1] An incorrect term or a term from the wrong domain was used or terms are used inconsistently. [2] The localization had â€œPen Driveâ€ when corporate terminology specified that â€œUSB Stickâ€ was to be used. The localization text inconsistently used "Start" and "Begin". A text renders the Hungarian term recsegÅ‘Ã©k as â€œbuzzer bridgeâ€ in English to translate (a literal translation), but the term used in English should be â€œwedge block,â€ as specified in a terminology list supplied to the translator. [3] S or T [4] This value MUST NOT be used for simple typographical errors or word choice not related to defined terminologies. For example, a mistyping of â€œpinâ€ as â€œpenâ€ or the use of â€œimplyâ€ instead of â€œinferâ€ (mistaking two commonly confused words) would not count as terminology issues and should be categorized as either spelling errors or mistranslations, depending on the nature of the issue. Terminology refers only to cases where incorrect choices about terms (either formal or commonly defined in a domain) are involved. [0]

Output: terminology

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The content of the target mistranslates the content of the source. [2] The English source reads "An ape succeeded in grasping a banana lying outside its cage with the help of a stick" but the Italian translation reads "l'ape riuscÃ¬ a prendere la banana posta tuori dall sua gabbia aiutandosi con un bastone" ("A bee succeeded...") [3] T [4] Issues related to translation of specific terms related to the domain or task-specific language should be categorized as terminology issues. [0]

Output: mistranslation

Internationalization Tag Set (ITS) Version 2.0


Input: [1] Necessary text has been omitted from the localization or source. [2] One or more segments found in the source that should have been translated are missing in the target. [3] S or T [4] This type should not be used for missing whitespace or formatting codes, but instead should be reserved for linguistic content. [0]

Output: omission

Internationalization Tag Set (ITS) Version 2.0


Input: [1] Content that should have been translated was left untranslated. [2] The source segment reads "The Professor said to Smith that he would hear from his lawyer" but the Hungarian localization reads "A professzor azt modta Smithnek, hogy he would hear from his lawyer." [3] T [4] omission takes precedence over untranslated . Omissions are distinct in that they address cases where text is not present, while untranslated addresses cases where text has been carried from the source untranslated. [0]

Output: untranslated

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The translated text contains inappropriate additions. [2] The translated text contains a note from the translator to himself to look up a term; the note should have been deleted but was not. [3] T [0]

Output: addition

Internationalization Tag Set (ITS) Version 2.0


Input: [1] Content has been duplicated improperly. [2] A section of the target text was inadvertently copied twice in a copy and paste operation. [3] T [0]

Output: duplication

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text is inconsistent with itself (NB: not for use with terminology inconsistency). [2] The text states that an event happened in 1912 in one location but in another states that it happened in 1812. [3] S or T [0]

Output: inconsistency

Internationalization Tag Set (ITS) Version 2.0


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

Output: grammar

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text is legally problematic (e.g., it is specific to the wrong legal system). [2] The localized text is intended for use in Thailand but includes U.S. regulatory notices. A text translated into German contains comparative advertising claims that are not allowed by German law. [3] S or T [0]

Output: legal

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text is written in the wrong linguistic register of uses slang or other language variants inappropriate to the text. [2] A financia financial text in U.S. English refers to dollars as "bucks". [3] S or T [0]

Output: register

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The localization contains content that does not apply to the locale for which it was prepared. [2] A text translated for the Japanese market contains call center numbers in Texas and refers to special offers available only in the U.S. [3] S or T [4] Legally inappropriate material should be classified as legal . [0]

Output: locale-specific-content

Internationalization Tag Set (ITS) Version 2.0


Input: [1] Text violates norms for the intended locale. [2] A text localized into German has dates in YYYY-MM-DD format instead of in DD.MM.YYYY. A text for the Irish market uses American-style foot and inch measurements instead of centimeters. A text intended for a U.S.-based audience uses U.K. spellings such as â€œcentreâ€ and â€œcolour.â€ [3] S or T [4] This category should be used for spelling errors only if they relate specifically to locale expectations (e.g., a text consitently uses British instead of U.S. spellings for a text intended for the U.S.). If these errors are not systematic (e.g., a text uses U.S. spellings but has a single instance of â€œcentreâ€), they should instead be counted as spelling errors. [0]

Output: locale-violation

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text contains stylistic errors. [2] Company style guidelines dictates that all individuals be referred to as Mr. or Ms. with a family name, but the text refers to â€œJack Smithâ€. [3] S or T [0]

Output: style

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears. [2] A text should have a 'â€¢' but instead has a 'Â¥' sign. A text translated into German omits the umlauts over 'Ã¼', 'Ã¶', and 'Ã¤'. [3] S or T [0]

Output: characters

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text contains a misspelling. [2] A German text misspells the word "Zustellung" as "ZustellÃ¼ng". [3] S or T [0]

Output: misspelling

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text has typographical errors such as omitted/incorrect punctuation, incorrect capitalization, etc. [2] An English text has the following sentence: "The man whom, we saw, was in the Military and carried it's insignias". [3] S or T [0]

Output: typographical

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text is formatted incorrectly. [2] Warnings in the text are supposed to be set in italic face, but instead appear in bold face. Margins of the text are narrower than specified. [3] S or T [0]

Output: formatting

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The source and target text contain different named entities (dates, times, place names, individual names, etc.) [2] The name "Thaddeus Cahill" appears in an English source but is rendered as "TamaÅ¡ Cahill" in the Czech version. The date "February 9, 2007" appears in the source but the translated text has "2. September 2007". [3] S or T [0]

Output: inconsistent-entities

Internationalization Tag Set (ITS) Version 2.0


Input: [1] Numbers are inconsistent between source and target. [2] A source text states that an object is 120 cm long, but the target text says it is 129 cm. long. [3] S or T [4] Some tools may correct for differences in units of measurement to reduce false positives. [0]

Output: numbers

Internationalization Tag Set (ITS) Version 2.0


Input: [1] There is an issue related to markup or a mismatch in markup between source and target. [2] The source segment has five markup tags but the target has only two. An opening tag in the text is missing a closing tag. [3] S or T [0]

Output: markup

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content). [2] The tool disallows the regular expression pattern ['"â€â€™][\.,] but the translated text contains "A leading â€œexpertâ€, a political hack, claimed otherwise." [3] S or T [0]

Output: pattern-problem

Internationalization Tag Set (ITS) Version 2.0


Input: [1] There is a mismatch in whitespace between source and target content. content or the text violates specific rules related to the use of whitespace.. [2] A source segment starts with six space characters but the corresponding target segment has two non-breaking spaces at the start. The text uses a run of 12 space characters instead of a tab character to align numbers in a table. Two space characters appear after a period even though only a single period should be used. [3] S or T [0]

Output: whitespace

Internationalization Tag Set (ITS) Version 2.0


Input: [1] There is an issue related to the internationalization of content. [2] A line of programming code has embedded language-specific strings. A user interface element leaves no room for text expansion. A form allows only for U.S.-style postal addresses and expects five digit U.S. ZIP codes. [3] S or T [4] There are many kinds of internationalization issues. This category is therefore very heterogeneous in what it can refer to. [0]

Output: internationalization

Internationalization Tag Set (ITS) Version 2.0


Input: [1] There is a significant difference in source and target length. [2] The translation of a segment is five times as long as the source. [3] T or S [4] What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef . [0]

Output: length

Internationalization Tag Set (ITS) Version 2.0


Input: [1] The issue has not been categorized. [2] A new version of a tool returns information on an issue that has not been previously checked and that is not yet classified. [3] S or T [4] This category has two uses: A tool can use it to pass through quality data from another tool in cases where the issues from the other tool are not classified (for example, a localization quality assurance tool interfaces with a third-party grammar checker). A tool's issues are not yet assigned to categories, and, until an updated assignment is made, they may be listed as uncategorized . In this case it is recommended that issues be assigned to appropriate categories as soon as possible since uncategorized does not foster interoperability. [0]

Output: uncategorized

Internationalization Tag Set (ITS) Version 2.0


Input: [1] Any issue that cannot be assigned to any values listed above. [3] S or T [4] This category allows for the inclusion of any issues not included in the previously listed values. This value MUST NOT be used for any tool- or model-specific issues that can be mapped to the values listed above. In addition, this value is not synonymous with uncategorized in that uncategorized issues may be assigned to another precise value, while other issues cannot. If a system has an "miscellaneous" or "other" category, it MUST be mapped to this value even if the specific instance of the issue might be mapped to another category. [0]

Output: other

Internationalization Tag Set (ITS) Version 2.0


Input: [ID] 57 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4 [Resolution] Resolution: Section rewritten. Rationale: Provides more guidance on how to evaluate content using WCAG 2.0 and its accompanying document. [Rationale]

Output: "some of the content of this step seems to me to be out of scope. WCAG-EM is about testing conformance to WCAG 2.0, that is, to determine whether a web site conforms to the technical requirements of WCAG 2.0, which are the 61 success criteria and the 5 conformance requirements. WCAG-EM should not deal with other types of accessibility evaluations, such as user testing or the concept of "accessibility-in-use" as defined in current research. So the first substep, as 4.a (check for use cases), seems to me out of scope." "What I expected as content of step 4 is guidance about: how to evaluate each success criterion for each element of a web page of the sample, including guidance about the best approach: inspection, testing by experts, testing by users... how to combine the results obtained for each element in order to get a result for the page, how to evaluate the 5 conformance requirements once the result of each SC is known for the page, how to combine the results obtained for each page to get the global result for the site (that then will be reported in step 5)."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 58 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4 [Current text] Note 1 [Suggested Change] Proposal for that second sentence: "An evaluator does not need to repeatedly identify successes and failures in meeting the conformance target for these repetitive elements on every web page. The success and failures for such repetitive elements can be identified once and then be reused in all the pages those elements appear." [Resolution] Resolution: Edited. Rationale: The note has been edited and worked into the main text. [Rationale]

Output: "The first note is confusing. If there are repetitive elements on every web page it makes sense to evaluate them only once, and then record and reuse the evaluation results. It is clear that an evaluator should not valuate several times the same repetitive elements but it is also important to note that the result assigned after the first evaluation has to be used when evaluating each page where the repetitive elements appear! My understanding of the second sentence of this note is that it implies that the repetitive elements are only evaluated once and their result is only used once... I'm probably misreading it, but I think that the text would benefit from some rewrite. In addition I don't see the point of referring back to step 1.b in this note. What would be the difference on dealing with repetitive elements depending of the type of expected report?"

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 59 [Status] Closed [Commenter] Giorgio Brajnik [Location] Step 4 [Suggested Change] Is this "in reality what [..] people do?" [Resolution] Resolution: No change. Rationale: Representatives from both mentioned organizations (and more) are actively involved in the development of this methodology. This edior note was to gather additional input. [Rationale]

Output: Question: "in reality what do people do? For example the Germans that follow the BITV, what methodology do they employ? Or the Knowbility.org people that run the accessibility rallies? Is this methodology connected to those? Because there’s no bibliography in this document I think it is not. And it should not be such."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 60 [Status] Closed [Commenter] Denis Boudreau [Location] Step 4 [Current text] Note 1 [Suggested Change] "We should suggest isolating template findings from the rest of the findings related to main content of a page or pages, so findings/issues related to templates can be referenced globally for all related pages, rather than repeating the findings every time." [Resolution] Resolution: Note removed. Rationale: Templates are addressed in the exploration and sampling steps instead, to make sure that templates that are actively used are being evaluated (rather than templates in absence of content). [Rationale]

Output: "By doing this, once the template findings are covered, all subsequent pages could only be covering the main content issues, making the whole process simpler and more organized."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 61 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4 [Current text] Note 2 [Suggested Change] Proposal: "According to WCAG 2.0, Success Criteria to which there is no matching content are satisfied. In such cases, an evaluator may use text such as "Not applicable" as a description associated to the outcome "satisfied", to denote the particular situation where a success criterion was satisfied because no relevant content was applicable." [Resolution] Resolution: Edited. Rationale: Text edited to make clearer. [Rationale]

Output: "I think that the wording of this note is confusing. It should clearly explain that, according to WCAG 2.0, "no matching content for SC" is really "SC is satisfied" with no question. It should also explain that the "not applicable" could be used as a "description" of the result but not as a result.

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 62 [Status] Closed [Commenter] Peter Korn [Location] Step 4 [Resolution] Resolution: No change. Rationale: The proper assessment of Success Criteria is assumed to be part of the skills of an evaluator. [Rationale]

Output: "There was little direction related to web applications related to any documentation that may have been provided with the web application, or published by the company selling the web app. For example, the Oracle whitepaper Testing Oracle Products for Accessibility , mentions many things related to the accessibility of web applications, including: making sure to read documentation to understand how the product is meant to be used, such as keystrokes documentation that might point out workarounds, including alternative paths through a website enablement of applicable accessibility modes, if any if using AT, ensuring that a defect found is not in the AT itself, and that the user is proficient if using automated test tools, ensuring that it is accurately representing the SC and sufficient/failure techniques that it claims to meet"

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 64 [Status] Closed [Commenter] Neil King [Location] Step 4a [Suggested Change] "It is strongly recommended to also involve real users during this process.... Whilst we completely agree with this and conduct 'technical' testing with end users during WCAG evaluations, it is no substitute for formal usability testing. 'Practical' accessibility issues are just as important as 'technical' accessibility issues but may be disregarded when assessed in the context of a technical evaluation as they do not always directly map to WCAG 2.0." [Resolution] Resolution: Section rewritten. Rationale: Provides more guidance on how to evaluate content using WCAG 2.0 and its accompanying document. [Rationale]

Output: "We all interact with websites using different browsers, different ATs and different approaches. Determining the true nature of an accessibility issue when involving users is not as straightforward as merely asking them what they believe is the issue, or reporting on general observations as with mainstream users. To undertake comprehensive formal usability testing for accessibility we believe there is a real requirement to understand user experience, technical accessibility and how ATs are used and their capabilities; it is rare you find people with all of these skills and experience."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 65 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4a [Suggested Change] Change the title in: "Step 4.a: Check the conformance requirements". [Resolution] Resolution: Section rewritten. Rationale: Provides more guidance on how to evaluate content using WCAG 2.0 and its accompanying document. [Rationale]

Output: "The title of misleading, because the requirement 4.a is about checking the conformance requirements, not about use cases."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 66 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4a [Suggested Change] "I would like to have guidance outlining a process such as: a) Look for failures (as published) b) If no failures are found, check if any SC fails c) If no SC fails and a "in-depth analysis" has been selected in step 1.b, then determines which techniques have been used to conform to each SC" [Resolution] Resolution: Section rewritten. Rationale: Provides more guidance on how to evaluate content using WCAG 2.0 and its accompanying document. [Rationale]

Output: "I find that this step has gaps in the content I expected it to have. In my opinion checking for the 5 conformance requirements is not a straightforward task and more guidance is needed." " My proposed process is based on the definition of "satisfies a SC" in WCAG: "the success criterion does not evaluate to 'false'", Given that definition, it is not really needed to find/determine the techniques. It should be enough to be sure that no SC fails." "All the text about scenarios, use cases, personas and user involvement is, to me, out of scope when dealing about testing for conformance with a standard. These type of things are essential during the development process when following a user-centred approach, but I believe that they don't provide added value in the context of checking the conformance of WCAG 2.0. If this text about scenarios and users is to be kept, I'd suggest it being transformed into a note."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 67 [Status] Closed [Commenter] Peter Korn [Location] Step 4a [Resolution] Resolution: Section rewritten. Rationale: Provides more guidance on how to evaluate content using WCAG 2.0 and its accompanying document. [Rationale]

Output: "The second paragraph, starting with the text "To carry out an evaluation effectively, it is often useful to construct and apply personas..." over-emphasizes a specific approach, particularly with language like the second sentence "It is critical to consider...". It should be possible to evaluate against WCAG 2.0 on a purely technical, objective basis. As such, this material could be presented as an advisory statement. As written now it goes beyond the scope of WCAG 2.0 conformance."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 68 [Status] Closed [Commenter] Giorgio Brajnik [Location] Step 4a [Suggested Change] Place this step first [Resolution] Resolution: Section rewritten. Rationale: Provides more guidance on how to evaluate content using WCAG 2.0 and its accompanying document. [Rationale]

Output: "If one enumerates the use cases then the sample of pages may change, as per “complete process” requirement. Hence this step should come first."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 69 [Status] Closed [Commenter] Neil King [Location] Step 4b [Suggested Change] Add: "The Working Group, therefore, limited itself to defining what constituted support and defers the judgment of how much, how many, or which AT must support a technology to the community and to entities closer to each situation that set requirements for an organization, purchase, community, etc. (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-support-level-head)". [Resolution] Resolution: Section removed; edits worked into Step 4.a and 1.c. Rationale: More guidance on determining a baseline for accessibility support. [Rationale]

Output: "As there is no definitive list to define what technologies or particular AT is classified as 'Accessibility Supported' it is not always easy to establish this without the subjectivity between website owners coming into play."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 70 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4b [Suggested Change] "This should be linked to step 2.d (identify web technologies relied upon)" [Resolution] Resolution: Section removed; edits worked into Step 4.a and 1.c. Rationale: Edits have been made though emphasis remained that accessibility support is determined by feature rather than by technology. [Rationale]

Output: "The first "cut" for features that have accessibility support is to look for the ones using technologies identified"

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 71 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4b [Resolution] Resolution: Section removed; edits worked into Step 4.a and 1.c. Rationale: More guidance on determining a baseline for accessibility support. [Rationale]

Output: "According to my comment for step 4.a, I think this could be optional as it is only needed when the evaluation report will contain detailed information about how each SC is met (see my outlined process, step c)."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 72 [Status] Closed [Commenter] Neil King [Location] Step 4c [Resolution] Resolution: Section removed; edits worked into Step 4.a and 1.c. Rationale: More guidance on the use of techniques in the context of WCAG 2.0; enforcing the use of (informative) techniques is an additional requirement to WCAG 2.0 and is beyond the scope of this methodology. [Rationale]

Output: "In an Australian Government context this is not optional."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 73 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4c [Suggested Change] "I propose dividing this into two: 4.c.1 Use failures (mandatory) and 4.c.2 Use techniques (optional). (If this is accepted then the text of these two steps should be rewritten to fit the new structure.)" [Resolution] Resolution: Section removed; edits worked into Step 4.a and 1.c. Rationale: More guidance on the use of techniques in the context of WCAG 2.0. [Rationale]

Output: "I agree that the use of techniques is optional, but I fundamentally disagree in the use of failures. Even if failures are part of an informative document it is 100% sure that if one of those failures is found, then the corresponding SC fails for the page being evaluated. I cannot imagine any exception to that idea. As I already explained above, given the definition of "satisfying a SC", the concept of "failures" is an essential tool for evaluators and should not be optional"

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 74 [Status] Closed [Commenter] Peter Korn [Location] Step 4c [Resolution] Resolution: Section removed; edits worked into Step 4.a and 1.c. Rationale: More guidance on the use of techniques in the context of WCAG 2.0; WCAG WG provided updated guidance that is referenced from the respective sections. [Rationale]

Output: "This section appropriately describes the proper use of techniques (that they are informative and not mandatory). However, the document would be improved if this were particularly emphasized. We are seeing entities that are requiring the use of WCAG 2.0 also requiring the use of these techniques as THE way of demonstrating compliance."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 75 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4d [Suggested Change] This step needs some clarification. [Resolution] Resolution: Section removed; edits worked into Step 5.b. Rationale: More guidance on recording the evaluation specifics (optional) as opposed to documenting the evaluation outcomes (required). [Rationale]

Output: "I think that it would be good to have an explanation of the reasons to make this step optional. My first idea when reading the title of the step was to ask for it to be mandatory, as I thought that any evaluator should really archive the pages being evaluated (at least the URI and data required to be able to re-evaluate the page if needed). But then I read the details of this step and I tend to agree that all this information is optional. This is why I think that some clarification is needed."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [ID] 76 [Status] Closed [Commenter] Loïc Martínez Normand [Location] Step 4e [Suggested Change] This step should not be optional. [Resolution] Resolution: Section removed; edits worked into Step 5.b. Rationale: More guidance on recording the evaluation specifics (optional) as opposed to documenting the evaluation outcomes (required). [Rationale]

Output: "I think that this step should not be optional. I agree that it is not always necessary to report on this information but evaluators should always record the information so it can be accessed if needed."

Disposition of Comments - WCAG-EM Working Draft 21 may 2013


Input: [Part] 1 [Type] For Users [Document]

Output: Document Overview. A quick overview of the OWL 2 specification that includes a description of its relationship to OWL 1. This it the starting point and primary reference point for OWL 2.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 2 [Type] Core Specification [Document]

Output: Structural Specification and Functional-Style Syntax defines the constructs of OWL 2 ontologies in terms of both their structure and a functional-style syntax, and defines OWL 2 DL ontologies in terms of global restrictions on OWL 2 ontologies.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 3 [Type] Core Specification [Document]

Output: Mapping to RDF Graphs defines a mapping of the OWL 2 constructs into RDF graphs, and thus defines the primary means of exchanging OWL 2 ontologies in the Semantic Web.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 4 [Type] Core Specification [Document]

Output: Direct Semantics defines the meaning of OWL 2 ontologies in terms of a model-theoretic semantics.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 5 [Type] Core Specification [Document]

Output: RDF-Based Semantics defines the meaning of OWL 2 ontologies via an extension of the RDF Semantics.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 6 [Type] Core Specification [Document]

Output: Conformance provides requirements for OWL 2 tools and a set of test cases to help determine conformance.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 7 [Type] Specification [Document]

Output: Profiles defines three sub-languages of OWL 2 that offer important advantages in particular applications scenarios.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 8 [Type] For Users [Document]

Output: OWL 2 Primer provides an approachable introduction to OWL 2, including orientation for those coming from other disciplines.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 9 [Type] For Users [Document]

Output: OWL 2 New Features and Rationale provides an overview of the main new features of OWL 2 and motivates their inclusion in the language.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 10 [Type] For Users [Document]

Output: OWL 2 Quick Reference Guide provides a brief guide to the constructs of OWL 2, noting the changes from OWL 1.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 11 [Type] Specification [Document]

Output: XML Serialization defines an XML syntax for exchanging OWL 2 ontologies, suitable for use with XML tools like schema-based editors and XQuery/XPath.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 12 [Type] Specification [Document]

Output: Manchester Syntax (WG Note) defines an easy-to-read, but less formal, syntax for OWL 2 that is used in some OWL 2 user interface tools and is also used in the Primer.

OWL 2 Web Ontology Language Document Overview


Input: [Part] 13 [Type] Specification [Document]

Output: Data Range Extension: Linear Equations (WG Note) specifies an optional extension to OWL 2 which supports advanced constraints on the values of properties.

OWL 2 Web Ontology Language Document Overview


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.

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

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

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

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

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

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

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.

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

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

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

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'

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

System Applications WG: Security Model - W3C Wiki


Input: [1] Response Header [2] Well-known URI [3] Notes [0]

Output: Criteria


Input: [1] ++ [2] +(may need dynamic generation) [3] MSchunter believes that sending individualised (per user) status is easier with headers since they can be locally generated and attached. This seems easier than dynamically generating a centralised resource at a well-known URI. [0]

Output: Transmits tracking status for retrieved object at URL


Input: [1] ++ [2] + [3] Headers are slightly less ambiguous due to their narrow scope [0]

Output: Enables enforcement by regulators


Input: [1] ++ (per request; very fine-grained) [2] + (per sub-site; coarser-grained) [3] To support DNT for each URL, the site needs to be replicated under the well-known URL. [0]

Output: Granularity


Input: [1] ++ (info along with page) [2] 0 (separate lookup) [0]

Output: Simplicity of user agent


Input: [1] ++ (info along with page) [2] 0 (separate lookup) [3] It seems as -worst case-, the URI proposal may generate 2x the number of requests? [0]

Output: Traffic generated


Input: [1] - [2] ++ [3] Some cache implementations do not properly handle headers while all caches can cache a well-known URL. [0]

Output: Robustness wrt caching


Input: [1] + [2] - [3] URI can be declared 'no tracking area' and retrieved before actual request. For headers, tracking may have happened while returning a header? [0]

Output: Tracking protection on info resource


Input: [1] + [2] - [3] URI requires all site stakeholders to agree and populate the well-known URI (difficult); header allows resource-owner to just attach a header [0]

Output: Maintainability of site


Input: [1] - [2] + [3] Status object can transmit larger data sets (partner-sites, options, ...) while this would overload header. [0]

Output: Ability to transmit complex data


Output: [More criteria needed...]


Input: [Member name] Compaq [Patent declaration] None declared [License Summary] Royalty-Free [License statement] http://lists.w3.org/Archives/Member/patent-issues/1999JanMar/0005.html [good standing]

Output: no

Summary of SMIL 2.0 Patent Statements from SYMM WG members


Input: [Member name] CSELT [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/1999JanMar/0000.html [good standing]

Output: no


Input: [Member name] CWI [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/1999JanMar/0003.html [good standing]

Output: yes


Input: [Member name] GLOCOM [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/1999AprJun/0000.html [good standing]

Output: no


Input: [Member name] IBM [Patent declaration] Possible Patent declared [License Summary] RAND [License statement] http://lists.w3.org/Archives/Member/patent-issues/2001AprJun/0023.html [good standing]

Output: yes


Input: [Member name] INRIA [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/1999JanMar/0004.html [good standing]

Output: yes


Input: [Member name] Intel [Patent declaration] None declared [License Summary] Royalty-Free [License statement] http://lists.w3.org/Archives/Member/patent-issues/2001JanMar/0040.html [good standing]

Output: yes


Input: [Member name] Macromedia [Patent declaration] Possible Patent declared [License Summary] Royalty-Free [License statement] http://lists.w3.org/Archives/Member/patent-issues/2001AprJun/0025.html [good standing]

Output: yes


Input: [Member name] Microsoft [Patent declaration] None declared [License Summary] Royalty-Free [License statement] http://lists.w3.org/Archives/Member/patent-issues/2001AprJun/0024.html [good standing]

Output: yes


Input: [Member name] Netscape/AOL [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/2000AprJun/0000.html [good standing]

Output: no


Input: [Member name] Nokia [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/1999JulSep/0000.html [good standing]

Output: no


Input: [Member name] Oratrix [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/2001AprJun/0000.html [good standing]

Output: yes


Input: [Member name] Panasonic (Matsushita) [Patent declaration] None declared [License Summary] Royalty-Free [License statement] http://lists.w3.org/Archives/Member/patent-issues/2001AprJun/0015.html [good standing]

Output: yes


Input: [Member name] Web3D Consortium [Patent declaration] None declared [License Summary] No licence [License statement] http://lists.w3.org/Archives/Team/symm-review/2000JanMar/0001.html [good standing]

Output: no


Input: [Member name] Philips [Patent declaration] None declared [License Summary] RAND [License statement] http://lists.w3.org/Archives/Member/symm/2000Dec/0115.html [good standing]

Output: yes


Input: [Member name] RealNetworks [Patent declaration] None declared [License Summary] Royalty-Free [License statement] http://lists.w3.org/Archives/Member/patent-issues/2001JanMar/0029.html [good standing]

Output: yes


Input: [Member name] WGBH * [Patent declaration] None declared [License Summary] No licence [good standing]

Output: yes


Input: [Definition] Character data [Attribute Type]

Output: CDATA


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

Output: ID


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

Output: IDREF


Input: [Definition] A space-separated list of references to document-unique identifiers [Attribute Type]

Output: IDREFS


Input: [Definition] A name with the same character constraints as ID above [Attribute Type]

Output: NAME


Input: [Definition] A name composed of only name tokens as defined in XML 1.0 [XML]. [Attribute Type]

Output: NMTOKEN


Input: [Definition] One or more white space separated NMTOKEN values [Attribute Type]

Output: NMTOKENS


Input: [Definition] Processed character data [Attribute Type]

Output: PCDATA


Input: [0] Criteria [1] Response Header [2] Well-known URI [3]

Output: Notes


Input: [0] Transmits tracking status for retrieved object at URL [1] ++ [2] +(may need dynamic generation) [3]

Output: MSchunter believes that sending individualised (per user) status is easier with headers since they can be locally generated and attached. This seems easier than dynamically generating a centralised resource at a well-known URI.


Input: [0] Enables enforcement by regulators [1] ++ [2] + [3]

Output: Headers are slightly less ambiguous due to their narrow scope


Input: [0] Granularity [1] ++ (per request; very fine-grained) [2] + (per sub-site; coarser-grained) [3]

Output: To support DNT for each URL, the site needs to be replicated under the well-known URL.


Input: [0] Traffic generated [1] ++ (info along with page) [2] 0 (separate lookup) [3]

Output: It seems as -worst case-, the URI proposal may generate 2x the number of requests?


Input: [0] Robustness wrt caching [1] - [2] ++ [3]

Output: Some cache implementations do not properly handle headers while all caches can cache a well-known URL.


Input: [0] Tracking protection on info resource [1] + [2] - [3]

Output: URI can be declared 'no tracking area' and retrieved before actual request. For headers, tracking may have happened while returning a header?


Input: [0] Maintainability of site [1] + [2] - [3]

Output: URI requires all site stakeholders to agree and populate the well-known URI (difficult); header allows resource-owner to just attach a header


Input: [0] Ability to transmit complex data [1] - [2] + [3]

Output: Status object can transmit larger data sets (partner-sites, options, ...) while this would overload header.


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

Output: networkState equals LOADING


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is fetching media data . [Preconditions]

Output: networkState is more than EMPTY and less than LOADED


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

Output: networkState equals LOADED_METADATA


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

Output: networkState equals LOADED_FIRST_FRAME


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

Output: networkState equals LOADED


Input: [Event name] abort [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]

Output: error is an object with the code MEDIA_ERR_ABORTED . networkState equals either EMPTY or LOADED , depending on when the download was aborted.


Input: [Event name] error [Interface] ProgressEvent [PROGRESS] [Dispatched when...] An error occurs while fetching the media data . [Preconditions]

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


Input: [Event name] emptied [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]

Output: networkState is EMPTY ; all the DOM attributes are in their initial states.


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

Output: paused is newly false.


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

Output: paused is newly true.


Input: [Event name] waiting [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]

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


Input: [Event name] ended [Interface] Event [Dispatched when...] Playback has stopped because the end of the media resource was reached. [Preconditions]

Output: currentTime equals the effective end ; ended is true.


Input: [Event name] dataunavailable [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]

Output: The readyState attribute is newly equal to DATA_UNAVAILABLE .


Input: [Event name] canshowcurrentframe [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]

Output: The readyState attribute is newly equal to CAN_SHOW_CURRENT_FRAME .


Input: [Event name] canplay [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]

Output: The readyState attribute is newly equal to CAN_PLAY .


Input: [Event name] canplaythrough [Interface] Event [Dispatched when...] 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. [Preconditions]

Output: The readyState attribute is newly equal to CAN_PLAY_THROUGH .


Input: [Event name] begin 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: [Patterns] RDF terms [Query Forms] SELECT [Other] VALUES [Modifiers]

Output: DISTINCT


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

Output: REDUCED


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

Output: Projection


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

Output: ORDER BY


Input: [Patterns] OPTIONAL [Modifiers]

Output: LIMIT


Input: [Patterns] UNION [Modifiers]

Output: OFFSET


Input: [Patterns] GRAPH [Modifiers]

Output: Select expressions


Input: [EXI Option] alignment [Description] Alignment of event codes and content items [Default Value]

Output: bit-packed

Table 2-3. EXI Options


Input: [EXI Option] compression [Description] Indicates if EXI compression is to be used for better compactness [Default Value]

Output: false

Table 2-3. EXI Options


Input: [EXI Option] strict [Description] Strict interpretation of schema is used to achieve better compactness [Default Value]

Output: false

Table 2-3. EXI Options


Input: [EXI Option] fragment [Description] Indicates if the body is to be encoded as an EXI fragment instead of an EXI document [Default Value]

Output: false

Table 2-3. EXI Options


Input: [EXI Option] preserve [Description] A set of options that controls whether comments, processing instructions, etc. are preserved [Default Value]

Output: all false

Table 2-3. EXI Options


Input: [EXI Option] selfContained [Description] Enables self-contained elements. Self-contained elements may be read independently from the rest of the EXI body [Default Value]

Output: false

Table 2-3. EXI Options


Input: [EXI Option] schemaId [Description] Identify the schema information, if any, used to encode the body [Default Value]

Output: no default value

Table 2-3. EXI Options


Input: [EXI Option] datatypeRepresentationMap [Description] Specify alternate datatype representations for typed values in the EXI body [Default Value]

Output: no default value

Table 2-3. EXI Options


Input: [EXI Option] blockSize [Description] Specifies the number of Attribute (AT) and Character (CH) values for each block used for EXI compression [Default Value]

Output: 1,000,000

Table 2-3. EXI Options


Input: [EXI Option] valueMaxLength [Description] Specifies the maximum string length of value content items to be considered for addition to the string table [Default Value]

Output: unbounded

Table 2-3. EXI Options


Input: [EXI Option] valuePartitionCapacity [Description] Specifies the total capacity of value partitions in a string table [Default Value]

Output: unbounded

Table 2-3. EXI Options


Input: [EXI Option] [user defined meta-data] [Description] User defined options may be added [Default Value]

Output: no default value

Table 2-3. EXI Options


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

Output: Agreement

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Offer

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Privacy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Request

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Set

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Ticket

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Specification] CORS [Spec Status] CR (Jan/Feb 2013) [Test Suite] Yes (WebApps WG); Yes (WebAppSec WG) [Remarks] Implementation Report [Test Suite Status]

Output: Complete or very close

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Specification] DOM 3 Events [Spec Status] LCWD [Test Suite] Yes [Remarks] Approved Tests [Test Suite Status]

Output: Complete or very close

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Specification] DOM4 [Spec Status] WD [Test Suite] Yes [Remarks] Approved Tests [Test Suite Status]

Output: Not complete

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Specification] Progress Events [Spec Status] CR [Test Suite] Yes [Test Suite Status]

Output: Complete

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Specification] Web Storage [Spec Status] CR [Test Suite] Yes [Remarks] Approved Tests [Test Suite Status]

Output: Complete or very close

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Specification] Web Workers [Spec Status] CR [Test Suite] Yes [Test Suite Status]

Output: Not complete

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Specification] XMLHttpRequest [Spec Status] WD [Test Suite] Yes [Test Suite Status]

Output: Not complete

Difference between revisions of "Testing/Common" - W3C Wiki


Input: [Property] hanging-punctuation [Values] none | [ first || [ force-end | allow-end ] || last ] [Initial] none [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: inline elements


Input: [Property] hyphens [Values] none | manual | auto [Initial] manual [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] letter-spacing [Values] normal | [Initial] normal [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] line-break [Values] auto | loose | normal | strict [Initial] auto [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] overflow-wrap [Values] normal | break-word [Initial] normal [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] tab-size [Values] | [Initial] 8 [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: block containers


Input: [Property] text-align [Values] start | end | left | right | center | justify | match-parent | start end [Initial] start [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: block containers


Input: [Property] text-align-last [Values] auto | start | end | left | right | center | justify [Initial] auto [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: block containers


Input: [Property] text-indent [Values] [ | ] && hanging? && each-line? [Initial] 0 [Inh.] yes [Percentages] refers to width of containing block [Media] visual [Applies to]

Output: block containers


Input: [Property] text-justify [Values] auto | none | inter-word | distribute [Initial] auto [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: block containers and, optionally, inline elements


Input: [Property] text-transform [Values] none | capitalize | uppercase | lowercase | full-width [Initial] none [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] white-space [Values] normal | pre | nowrap | pre-wrap | pre-line [Initial] normal [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] word-break [Values] normal | keep-all | break-all [Initial] normal [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Property] word-spacing [Values] [ normal | | ] [Initial] normal [Inh.] yes [Percentages] refers to width of the affected glyph [Media] visual [Applies to]

Output: all elements


Input: [Property] word-wrap [Values] normal | break-word [Initial] normal [Inh.] yes [Percentages] N/A [Media] visual [Applies to]

Output: all elements


Input: [Attribute Type] CDATA [Definition]

Output: Character data

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] ID [Definition]

Output: A document-unique identifier

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] IDREF [Definition]

Output: A reference to a document-unique identifier

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] IDREFS [Definition]

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

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] NAME [Definition]

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

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] NMTOKEN [Definition]

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

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] NMTOKENS [Definition]

Output: One or more whitespace separated NMTOKEN values

Modularization of XHTML - Defining Abstract Modules


Input: [Attribute Type] PCDATA [Definition]

Output: Processed character data

Modularization of XHTML - Defining Abstract Modules


Input: [Prefix] rdf: [URI] http://www.w3.org/1999/02/22-rdf-syntax-ns# [Description]

Output: The RDF Vocabulary

Semantic Web Applications in Neuromedicine (SWAN) Ontology


Input: [Prefix] rdfs: [URI] http://www.w3.org/2000/01/rdf-schema# [Description]

Output: The RDF Schema vocabulary

Semantic Web Applications in Neuromedicine (SWAN) Ontology


Input: [Prefix] xsd: [URI] http://www.w3.org/2001/XMLSchema# [Description]

Output: XML Schema

Semantic Web Applications in Neuromedicine (SWAN) Ontology


Input: [Prefix] foaf: [URI] http://xmlns.com/foaf/0.1/ [Description]

Output: Friend Of A Friend

Semantic Web Applications in Neuromedicine (SWAN) Ontology


Input: [Prefix] skos: [URI] http://www.w3.org/2008/05/skos# [Description]

Output: Simple Knowledge Organization System

Semantic Web Applications in Neuromedicine (SWAN) Ontology


Input: [Prefix] dc: [URI] http://purl.org/dc/elements/1.1/ [Description]

Output: Dublin Core Metadata Element Set, Version 1.1

Semantic Web Applications in Neuromedicine (SWAN) Ontology


Input: [Prefix] dcterms: [URI] http://purl.org/dc/terms/ [Description]

Output: Dublin Core Metadata Terms

Semantic Web Applications in Neuromedicine (SWAN) Ontology


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

Output: No conflict

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


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

Output: No conflict; added LDP headers

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


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

Output: No conflict; added LDP headers

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


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

Output: No conflict

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


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

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

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


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

Output: No conflict

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


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

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

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


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

Output: acceptTracking

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: attribute

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: compensate

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: delete

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: ensureExclusivity

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: include

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: inform

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: nextPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: obtainConsent

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: reviewPolicy

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: uninstall

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: watermark

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [type] abort [Bubbling phase] Yes [Target node types] Element [DOM interface] Event [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] blur [Bubbling phase] No [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] change [Bubbling phase] Yes [Target node types] Element [DOM interface] Event [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] click [Bubbling phase] Yes [Target node types] Element [DOM interface] MouseEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification


Input: [type] compositionstart [Bubbling phase] Yes [Target node types] Element [DOM interface] CompositionEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification


Input: [type] compositionupdate [Bubbling phase] Yes [Target node types] Element [DOM interface] CompositionEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification


Input: [type] compositionend [Bubbling phase] Yes [Target node types] Element [DOM interface] CompositionEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification


Input: [type] dblclick [Bubbling phase] Yes [Target node types] Element [DOM interface] MouseEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMActivate [Bubbling phase] Yes [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMAttributeNameChanged [Bubbling phase] Yes [Target node types] Element [DOM interface] MutationNameEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMAttrModified [Bubbling phase] Yes [Target node types] Element [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMCharacterDataModified [Bubbling phase] Yes [Target node types] Text, Comment, CDATASection, ProcessingInstruction [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMElementNameChanged [Bubbling phase] Yes [Target node types] Element [DOM interface] MutationNameEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMFocusIn [Bubbling phase] Yes [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMFocusOut [Bubbling phase] Yes [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMNodeInserted [Bubbling phase] Yes [Target node types] Element, Attr, Text, Comment, CDATASection, DocumentType, EntityReference, ProcessingInstruction [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMNodeInsertedIntoDocument [Bubbling phase] No [Target node types] Element, Attr, Text, Comment, CDATASection, DocumentType, EntityReference, ProcessingInstruction [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMNodeRemoved [Bubbling phase] Yes [Target node types] Element, Attr, Text, Comment, CDATASection, DocumentType, EntityReference, ProcessingInstruction [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMNodeRemovedFromDocument [Bubbling phase] No [Target node types] Element, Attr, Text, Comment, CDATASection, DocumentType, EntityReference, ProcessingInstruction [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] DOMSubtreeModified [Bubbling phase] Yes [Target node types] Document, DocumentFragment, Element, Attr [DOM interface] MutationEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] error [Bubbling phase] Yes [Target node types] Element [DOM interface] Event [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] focus [Bubbling phase] No [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] focusin [Bubbling phase] Yes [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] focusout [Bubbling phase] Yes [Target node types] Element [DOM interface] UIEvent [Cancelable]

Output: No

Document Object Model (DOM) Level 3 Events Specification


Input: [type] keydown [Bubbling phase] Yes [Target node types] Element [DOM interface] KeyboardEvent [Cancelable]

Output: Yes

Document Object Model (DOM) Level 3 Events Specification