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

Output: Yes


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

Output: Yes


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

Output: Yes


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

Output: Yes


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

Output: Yes


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

Output: No


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

Output: No


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

Output: No


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

Output: No


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

Output: No


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

Output: No


Input: [Function] op:to [Meaning]

Output: Returns the sequence containing every xs:integer between the values of the operands.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:id [Meaning]

Output: Returns the sequence of element nodes having an ID value matching the one or more of the supplied IDREF values.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:idref [Meaning]

Output: Returns the sequence of element or attribute nodes with an IDREF value matching one or more of the supplied ID values.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:doc [Meaning]

Output: Returns a document node retrieved using the specified URI.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:doc-available [Meaning]

Output: Returns true if a document node can be retrieved using the specified URI.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:collection [Meaning]

Output: Returns a sequence of nodes retrieved using the specified URI or the nodes in the default collection.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Default implied ARIA semantic] article role [Restrictions] Role must be either article, document, application, or main [Language feature]

Output: article element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] note role [Restrictions] Role must be either note, complementary, or search [Language feature]

Output: aside element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] document role [Restrictions] Role must be either document or application [Language feature]

Output: html element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] listitem role [Restrictions] Role must be either listitem or treeitem [Language feature]

Output: li element whose parent is an ol or ul element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] list role [Restrictions] Role must be either list, tree, or directory [Language feature]

Output: ol element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] status role [Restrictions] No restrictions [Language feature]

Output: output element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] region role [Restrictions] Role must be either region, document, application, contentinfo, main, search, alert, dialog, alertdialog, status, or log [Language feature]

Output: section element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] grid role [Restrictions] Role must be either grid or treegrid [Language feature]

Output: table element

li element whose parent is an ol or ul element


Input: [Default implied ARIA semantic] list role [Restrictions] Role must be either list or tree, or directory [Language feature]

Output: ul element

li element whose parent is an ol or ul element


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: [Event Identifier] DOMFocusIn [Description] Occurs when an element receives focus. [DOM3 event category] UIEvent [Animation event name] focusin [Bubbling phase] Yes [Cancel -able] No [uDOM interface]

Output: UIEvent


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

Output: UIEvent


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

Output: UIEvent


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

Output: MouseEvent


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

Output: MouseEvent


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

Output: MouseEvent


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

Output: MouseEvent


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

Output: MouseEvent


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

Output: MouseEvent


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

Output: TextEvent


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

Output: KeyboardEvent


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

Output: KeyboardEvent


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

Output: Event


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

Output: Event


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

Output: Event


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

Output: Event


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

Output: Event


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

Output: Event


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

Output: Event


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

Output: Event


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

Output: TimeEvent


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

Output: TimeEvent


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

Output: TimeEvent


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

Output: WheelEvent


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

Output: ProgressEvent


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

Output: ProgressEvent


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

Output: ProgressEvent


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

Output: Event


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

Output: ConnectionEvent


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

Output: ConnectionEvent


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

Output: ConnectionEvent


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

Output: ConnectionEvent


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

Output: ConnectionEvent


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


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.


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.


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

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


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.


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.


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

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


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.


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.


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.


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.


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.


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.


Input: [For this page] A plain text version of the page, handy for pasting into email. [,shortcut] ,text [Access control] Same as the document [General tool]

Output: HTML to Text converter


Input: [For this page] List of bad links in the page [,shortcut] ,checklink [Access control] Same as the document [General tool]

Output: Link Checker


Input: [For this page] Bad links in a page and in pages linked from it [,shortcut] ,rchecklink [Access control] Same as the document [General tool]

Output: Link Checker


Input: [For this page] List of HTML markup errors. [,shortcut] ,validate [Access control] Same as the document [General tool]

Output: HTML Validator


Input: [For this page] List of spelling errors. [,shortcut] ,spell [Access control] Same as the document [General tool]

Output: W3C Spellchecker


Input: [For this page] List of style CSS errors. [,shortcut] ,cssvalidate [Access control] Works only on public pages. [General tool]

Output: CSS Validator


Input: [For this page] Log of changes to the document [,shortcut] ,cvslog [Access control] Public on dev.w3.org, Team-only on www.w3.org [General tool]

Output: CVS Log


Input: [For this page] HTTP headers sent by the server [,shortcut] ,headers [Access control] Same as the document [General tool]

Output: Headers


Input: [For this page] Check the compliance of this document to the W3C publication rules [,shortcut] ,pubrules [Access control] Same as the document [General tool]

Output: the pubrules checker


Input: [For this page] Check the compliance of this document to the W3C publication rules, only displaying errors [,shortcut] ,pubruleserrors [Access control] Same as the document [General tool]

Output: the pubrules checker


Input: [Language feature] article element [Default implied ARIA semantic] article role [Restrictions]

Output: Role must be either article, document, application, or main


Input: [Language feature] aside element [Default implied ARIA semantic] note role [Restrictions]

Output: Role must be either note, complementary, or search


Input: [Language feature] html element [Default implied ARIA semantic] document role [Restrictions]

Output: Role must be either document or application


Input: [Language feature] li element whose parent is an ol or ul element [Default implied ARIA semantic] listitem role [Restrictions]

Output: Role must be either listitem or treeitem


Input: [Language feature] ol element [Default implied ARIA semantic] list role [Restrictions]

Output: Role must be either list, tree, or directory


Input: [Language feature] output element [Default implied ARIA semantic] status role [Restrictions]

Output: No restrictions


Input: [Language feature] section element [Default implied ARIA semantic] region role [Restrictions]

Output: Role must be either region, document, application, contentinfo, main, search, alert, dialog, alertdialog, status, or log


Input: [Language feature] table element [Default implied ARIA semantic] grid role [Restrictions]

Output: Role must be either grid or treegrid


Input: [Language feature] ul element [Default implied ARIA semantic] list role [Restrictions]

Output: Role must be either list or tree, or directory


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

Output: Notes

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] 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: [General tool] HTML to Text converter [,shortcut] ,text [Access control] Same as the document [For this page]

Output: A plain text version of the page, handy for pasting into email.


Input: [General tool] Link Checker [,shortcut] ,checklink [Access control] Same as the document [For this page]

Output: List of bad links in the page


Input: [General tool] Link Checker [,shortcut] ,rchecklink [Access control] Same as the document [For this page]

Output: Bad links in a page and in pages linked from it


Input: [General tool] HTML Validator [,shortcut] ,validate [Access control] Same as the document [For this page]

Output: List of HTML markup errors.


Input: [General tool] W3C Spellchecker [,shortcut] ,spell [Access control] Same as the document [For this page]

Output: List of spelling errors.


Input: [General tool] CSS Validator [,shortcut] ,cssvalidate [Access control] Works only on public pages. [For this page]

Output: List of style CSS errors.


Input: [General tool] CVS Log [,shortcut] ,cvslog [Access control] Public on dev.w3.org, Team-only on www.w3.org [For this page]

Output: Log of changes to the document


Input: [General tool] Headers [,shortcut] ,headers [Access control] Same as the document [For this page]

Output: HTTP headers sent by the server


Input: [General tool] the pubrules checker [,shortcut] ,pubrules [Access control] Same as the document [For this page]

Output: Check the compliance of this document to the W3C publication rules


Input: [General tool] the pubrules checker [,shortcut] ,pubruleserrors [Access control] Same as the document [For this page]

Output: Check the compliance of this document to the W3C publication rules, only displaying errors


Input: [Language feature] article element [Restrictions] Role must be either article, document, application, or main [Default implied ARIA semantic]

Output: article role


Input: [Language feature] aside element [Restrictions] Role must be either note, complementary, or search [Default implied ARIA semantic]

Output: note role


Input: [Language feature] html element [Restrictions] Role must be either document or application [Default implied ARIA semantic]

Output: document role


Input: [Language feature] li element whose parent is an ol or ul element [Restrictions] Role must be either listitem or treeitem [Default implied ARIA semantic]

Output: listitem role


Input: [Language feature] ol element [Restrictions] Role must be either list, tree, or directory [Default implied ARIA semantic]

Output: list role


Input: [Language feature] output element [Restrictions] No restrictions [Default implied ARIA semantic]

Output: status role


Input: [Language feature] section element [Restrictions] Role must be either region, document, application, contentinfo, main, search, alert, dialog, alertdialog, status, or log [Default implied ARIA semantic]

Output: region role


Input: [Language feature] table element [Restrictions] Role must be either grid or treegrid [Default implied ARIA semantic]

Output: grid role


Input: [Language feature] ul element [Restrictions] Role must be either list or tree, or directory [Default implied ARIA semantic]

Output: list role


Input: [Component] Context item [Scope]

Output: dynamic; changes during evaluation of path expressions and predicates

Dynamic Context Components


Input: [Component] Context position [Scope]

Output: dynamic; changes during evaluation of path expressions and predicates

Dynamic Context Components


Input: [Component] Context size [Scope]

Output: dynamic; changes during evaluation of path expressions and predicates

Dynamic Context Components


Input: [Component] Variable values [Scope]

Output: dynamic; for-expressions and quantified expressions can bind new variables

Dynamic Context Components


Input: [Component] Current date and time [Scope]

Output: global

Dynamic Context Components


Input: [Component] Implicit timezone [Scope]

Output: global

Dynamic Context Components


Input: [Component] Available documents [Scope]

Output: global

Dynamic Context Components


Input: [Component] Available collections [Scope]

Output: global

Dynamic Context Components


Input: [Part] 1 [Document] 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. [Type]

Output: For Users


Input: [Part] 2 [Document] 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. [Type]

Output: Core Specification


Input: [Part] 3 [Document] 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. [Type]

Output: Core Specification


Input: [Part] 4 [Document] Direct Semantics defines the meaning of OWL 2 ontologies in terms of a model-theoretic semantics. [Type]

Output: Core Specification


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: [Function] op:to [Meaning]

Output: Returns the sequence containing every xs:integer between the values of the operands.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:id [Meaning]

Output: Returns the sequence of element nodes having an ID value matching the one or more of the supplied IDREF values.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:idref [Meaning]

Output: Returns the sequence of element or attribute nodes with an IDREF value matching one or more of the supplied ID values.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:doc [Meaning]

Output: Returns a document node retrieved using the specified URI.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:doc-available [Meaning]

Output: Returns true if a document node can be retrieved using the specified URI.

XQuery 1.0 and XPath 2.0 Functions and Operators


Input: [Function] fn:collection [Meaning]

Output: Returns a sequence of nodes retrieved using the specified URI or the nodes in the default collection.

XQuery 1.0 and XPath 2.0 Functions and Operators


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

Output: alignment

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)

Table 5-1. EXI Options in Options Document


Input: [Description] EXI compression is used to achieve better compactness [Default Value] false [EXI Option]

Output: compression

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


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

Output: strict

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


Input: [Description] Body is encoded as an EXI fragment instead of an EXI document [Default Value] false [EXI Option]

Output: fragment

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


Input: [Description] Specifies whether the support for the preservation of comments, pis, etc. is each enabled [Default Value] all false [EXI Option]

Output: preserve

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


Input: [Description] Enables self-contained elements [Default Value] false [EXI Option]

Output: selfContained

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


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

Output: schemaId

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


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

Output: datatypeRepresentationMap

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


Input: [Description] Specifies the block size used for EXI compression [Default Value] 1,000,000 [EXI Option]

Output: blockSize

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


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

Output: valueMaxLength

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


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

Output: valuePartitionCapacity

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


Input: [Description] User defined meta-data may be added [Default Value] no default value [EXI Option]

Output: [user defined meta-data]

Efficient XML Interchange (EXI) Format 1.0 (Second Edition)


Input: [Data category] Translate [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] translate="yes" for elements, and translate="no" for attributes [Inheritance] Textual content of element, including content of child elements, but excluding attributes [Overriding]

Output: Yes

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Data category] Localization Note [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [Inheritance] Textual content of element, including content of child elements, but excluding attributes [Overriding]

Output: Yes

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Data category] Terminology [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] term="no" [Inheritance] None [Overriding]

Output: Not applicable

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Data category] Directionality [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] dir="ltr" [Inheritance] Textual content of element, including attributes and child elements [Overriding]

Output: Yes

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Data category] Ruby [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [Inheritance] None [Overriding]

Output: Not applicable

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Data category] Language Information [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] No Yes [Default Values] None [Inheritance] Textual content of element, including attributes and child elements [Overriding]

Output: Yes

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Data category] Elements Within Text [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] withinText="no" [Inheritance] None [Overriding]

Output: Not applicable

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


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

Output: A point defined with absolute coordinates

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

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


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

Output: The absolute dimension that the Asset may be resized

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The file format applicable to the Asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The defined industry sector applicable to the asset usage

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The natural language applicable to the asset usage

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The maximum period of metered usage time

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The value of the financial payment

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The specified Product or Service name

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: A point defined with reference to another position

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The relative dimension that the Asset may be resized

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The resolution at which the asset may be used

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: A code representing a geospatial area

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

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

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: An identifiable computing system

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: The scope of versions for the asset

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


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

Output: Specification of a digital locale

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party is the issuer of the policy statement [Comment] Must be supported. [Identifier]

Output: assigner

ODRL Version 2.1 Common Vocabulary | ODRL Community Group

Table 2.4.1: Terms for the attribute “function” of the entity Role


Input: [Semantics] The Party is the recipient of the policy statement [Comment] Must be supported. [Identifier]

Output: assignee

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party to be attributed [Comment] May be specified as part of the attribute action. [Identifier]

Output: attributedParty

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party to obtain consent from [Comment] May be specified as part of the obtainConsent action. [Identifier]

Output: consentingParty

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party to be informed of all uses [Comment] May be specified as part of the inform action. [Identifier]

Output: informedParty

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party is the recipient of the compensation [Comment] May be specified as part of the compensate duty action. [Identifier]

Output: compensatedParty

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Semantics] The Party is the usage tracker [Comment] May be specified as part of the acceptTracking action. [Identifier]

Output: trackingParty

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Event Identifier] DOMFocusIn [DOM3 event category] UIEvent [Animation event name] focusin [Bubbling phase] Yes [Cancel -able] No [uDOM interface] UIEvent [Description]

Output: Occurs when an element receives focus.


Input: [Event Identifier] DOMFocusOut [DOM3 event category] UIEvent [Animation event name] focusout [Bubbling phase] Yes [Cancel -able] No [uDOM interface] UIEvent [Description]

Output: Occurs when an element loses focus.


Input: [Event Identifier] DOMActivate [DOM3 event category] UIEvent [Animation event name] activate [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] UIEvent [Description]

Output: Occurs when an element is activated, for instance, through a mouse click or a keypress.


Input: [Event Identifier] click [DOM3 event category] MouseEvent [Animation event name] click [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [Description]

Output: Occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: mousedown, mouseup, click. If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition.


Input: [Event Identifier] mousedown [DOM3 event category] MouseEvent [Animation event name] mousedown [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [Description]

Output: Occurs when the pointing device button is pressed over an element.


Input: [Event Identifier] mouseup [DOM3 event category] MouseEvent [Animation event name] mouseup [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [Description]

Output: Occurs when the pointing device button is released over an element.


Input: [Event Identifier] mouseover [DOM3 event category] MouseEvent [Animation event name] mouseover [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [Description]

Output: Occurs when the pointing device is moved onto an element.


Input: [Event Identifier] mousemove [DOM3 event category] MouseEvent [Animation event name] mousemove [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [Description]

Output: Occurs when the pointing device is moved while it is over an element.


Input: [Event Identifier] mouseout [DOM3 event category] MouseEvent [Animation event name] mouseout [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] MouseEvent [Description]

Output: Occurs when the pointing device is moved away from an element.


Input: [Event Identifier] textInput [DOM3 event category] TextEvent [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] TextEvent [Description]

Output: One or more characters have been entered.


Input: [Event Identifier] keydown [DOM3 event category] KeyboardEvent [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] KeyboardEvent [Description]

Output: A key is pressed down. (The normative definition of this event is the description in the DOM3 Events specification.)


Input: [Event Identifier] keyup [DOM3 event category] KeyboardEvent [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] KeyboardEvent [Description]

Output: A key is released. (The normative definition of this event is the description in the DOM3 Events specification.)


Input: [Event Identifier] load [DOM3 event category] BasicEvent [Animation event name] load [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [Description]

Output: The event is triggered at the point at which the user agent finishes loading the element and any dependent resources (such as images, style sheets, or scripts). In the case the element references a script, the event will be raised only after an attempt to interpret the script has been made. Dependent resources that fail to load will not prevent this event from firing if the element that referenced them is still accessible via the DOM unless they are designated as externalResourcesRequired. The event is independent of the means by which the element was added to DOM tree.


Input: [Event Identifier] SVGLoad [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [Description]

Output: This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the load event, but the load event must be sent before the SVGLoad event.


Input: [Event Identifier] resize [DOM3 event category] BasicEvent [Animation event name] resize [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [Description]

Output: Occurs when a document view is being resized. This event is only applicable to 'svg' elements and is dispatched after the resize operation has taken place. The target of the event is the 'svg' element.


Input: [Event Identifier] SVGResize [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [Description]

Output: This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the resize event, but the resize event must be sent before the SVGResize event.


Input: [Event Identifier] scroll [DOM3 event category] BasicEvent [Animation event name] scroll [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [Description]

Output: Occurs when a document view is being shifted along the X or Y or both axis, either through a direct user interaction or any change on the currentTranslate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the shift modification has taken place. The target of the event is the 'svg' element.


Input: [Event Identifier] SVGScroll [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] Event [Description]

Output: This event is deprecated and is for backwards compatibility only, see notes below. This event is sent at the same time as the scroll event, but the scroll event must be sent before the SVGScroll event.


Input: [Event Identifier] SVGZoom [DOM3 event category] none [Animation event name] zoom [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [Description]

Output: Occurs when the zoom level of a document view is being changed, either through a direct user interaction or any change to the currentScale property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the zoom level modification has taken place. The target of the event is the 'svg' element.


Input: [Event Identifier] SVGRotate [DOM3 event category] none [Animation event name] rotate [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [Description]

Output: Occurs when the rotation of a document view is being changed, either through a direct user interaction or any change to the currentRotate property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the rotation modification has taken place. The target of the event is the 'svg' element.


Input: [Event Identifier] beginEvent [DOM3 event category] none [Animation event name] beginEvent [Bubbling phase] Yes [Cancel -able] No [uDOM interface] TimeEvent [Description]

Output: Occurs when a Timed Element begins. For details, see the description of the Events and event model in SMIL 2.1.


Input: [Event Identifier] endEvent [DOM3 event category] none [Animation event name] endEvent [Bubbling phase] Yes [Cancel -able] No [uDOM interface] TimeEvent [Description]

Output: Occurs when a Timed Element ends. For details, see the description of the Events and event model in SMIL 2.1.


Input: [Event Identifier] repeatEvent [DOM3 event category] none [Animation event name] repeatEvent [Bubbling phase] Yes [Cancel -able] No [uDOM interface] TimeEvent [Description]

Output: Occurs when a Timed Element repeats. It is raised each time the element repeats, after the first iteration. For details, see the description of the Events and event model in SMIL 2.1.


Input: [Event Identifier] SVGMousewheel [DOM3 event category] MouseEvent [Animation event name] none [Bubbling phase] Yes [Cancel -able] Yes [uDOM interface] WheelEvent [Description]

Output: Occurs when a rotational input device has been activated.


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

Output: A load operation has begun.


Input: [Event Identifier] SVGLoadProgress [DOM3 event category] none [Animation event name] none [Bubbling phase] Yes [Cancel -able] No [uDOM interface] ProgressEvent [Description]

Output: Progress has occurred in loading a given resource.


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

Output: A load operation has completed.


Input: [Event Identifier] SVGTimer [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] Event [Description]

Output: Occurs when the specified timer interval has elapsed for a timer. This event is triggered only by 'running' timers in the current global execution context of the SVG document (i.e. for timers which have been instantiated via the SVGGlobal interface and started via the start() method of the Timer interface). The target of the event is the 'timer' object itself. The event processing is limited to the target phase.


Input: [Event Identifier] SVGConnectionConnected [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [Description]

Output: Occurs when a connection has been established. No context information is available.


Input: [Event Identifier] SVGConnectionClosed [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [Description]

Output: Occurs when a connection has been closed. No context information is available


Input: [Event Identifier] SVGConnectionError [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [Description]

Output: Occurs when an error happens during the lifetime of a connection. Additional context information is available in the errorCode field.


Input: [Event Identifier] SVGConnectionDataSent [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [Description]

Output: Occurs when data has been successfully transmitted. No context information is available.


Input: [Event Identifier] SVGConnectionDataReceived [DOM3 event category] none [Animation event name] none [Bubbling phase] No [Cancel -able] No [uDOM interface] ConnectionEvent [Description]

Output: Occurs when data has been received on the connection. Additional context information is available on the receivedData field.


Input: [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] translate="yes" for elements, and translate="no" for attributes [Inheritance] Textual content of element, including content of child elements, but excluding attributes [Overriding] Yes [Data category]

Output: Translate

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [Inheritance] Textual content of element, including content of child elements, but excluding attributes [Overriding] Yes [Data category]

Output: Localization Note

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] term="no" [Inheritance] None [Overriding] Not applicable [Data category]

Output: Terminology

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] dir="ltr" [Inheritance] Textual content of element, including attributes and child elements [Overriding] Yes [Data category]

Output: Directionality

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [Inheritance] None [Overriding] Not applicable [Data category]

Output: Ruby

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] No Yes [Default Values] None [Inheritance] Textual content of element, including attributes and child elements [Overriding] Yes [Data category]

Output: Language Information

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] withinText="no" [Inheritance] None [Overriding] Not applicable [Data category]

Output: Elements Within Text

Internationalization Tag Set (ITS) Version 1.0 -- Review Version


Input: [Identifier] assigner [Semantics] The Party is the issuer of the policy statement [Comment]

Output: Must be supported.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] assignee [Semantics] The Party is the recipient of the policy statement [Comment]

Output: Must be supported.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] attributedParty [Semantics] The Party to be attributed [Comment]

Output: May be specified as part of the attribute action.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] consentingParty [Semantics] The Party to obtain consent from [Comment]

Output: May be specified as part of the obtainConsent action.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] informedParty [Semantics] The Party to be informed of all uses [Comment]

Output: May be specified as part of the inform action.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] compensatedParty [Semantics] The Party is the recipient of the compensation [Comment]

Output: May be specified as part of the compensate duty action.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [Identifier] trackingParty [Semantics] The Party is the usage tracker [Comment]

Output: May be specified as part of the acceptTracking action.

ODRL Version 2.1 Common Vocabulary | ODRL Community Group


Input: [LiveCycle Placement Rules] Default placement for the label is to the left of the control. If this is not possible, LiveCycle will attempt to place it immediately above the control. [Control Type]

Output: Text input (including date/time and password fields)

Text input (including date/time and password fields)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [LiveCycle Placement Rules] Default placement for the label is to the right of the check box. [Control Type]

Output: Checkbox

Text input (including date/time and password fields)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [LiveCycle Placement Rules] Default placement for the label for each individual radio button is to the right of the button. Create a visible caption for the radio button group by creating static text and placing it to the left of or above the group. (See Labeling radio buttons below.) [Control Type]

Output: Radio button group

Text input (including date/time and password fields)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [LiveCycle Placement Rules] Default placement for the label is to the left of the drop-down list. If this is not possible, LiveCycle will attempt to place it immediately above the control.. [Control Type]

Output: Combo box

Text input (including date/time and password fields)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [LiveCycle Placement Rules] Default placement for the label is above the list box. [Control Type]

Output: List box

Text input (including date/time and password fields)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [LiveCycle Placement Rules] LiveCycle automatically places the label on the button; it does not have to be positioned manually. Ensure that the button's purpose is properly described in the label text. [Control Type]

Output: Button

Text input (including date/time and password fields)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [Control Type] Text input (including date/time and password fields) [LiveCycle Placement Rules]

Output: Default placement for the label is to the left of the control. If this is not possible, LiveCycle will attempt to place it immediately above the control.

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [Control Type] Checkbox [LiveCycle Placement Rules]

Output: Default placement for the label is to the right of the check box.

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [Control Type] Radio button group [LiveCycle Placement Rules]

Output: Default placement for the label for each individual radio button is to the right of the button. Create a visible caption for the radio button group by creating static text and placing it to the left of or above the group. (See Labeling radio buttons below.)

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [Control Type] Combo box [LiveCycle Placement Rules]

Output: Default placement for the label is to the left of the drop-down list. If this is not possible, LiveCycle will attempt to place it immediately above the control..

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [Control Type] List box [LiveCycle Placement Rules]

Output: Default placement for the label is above the list box.

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [Control Type] Button [LiveCycle Placement Rules]

Output: LiveCycle automatically places the label on the button; it does not have to be positioned manually. Ensure that the button's purpose is properly described in the label text.

PDF10: Providing labels for interactive form controls in PDF documents | Techniques for WCAG 2.0


Input: [attribute] archive [function]

Output: For example, when defining an applet you could reference a space-separated list of jar files.


Input: [attribute] content-length [function]

Output: This is similar to meta data, in that this can be used by the object handler as a hint to the physical size of the object data that is to be processed.


Input: [attribute] data [function]

Output: This URI points to the object data to be processed. This can be an absolute URI (http://www.example.com/datafiles/myinstance.mpg), or a relative URI (myinstance.mpg). If you use a relative URI, then you will need to use the xml:base attribute to define the base location of the object data. This attribute should only refer to the data to be processed.


Input: [attribute] declare [function]

Output: This is used to delay the processing of the object data until such time that it is referred to by another element that requires the object data to be processed. In other words, the object data should be downloaded but should not be processed. For example, if an a element is coded to refer to the object element and the a element is activated, then the object data would be processed.


Input: [attribute] standby [function]

Output: The author can provide a text string that should be displayed while the object data is being downloaded and processed.


Input: [attribute] type [function]

Output: Defining the mime type of the object data will assist the object handler in determining whether the object data can be processed by the user agent or if an external application needs to be launched to process the object data.


Input: [attribute] xml:base [function]

Output: Use this attribute to define the base location of the object data. For example: http://www.example.com/datafiles/. This attribute should not be used for any other purpose.


Input: [Attributes] author author name [Is localizable string]

Output: yes

Configuration Attributes Table


Input: [Attributes] version widget version [Is localizable string]

Output: yes

Configuration Attributes Table


Input: [Attributes] shortName widget short name [Is localizable string]

Output: yes

Configuration Attributes Table


Input: [Attributes] name widget name [Is localizable string]

Output: yes

Configuration Attributes Table


Input: [Attributes] description widget description [Is localizable string]

Output: yes

Configuration Attributes Table


Input: [Attributes] authorEmail author email [Is localizable string]

Output: no

Configuration Attributes Table


Input: [Attributes] authorHref author href [Is localizable string]

Output: no

Configuration Attributes Table


Input: [Attributes] id widget id [Is localizable string]

Output: no

Configuration Attributes Table


Input: [Component] Address [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Nice to


Input: [Component] Address, email [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Alpha string, simple [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Alphanumeric string, non-fixed [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Nice to


Input: [Component] Alphanumeric string, sectioned [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Alphanumeric string, simple [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Browsable action list [Specification level] Return only [Task vs. Template] Template [Specification priority]

Output: Should


Input: [Component] Browsable selection list [Specification level] Return only [Task vs. Template] Template [Specification priority]

Output: Should


Input: [Component] Credit card information [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Confirmation & correction dialog [Specification level] Return only [Task vs. Template] Template [Specification priority]

Output: Should


Input: [Component] Currency [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Must


Input: [Component] Date, context-compensating [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Date, fully-specified [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Must


Input: [Component] Date, partially-specified [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Digit string, sectioned [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Digit string, simple [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Must


Input: [Component] Duration [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Error-recovery dialog, simple [Specification level] Configure & Return [Task vs. Template] Template [Specification priority]

Output: Should


Input: [Component] Menu [Specification level] Return only [Task vs. Template] Template [Specification priority]

Output: Must


Input: [Component] Multiple choice selections [Specification level] Return only [Task vs. Template] Template [Specification priority]

Output: Nice to


Input: [Component] Name, spelled [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Name, spoken & spelled [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Natural numbers [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Must


Input: [Component] Postal code [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Telephone number [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Time [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Must


Input: [Component] Time range [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] URL [Specification level] Return only [Task vs. Template] Task [Specification priority]

Output: Should


Input: [Component] Yes/No [Specification level] Configure & Return [Task vs. Template] Task [Specification priority]

Output: Must


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

Output: Identified


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

Output: Defined


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

Output: Identified


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

Output: Defined as far as possible


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

Output: Defined


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

Output: Not Defined


Input: [Part] 1 [Audience] Users [Document] PROV-PRIMER is the entry point to PROV offering an introduction to the provenance model. This is where you should start and for many may be the only document needed. [Type]

Output: Note


Input: [Part] 2 [Audience] Developers [Document] PROV-O defines a light-weight OWL2 ontology for the provenance model. This is intended for the Linked Data and Semantic Web community. [Type]

Output: Rec


Input: [Part] 3 [Audience] Developers [Document] PROV-XML defines an XML schema for the provenance model. This is intended for developers who need a native XML serialization of PROV [Type]

Output: Note


Input: [Part] 4 [Audience] Advanced [Document] PROV-DM defines a conceptual data model for provenance including UML diagrams. PROV-O and PROV-XML are serializations of this conceptual model. [Type]

Output: Rec


Input: [Part] 5 [Audience] Advanced [Document] PROV-N defines a human-readable notation for provenance. This is used to define the conceptual model as well as PROV-CONSTRAINTS. [Type]

Output: Rec


Input: [Part] 6 [Audience] Advanced [Document] PROV-CONSTRAINTS defines a set constraints that define a notion of valid provenance. It is specifically aimed at the implementors of validators. [Type]

Output: Rec


Input: [Part] 7 [Audience] Developers [Document] PROV-AQ defines how to use Web-based mechanisms to locate and retrieve provenance information. [Type]

Output: Note


Input: [Part] 8 [Audience] Developers [Document] PROV-DC defines a mapping between Dublin Core and PROV. [Type]

Output: Note


Input: [Part] 9 [Audience] Advanced [Document] PROV-LINKS Defines extensions to PROV to enable linking provenance information across containers for provenance [Type]

Output: Note


Input: [Property] box-decoration-break [Values] slice | clone [Initial] slice [Applies to] all elements [Percentages] N/A [Media] visual [Inh.]

Output: no


Input: [Property] break-after [Values] auto | avoid | always | any | avoid-page | page | left | right | recto | verso | avoid-column | column | avoid-region | region [Initial] auto [Applies to] block-level elements, table row groups, table rows (but see prose) [Percentages] N/A [Media] visual [Inh.]

Output: no


Input: [Property] break-before [Values] auto | avoid | always | any | avoid-page | page | left | right | recto | verso | avoid-column | column | avoid-region | region [Initial] auto [Applies to] block-level elements, table row groups, table rows (but see prose) [Percentages] N/A [Media] visual [Inh.]

Output: no


Input: [Property] break-inside [Values] auto | avoid | avoid-page | avoid-column | avoid-region [Initial] auto [Applies to] elements in the normal flow that that establish formatting contexts, or are block containers, table row groups, or table rows [Percentages] N/A [Media] visual [Inh.]

Output: no


Input: [Property] orphans [Initial] 2 [Applies to] block containers [Percentages] N/A [Media] visual [Inh.]

Output: yes


Input: [Property] widows [Initial] 2 [Applies to] block containers [Percentages] N/A [Media] visual [Inh.]

Output: yes


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


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


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

Output: Based on effectAllowed value


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


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

Output: Based on effectAllowed value


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

Output: Current drag operation


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

Output: Current drag operation


Input: [Commentor] LC-2834 Tim Berners-Lee (archived comment) [Comment] 4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything. ... 4.8 PATCH is optional. Suggest a MUST. PATCH is to first order the only thing LDP provides over WebDav. 4.8.2 MUST Suggest specify a the subset of sparql-update we use at the moment as a mandatory patch format to get basic interop, with possible later extension to other languages. ******* Something I mentioned in a mail a long time ago is the necessity of doing atomic flag (P/V) operations with a PATCH. To recap, you have to be able to do a form of DELETE triple(s) which will FAIL and prevent any corresponding INSERT from happening. This is top be able to allocate shared resources. Eg DELETE { :x :nextID 4 } INSERT DATA { ?x :nexID 5 }. Hmm. Maybe this is covered by the ETag system sufficiently. If so, the case should be given as an worked example and put in as a test case. A collaborative system which allows atomic flag setting is fundamentally more valuable than one which doesn't. [Commentor reply] tocheck [Working Group decision]

Output: The LDP specification brings several features such as paging and containers that are useful even in case of a read-only server. As for PATCH, everybody wants it but given the lack of a standard PATCH format and the WG timeframe it is unpractical for LDP to make PATCH mandatory. The WG is however committed to encourage support for PATCH and will do so via the LDP Best Practices and Guidelines document the WG plans to publish as a Note. As soon as a standard PATCH format is available the WG will revise the LDP spec to make use of it.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2835 Tim Berners-Lee (archived comment) [Comment] 4.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level of functionality which any LDPR allows and which does not require OPTIONS polling? OPTIONS is expensive: another round trip. Always avoid an extra round trip if you can. We need this system to move really fast. Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users. Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension or a POWDER label say). You have to do it for every fresh URI you find. The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS? Maybe key headers can be put into the HEAD and GET response. Maybe the class of resource announced with Link: rel=type can have a URI which can be looked up itself and cached. and will give the set of features in a standard way. Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that the core functionality is enough for clients to do what they need. Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred. [Commentor reply] tocheck [Working Group decision]

Output: OPTIONS is not required to achieve this. It could be used in cases when a client wants a low-cost means to learn more about the resource identified by the URI if it hasn't already done a GET. If it has done a GET and kept the header information, there is no need to use OPTIONS.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2812 Mark Baker (archived comment) [Comment] Hi. I raised this issue before, but it was never resolved to my satisfaction, so I'm raising it again now at LC. Sec 4.6.1 says "LDPR servers must remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI must result in a 404 (Not found) or 410 ". This is bad because it redefines HTTP DELETE, which already has a well defined meaning in RFC 2616. The definition in 4.6.1 is more specific than the one in 2616, and it's why you need the LDP-specific Link response header which basically tells the client that the 200 response doesn't mean what it says in RFC 2616, but instead what it says in LDP 1.0. The correct way to do this is to simply reuse the definition in 2616 so that the client knows nothing about the state of server after a DELETE has completed. I'm not familiar with the use case that requires those post conditions on DELETE, but from experience I can't imagine why a client would need to depend on this specific behaviour. Let me be clear though, my concern is *only* with the interface between client and server, not with server behaviour. If you want to define that LDP servers have to behave in a certain way, go nuts. But as soon as that information leaks into the interface, you've crossed a line, leaking implementation details so that the client is coupled not to the interface, but the implementation. The same problem with DELETE exists elsewhere in section 4 too, including with PUT, though the definition seems close enough to 2616 that I'm not sure why it's being redefined. So in addition to those concerns about section 4, I'm also concerned with the requirements on client implementations and don't understand why they're necessary. Some seem purely superfluous, such as 4.3.5, as it's part and parcel of the RDF model that resources can have multiple types (not to mention the open world assumption). The same goes for 4.3.6. 4.5.2 falls under this category too because that behaviour is just one possible path through HTTP's conflict detection mechanism. 4.5.3 and 4.5.4 seem more like BCPs that anything needing to be conformance criteria. 4.5.5 just seems like a badly phrased constraint on server implementation that has nothing to do with a client. 4.11.3.3 says that a client shouldn't invoke GET, really? Are you concerned about DoS issues like the W3C's DTD problem? http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ There's no reason to make this a criterion of correct client behaviour AFAICT 4.11.3.4 also seems like it's part and parcel with the RDF model In short, I think section 4 needs to be completely rewritten so that it; - contains no client conformance criteria - contains no interface conformance criteria In addition, the mandatory Link header should be removed so that clients won't be tempted to treat server behaviour implementation conformance criteria as interface conformance criteria; all LDP servers would be indistinguishable from Web servers. Thanks. [Commentor reply] yes [Working Group decision]

Output: Thank you for your feedback Mark. While we didn't go as far as rewriting section 4 entirely, we've modified it to ensure that the specification doesn't seem to be redefining HTTP which was never the intent. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#conformance clarifies the overall relationship between LDP and HTTP; 4.6.1 was removed entirely as a result. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#base-specs and http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient were added to clarify consequences of base specs and how LDP clients differ from HTTP clients. 4.11 (at risk) was removed entirely.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2833 Tim Berners-Lee (archived comment) [Comment] I have comments at various levels. Two things concern me mainly, firstly that the LDP platform will support the functionality which the RWW community has been using, including tabulator-based apps, and the second if that the platform in general provide a in interoperable functionality between compliant client and server. This last is threatened mainly by the huge number of SHOULD's for the server where I would have expected MUSTs to get interoperability, and a persistent theme throughout the spec the actual behavior a client or a server can expect of the other party relies completely on out-of-band agreements. To the extent that that is true, the document does not define an interoperable system. I'll go though in document order now. [...] 4.2.9 This is an example of a complete interop gap. The server might or might not mess with your triples in any way defined elsewhere. I suggest defining a clean simple high-interop version of the server in which the server doesn't mess with or constrain the client application at all. This is a really important use case. For the RWW world, LDP storage must be generic storage which be used with any app. Maybe we can make a profile of this spec for this case, with no domain knowledge or behavior in the server. If not, we have a problem. 4.2.10 "Conservative clients"?? you already have MUST and MAY, but now (and elsewhere) you have conservative (and presumably liberal) clients. If you want to create a new conformance class Conservative Client, by all means do so, but declare it in the Conformance section and SAY WHAT YOU GET from each level of conformance. A client is not an animal tiptoeing gingerly or not into the wide world out there, it is a small hard part of a machine which either works or doesn't work. The phase occurs elsewhere too. It is a red flag. (Why would a client want to be conservative? What is risked by not being? What would a liberal client do? Does this mean the server needs to be more specified to eliminate the risk) I would strongly support as an exercise looking at a version of the spec with everything which is not mandatory removed, and see what you end up being able to do with it. 4.3.4. Broken. No guarantee that anything will work. Suggest strongly the following:- LDP Clients MUST either give no accept header or must give a header which includes at least text/turtle and has NO OTHER mime type with a higher q. LDP servers, which a GET is received on a LDPR, if text/turtle is present and there is no other mime type with a higher q, they MUST return turtle. If there is no Accept header, they must return turtle. Protocol value: If a LDP client goes a GET it will get the data in turtle. Interop is achieved. This provides interoperability and also is compatible with HTTP. It allows existing conneg software to be used, and allows LDP to work within a general conneg-based server serving other things too. 4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything. 4.5.2 Same sort of problem. Are you preventing data loss or not? Suggest yes. Clients MUST use If-match and Servers MUST implement it (which may men ignoring it in a case where you know nothing else can change the data). Protocol value: Changes from others are never overwritten. 4.5.4 A server which throws out random triples is hard as a basis for RWW applications. We must have a profile in which the server has no domain knowledge. 4.5.6 MUST allow PUT. Otherwise, what is the point? (Note that for clients which use PUT To make resources in system that looks like a unix file system, servers will have to generate intermediate directories. It is very useful for servers to be able to map a unix-like file system, for many reasons, including the isomorphisms between remote and local storage. So the use case in which the LDP server is a big unix file system but with PATCH as a performance enhancement is important. This doesn't affect the spec in any normative way I can see.) In this case, objects are not made by POST to a collection, but being mentioned in a a new file with PUT and then later PATCH. 4.5.7 MUST not SHOULD. 4.6.2 Another totally grey area. When you DELTE a resource, the server may or may not remove triples with that subject from other resources. (When you delete R, any quad R P O R2) may be deleted. This is ripe for a profile, and in that profile the value of what happens must be explained. E.G. when you delete R then R is removed from any containers, so there is no C member R *on this server* or on some other URI region. This is hairy feature, as of course, as it can't apply to triples stored on another server, so people splitting data across different servers will get unexpected results. This sounds like another protocol which needs a lot more thought. For now, suggest the LDP spec doe snot specify such behaviour, maybe flag magic triple side effects as possible extension spec in future. [...] 4.10.2.1 "Conservative clients" again. Explain the value of doing this or not doing it. 4.10.2.2 Servers MAY do it. That means clients MUST handle it. 4.10.2.3. MUST [Commentor reply] tocheck [Working Group decision]

Output: The specification was changed to prevent silent loss of data. See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_2 Many MAYs and SHOULDs have been changed to MUSTs as requested. See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_3 However, imposing creation of resources via PUT is deemed unpractical at this time. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_3

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2836 Tim Berners-Lee (archived comment) [Comment] ######################### 4.10.2.3 303 lis a basically very unsatisfactory design because of the round trip. As this is a new spec, suggest defined 20X code meaning like a 303 but containing the representation of the thing 303d to. This has been found to a problem in LD. LDP can avoid it now. Benefit: First page back to user in one less round trip. ######################### 4.10.2.4.3 This design puts the type and next links in the data. I prefer I think using HTTP headers here as elsewhere. Page control stuff is very meta, messy to have it in with actual data. Not a problem for containers, but for normal LDPRs IMHO. [Commentor reply] tocheck [Working Group decision]

Output: Given the time constraints under which the WG is it is deemed unpractical to depend on defining a new response code as suggested. However, based on input from several HTTP experts the WG decided to return the first page with 200 response code on initial GET which prevents the additional roundtrip you objected to. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_2 Move Paging information out of the RDF content into HTTP headers. See http://www.w3.org/2013/meeting/ldp/2013-09-30#resolution_2

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2837 Tim Berners-Lee (archived comment) [Comment] 4.11.1 "LDP does not provide clients with any way to detect whether or not the server is capable of inlining (all its resources or any specific resource), nor does it provide clients with any way to influence which (if any) resources are inlined in any given response." This implies cleints must all be able to handle inlining and recover from it if they didn't really want it. Need to define a protocol here properly or abandon the feature. (N3 or one of its weak imitations is obviously a clear choice for a inlined data, as it allows you to preserve the provenance, and basically explain which triples are from which resource. I understand this would frighten people at this stage.) [Commentor reply] tocheck [Working Group decision]

Output: Drop inlining from the spec, put it on the wish list for LDPnext See http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_2

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2813 Ashok Malhotra (archived comment) [Comment] The spec says nothing about access control. Give that we are discussing read-write capabilities should we add some words like “To work with LDPRs clients must be authorized by the server and must have appropriate access control permissions”? [Commentor reply] yes [Working Group decision]

Output: Dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP See http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_5 See new Security Considerations section https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#security

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker