Input: [Feature/Operation] propID repository full proposals can be compactly represented, new negotiation and agreement are not necessary if an agreement already exists. [Key Word]

Output: SHOULD


Input: [Feature/Operation] data repository frequently requested user profile information is stored and managed by the user. [Key Word]

Output: MAY


Input: [Section] Data Definitions [Feature/Operation] new schema instantiation schemas other than the base set can be instantiated and supported by the agent. [Key Word]

Output: MAY


Input: [Section] Source Attribute [Feature/Operation] source attributes "matched-form" and "extension" agents support multiple, extensible mechanisms by which information is solicited. [Key Word]

Output: MAY


Input: [Description] The ability of users to obtain and correct information that an entity has collected about them [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Clause]

Output: Access


Input: [Description] The entity who the user is entering into an agreement with [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] certificate, URI, or text string [May be Defined in Vocabulary] yes [Clause]

Output: Agreement With


Input: [Description] The impact on the user of reaching an agreement [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Clause]

Output: Consequence


Input: [Description] Information for contacting a service with inquiries about the services privacy practices. [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Clause]

Output: Contact


Input: [Description] The space where a particular statement is valid [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] set of URIs [May be Defined in Vocabulary] no [Clause]

Output: Experience Space


Input: [Description] What a service will do with data [Applies to] statement [Required in Every Proposal] yes [Default Type of Label] none [May be Defined in Vocabulary] yes [Clause]

Output: Practice


Input: [Description] The data a service proposes to collect or requests [Applies to] statement [Required in Every Proposal] yes [Default Type of Label] see definition below [May be Defined in Vocabulary] no, but qualifier and category components may be [Clause]

Output: Qualified Data Set


Input: [Description] Used by the creator of a vocabulary to provide extra functionality beyond that in the base P3 Proposal Grammar [Applies to] proposal, statement, or clause [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary] yes [Clause]

Output: Qualifier


Input: [Description] A binary value indicating whether a particular practice, qualified data set, or statement is required in an agreement [Applies to] practice clause, qualified data set clause, or statement [Required in Every Proposal] no (defaults to 1 when not present) [Default Type of Label] 0 or 1 [May be Defined in Vocabulary] no [Clause]

Output: Required


Input: [Description] A URI that identifies a particular P3 proposal vocabulary [Applies to] proposal [Required in Every Proposal] yes [Default Type of Label] URI [May be Defined in Vocabulary] no [Clause]

Output: Schema


Input: [Description] Signature and attribution information as defined by the Digital Signature effort [Applies to] Proposal or statement [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary] yes [Clause]

Output: Signature


Input: [Category] Navigation and click-stream data [Structure] uri [Short display name] URI of requested resource [loginfo]

Output: uri

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] date [Short display name] Request timestamp [loginfo]

Output: timestamp

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Computer Information [Structure] ipaddr [Short display name] Client's IP address or hostname [loginfo]

Output: clientip

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] unstructured [Short display name] HTTP request method [loginfo]

Output: other.httpmethod

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] unstructured [Short display name] Data bytes in response [loginfo]

Output: other.bytes

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Category] Navigation and click-stream data [Structure] unstructured [Short display name] Response status code [loginfo]

Output: other.statuscode

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Values] true or false [Description] whether to do inclusive or exclusive dealing of namespaces. In exclusive mode the inclusiveNamespacePrefixList parameter can be specified listing the prefixes that are to be treated in an inclusive mode [Default] false [Name]

Output: exclusiveMode


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

Output: inclusiveNamespacePrefixList


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

Output: ignoreComments


Input: [Values] true or false [Description] whether to trim (i.e. remove leading and trailing whitespaces) all text nodes when canonicalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text nodes descendants of that element are not trimmed regardless of the value of this parameter. [Default] false [Name]

Output: trimTextNodes


Input: [Values] XML or EXI [Description] whether to do the normal XML serialization, or do an EXI serialization - which is useful if the original document to be signed is already in EXI format. [Default] XML [Name]

Output: serialization


Input: [Values] none, sequential, derived [Description] with none, prefixes are not changed, with sequential prefixes are changed to n1, n2, n3 ... and with derived, each prefix is changed to nSuffix, where the suffix is derived by doing a digest of the namespace URI. [Default] none [Name]

Output: prefixRewrite


Input: [Values] true or false [Description] whether the attributes need to be sorted before canonicalization. In some environments the order of attributes changes in transit so sorting is important. [Default] true [Name]

Output: sortAttributes


Input: [Values] true or false [Description] if set to true, ignore the DTD completely, which means do not normalize attributes, do not look into entity definitions, do not add default attributes to each element [Default] false [Name]

Output: ignoreDTD


Input: [Values] true or false [Description] if set to true ignore all entity declarations, and expand only the predefined entites (lt, gt, amp, apos, quot) and character references. (Entity declarations are potential attack points, [BradHill] mentions an entity that is 2 GB is length, also expanding external entities can lead to cross site scripting attacks) [Default] true [Name]

Output: expandEntities


Input: [Values] inherit, none, combine [Description] whether to inherit xml:base attributes from ancestors (like C14N 1.0) or not (like Exc C14n 1.0) or combine them (like C14n 1.1) [Default] combine [Name]

Output: xmlBaseAncestors


Input: [Values] inherit, none [Description] whether to inherit xml:id attributes from ancestors (like C14N 1.0) or not (like C14N 1.1 or Exc C14n 1.0) [Default] none [Name]

Output: xmlIdAncestors


Input: [Values] inherit, none [Description] whether to inherit xml:lang attributes from ancestors (like C14N 1.0 and C14n 1.1) or not (Exc C14n 1.0) [Default] inherit [Name]

Output: xmlLangAncestors


Input: [Values] inherit, none [Description] whether to inherit xml:space attributes from ancestors (like C14N 1.0 and C14n 1.1) or not (Exc C14n 1.0) [Default] inherit [Name]

Output: xmlSpaceAncestors


Input: [Values] true or false [Description] if set to true, looks for namespace prefix usages in xsi:type attributes as well, otherwise xsi:type attributes are treated just like regular attributes. [Default] false [Name]

Output: xsiTypeAware


Input: [Competency] Describe usability concepts Identify design strategies [Evaluation Method] Journal Blog [Topic]

Output: Usability Concepts & Design Strategies

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Distinguish what the methods are Describe test methods Identify the approprate methods to use for testing [Evaluation Method] Usability Quiz Case Study Evaluation [Topic]

Output: Usability Testing Methods

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Recognize which test method is appropriate for the situation Distinguish between a co-discovery or individual testing session Identify tools, parameters, and constraints for testing Describe the intended audience [Evaluation Method] Test Plan SOW (document): choose 1 of the sites they evaluated for assignment 1; build a justification for testing this site using one of the methods discussed in Usability Testing Methods section (what method is best, individual vs. co-discovery, tools, etc.) [Topic]

Output: Planning for a Usability Test

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Identify the intended audience Developing strategies for recruiting individuals that resemble the intended audience Develop recruitment materials (i.e. screener, follow-up email, etc.) Explain incentive for participants Define a preferred number of participants [Evaluation Method] Screener Document [Topic]

Output: Recruiting

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Design appropriate tasks for the usability test Describe tentative data measures associated success factors Create a schedule for testing dates and milestones Describe the testing environment, required equipment, and logistics Develop testing materials (i.e. moderator/facilitator guide, consent forms, and surveys) [Evaluation Method] Test Plan [Topic]

Output: Designing a Usability Test Plan

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Describe the criteria for being an effective moderator (i.e. based on co-discovery or individual sessions) Identify and demonstrate appropriate note taking techniques Execute the usability test plan [Evaluation Method] Usability Lab [Topic]

Output: Conducting a Usability Test Session

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Identify and interpret the testing results(i.e. qualitative, quantitative, assessments, etc.) Create and organize collected data for further analysis Identify data patterns and recognize data that could potentially be invalid Identify and prioritize findings into design revisions or solutions [Evaluation Method] Data Summary Memo [Topic]

Output: Analyzing Data

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Identify the appropriate communication method for intended audience who is using the results Describe findings into actionable recommendations Distinguish findings that have the most impact Indicate areas where further research is required [Evaluation Method] Usability Report [Topic]

Output: Communicating Results

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Competency] Distinguish what the method variations are (i.e. eye tracking, biometrics, etc.) Describe variations on basic methods Identify the appropriate methods to use for testing [Evaluation Method] Brief Paper [Topic]

Output: Variation of Techniques

Es/Interact/Usabilidad 1 - Web Education Community Group


Input: [Numerical Code] 200 [Textual Description] OK [Example]

Output: property delivered correctly


Input: [Numerical Code] 204 [Textual Description] No Content [Example]

Output: property retrieved without content


Input: [Numerical Code] 206 [Textual Description] Partial Content [Example]

Output: only a subset of the available data stored in the result set


Input: [Numerical Code] 400 [Textual Description] Bad Request [Example]

Output: syntactical error


Input: [Numerical Code] 404 [Textual Description] Not Found [Example]

Output: the queries resource is not found


Input: [Numerical Code] 415 [Textual Description] Unsupported Media Type [Example]

Output: get duration call on an image data store


Input: [Numerical Code] 462 [Textual Description] Property not defined in Source Format [Example]

Output: location is not defined in MediaRSS


Input: [Numerical Code] 500 [Textual Description] Internal Server Error [Example]

Output: internal library (e.g., extractor) crashes


Input: [Numerical Code] 562 [Textual Description] Property not supported [Example]

Output: a subset of properties implemented


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 [XML examples] local, global [HTML5 examples] local, global

Output: Textual content of element, including content of child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Localization Note [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] local, global [HTML5 examples] local, global

Output: Textual content of element, including content of child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Terminology [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] term="no" [XML examples] local, global [HTML5 examples] local, global

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Directionality [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] dir="ltr" [XML examples] local, global [HTML5 examples] tbd

Output: Textual content of element, including attributes and child elements

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Ruby [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] local, global [HTML5 examples] tbd

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Language Information [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] No Yes [Default Values] None [XML examples] global [HTML5 examples] global

Output: Textual content of element, including attributes and child elements

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Elements Within Text [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] withinText="no" [XML examples] local, global [HTML5 examples] local, global

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Domain [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] global [HTML5 examples] global

Output: Textual content of element, including attributes and child elements

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Disambiguation [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] local [HTML5 examples] local, global

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Locale Filter [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] localeFilterList="*" [XML examples] local, global [HTML5 examples] local, global

Output: Textual content of element, including attributes and child elements

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Translation Agent Provenance [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] tbd [HTML5 examples] tbd

Output: Textual content of element, including child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] External Resource [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] No Yes [Default Values] None [XML examples] global [HTML5 examples] global

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Target Pointer [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] No Yes [Default Values] None [XML examples] global [HTML5 examples] global

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Id Value [Local Usage] No [Global, rule-based selection] Yes [Global adding of information] No Yes [Default Values] None [XML examples] global [HTML5 examples] global

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Preserve Space [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] default [XML examples] local, global [HTML5 examples] n/a

Output: Textual content of element, including attributes and child elements

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Localization Quality Issue [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] tbd [HTML5 examples] tbd

Output: Textual content of element, including child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Localization Quality Précis [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] tbd [HTML5 examples] tbd

Output: Textual content of element, including child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] MT Confidence [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes No [Default Values] None [XML examples] tbd [HTML5 examples] tbd

Output: Textual content of element, including child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Allowed Characters [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] None [XML examples] tbd [HTML5 examples] tbd

Output: Textual content of element, including child elements, but excluding attributes

Internationalization Tag Set (ITS) Version 2.0


Input: [Data category] Storage Size [Local Usage] Yes [Global, rule-based selection] Yes [Global adding of information] Yes Yes [Default Values] storageEncoding="UTF-8" [XML examples] tbd [HTML5 examples] tbd

Internationalization Tag Set (ITS) Version 2.0


Input: [Clause] Access [Description] The ability of users to obtain and correct information that an entity has collected about them [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Clause] Agreement With [Description] The entity who the user is entering into an agreement with [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] certificate, URI, or text string [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Clause] Consequence [Description] The impact on the user of reaching an agreement [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Clause] Contact [Description] Information for contacting a service with inquiries about the services privacy practices. [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Clause] Experience Space [Description] The space where a particular statement is valid [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] set of URIs [May be Defined in Vocabulary]

Output: no

no, but qualifier and category components may be


Input: [Clause] Practice [Description] What a service will do with data [Applies to] statement [Required in Every Proposal] yes [Default Type of Label] none [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Clause] Qualified Data Set [Description] The data a service proposes to collect or requests [Applies to] statement [Required in Every Proposal] yes [Default Type of Label] see definition below [May be Defined in Vocabulary]

Output: no, but qualifier and category components may be

no, but qualifier and category components may be


Input: [Clause] Qualifier [Description] Used by the creator of a vocabulary to provide extra functionality beyond that in the base P3 Proposal Grammar [Applies to] proposal, statement, or clause [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Clause] Required [Description] A binary value indicating whether a particular practice, qualified data set, or statement is required in an agreement [Applies to] practice clause, qualified data set clause, or statement [Required in Every Proposal] no (defaults to 1 when not present) [Default Type of Label] 0 or 1 [May be Defined in Vocabulary]

Output: no

no, but qualifier and category components may be


Input: [Clause] Schema [Description] A URI that identifies a particular P3 proposal vocabulary [Applies to] proposal [Required in Every Proposal] yes [Default Type of Label] URI [May be Defined in Vocabulary]

Output: no

no, but qualifier and category components may be


Input: [Clause] Signature [Description] Signature and attribution information as defined by the Digital Signature effort [Applies to] Proposal or statement [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary]

Output: yes

no, but qualifier and category components may be


Input: [Description] An incorrect term or a term from the wrong domain was used or terms are used inconsistently. [Example] The localization had “Pen Drive” when corporate terminology specified that “USB Stick” was to be used. The localized text inconsistently used "Start" and "Begin". A text renders the Hungarian term recsegőhid as “buzzer bridge” in English (a literal translation), but the term to be used in English is “wedge block,” as specified in a terminology list supplied to the translator. [Scope] S or T [Notes] This value is not intended for simple typographical errors or word choice not related to defined terminologies. For example, a mistyping of “pin” as “pen” or the use of “imply” instead of “infer” (mistaking two commonly confused words) would not count as terminology issues and is best categorized as either spelling errors or mistranslations, depending on the nature of the issue. Terminology refers only to cases where incorrect choices about terms (either formal or commonly defined in a domain) are involved. [Value]

Output: terminology

Internationalization Tag Set (ITS) Version 2.0


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

Output: mistranslation

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Necessary text has been omitted from the localization or source. [Example] One or more segments found in the source that have been intended for translation are missing in the target. After an alignment, a verification tool flags the pairs of aligned segments where the target has no corresponding source because of incorrect segmentation or some alignment issue. In such case the 'omission' type may apply to the source entry. [Scope] S or T [Notes] This value is not to be used for missing whitespace or formatting codes, but instead has to be reserved for linguistic content. [Value]

Output: omission

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Content that has been intended for translation is left untranslated. [Example] The source segment reads "The Professor said to Smith that he would hear from his lawyer" but the Hungarian localization reads "A professzor azt mondta Smithnek, hogy he would hear from his lawyer." [Scope] T [Notes] omission takes precedence over untranslated. Omissions are distinct in that they address cases where text is not present, while untranslated addresses cases where text has been carried from the source untranslated. [Value]

Output: untranslated

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The translated text contains inappropriate additions. [Example] The translated text contains a note from the translator to himself to look up a term; the note ought to have been deleted but was not. [Scope] T [Value]

Output: addition

Internationalization Tag Set (ITS) Version 2.0


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

Output: duplication

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text is inconsistent with itself or is translated inconsistently (NB: not for use with terminology inconsistency). [Example] The text states that an event happened in 1912 in one location but in another states that it happened in 1812. The translated text uses different wording for multiple instances of a single regulatory notice that occurs in multiple locations in a series of manuals. [Scope] S or T [Value]

Output: inconsistency

Internationalization Tag Set (ITS) Version 2.0


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

Output: grammar

Internationalization Tag Set (ITS) Version 2.0


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

Output: legal

Internationalization Tag Set (ITS) Version 2.0


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

Output: register

Internationalization Tag Set (ITS) Version 2.0


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

Output: locale-specific-content

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Text violates norms for the intended locale. [Example] A text localized into German has dates in mm/dd/yyyy format instead of DD.MM.YYYY. A text for the Irish market uses American-style foot and inch measurements instead of centimeters. A text intended for a U.S.-based audience uses U.K. spellings such as “centre” and “colour.” [Scope] S or T [Notes] This value can be used for spelling errors only if they relate specifically to locale expectations (e.g., a text consistently uses British instead of U.S. spellings for a text intended for the U.S.). If these errors are not systematic (e.g., a text uses U.S. spellings but has a single instance of “centre”), they are instead to be counted as spelling errors. [Value]

Output: locale-violation

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text contains stylistic errors. [Example] Company style guidelines dictate that all individuals be referred to as Mr. or Ms. with a family name, but the text refers to “Jack Smith”. [Scope] S or T [Value]

Output: style

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears. [Example] A text ought to have a '•' but instead has a '¥' sign. A German text erroneously uses û, ô, and â instead of the appropriate 'ü', 'ö', and 'ä'. A Japanese text has been garbled and appears with Devanagari characters. [Scope] S or T [Notes] Characters ought to be used in cases of garbling or systematic use of inappropriate characters, not for spelling issues where individual characters are replaced with incorrect one. [Value]

Output: characters

Internationalization Tag Set (ITS) Version 2.0


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

Output: misspelling

Internationalization Tag Set (ITS) Version 2.0


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

Output: typographical

Internationalization Tag Set (ITS) Version 2.0


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

Output: formatting

Internationalization Tag Set (ITS) Version 2.0


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

Output: inconsistent-entities

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Numbers are inconsistent between source and target. [Example] A source text states that an object is 120 cm long, but the target text says that it is 129 cm. long. [Scope] S or T [Notes] Some tools may correct for differences in units of measurement to reduce false positives (e.g., a tool might adjust for differences in values between inches and centimeters to avoid flagging numbers that seem to be different but are in fact equivalent). [Value]

Output: numbers

Internationalization Tag Set (ITS) Version 2.0


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

Output: markup

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content). [Example] The tool disallows the regular expression pattern ['"”’][\.,] but the translated text contains "A leading “expert”, a political hack, claimed otherwise." A tool uses a regular expression to ensure that the content of an element is an IRI and flags what appears to be a malformed IRI. [Scope] S or T [Notes] Defining what is or is not an allowable pattern is up to the processing application and is beyond the scope of this specification. Best practice would be to use the Comment attribute to specify the pattern that led to the issue. [Value]

Output: pattern-problem

Internationalization Tag Set (ITS) Version 2.0


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

Output: whitespace

Internationalization Tag Set (ITS) Version 2.0


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

Output: internationalization

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] There is a significant difference in source and target length. [Example] The translation of a segment is five times as long as the source. [Scope] S or T [Notes] What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef. [Value]

Output: length

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The content is deemed to show poor statistical conformance to a reference corpus. Higher severity values reflect poorer conformance. [Example] The sentence "The harbour connected which to printer is busy or configared not properly." would have poor conformance. [Scope] S or T [Notes] Non-conformance is determined through the use of multiple statistical measures of similarity to a corpus of known-good content. For example, in a system that uses classification techniques the poor conformance might be a function of combined incorrect terminology, wrong spelling and bad grammar, or other features as determined by the system. [Value]

Output: non-conformance

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] The issue either has not been categorized or cannot be categorized. [Example] A new version of a tool returns information on an issue that has not been previously checked and that is not yet classified. A text is defective in ways that defy categorization, such as the appearance of nonsense garbled text of unknown origin (e.g., a translation shows an unintelligible result and/or appears unrelated to the source material). [Scope] S or T [Notes] This value has the following uses: A tool can use it to pass through quality data from another tool in cases where the issues from the other tool are not classified (for example, a localization quality assurance tool interfaces with a third-party grammar checker). A tool’s issues are not yet assigned to values, and, until an updated assignment is made, they may be listed as uncategorized. In this case it is recommended that issues be assigned to appropriate values as soon as possible since uncategorized does not foster interoperability. uncategorized can be used where a portion of text is defective in a way that defies assignment to a value in either the originating system or in any other ITS localization quality markup to indicate that it is uncategorizable. [Value]

Output: uncategorized

Internationalization Tag Set (ITS) Version 2.0


Input: [Description] Any issue that cannot be assigned to any values listed above. [Scope] S or T [Notes] This value allows for the inclusion of any issues not included in the previously listed values. It is encouraged not to use this value for any tool- or model-specific issues that can be mapped to the values listed above. In addition, this value is not synonymous with uncategorized in that uncategorized issues may be assigned to another precise value, while other issues cannot. If a system has an "miscellaneous" or "other" value, it is better to map this to this value even if the specific instance of the issue might be mapped to another value. [Value]

Output: other

Internationalization Tag Set (ITS) Version 2.0


Input: [user] name [Category] Physical Contact Information, Demographic and Socioeconomic Data [Structure] personname [Short display name]

Output: User's Name

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] bdate [Category] Demographic and Socioeconomic Data [Structure] date [Short display name]

Output: User's Birth Date

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] cert [Category] Unique Identifiers [Structure] certificate [Short display name]

Output: User's Identity Certificate

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] gender [Category] Demographic and Socioeconomic Data [Structure] unstructured [Short display name]

Output: User's Gender (male or female)

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] employer [Category] Demographic and Socioeconomic Data [Structure] unstructured [Short display name]

Output: User's Employer

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] department [Category] Demographic and Socioeconomic Data [Structure] unstructured [Short display name]

Output: Department or division of organization where user is employed

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] jobtitle [Category] Demographic and Socioeconomic Data [Structure] unstructured [Short display name]

Output: User's Job Title

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] home-info [Category] Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data [Structure] contact [Short display name]

Output: User's Home Contact Information

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [user] business-info [Category] Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data [Structure] contact [Short display name]

Output: User's Business Contact Information

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification


Input: [Clause] Access [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Description]

Output: The ability of users to obtain and correct information that an entity has collected about them


Input: [Clause] Agreement With [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] certificate, URI, or text string [May be Defined in Vocabulary] yes [Description]

Output: The entity who the user is entering into an agreement with


Input: [Clause] Consequence [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Description]

Output: The impact on the user of reaching an agreement


Input: [Clause] Contact [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] URI or text string [May be Defined in Vocabulary] yes [Description]

Output: Information for contacting a service with inquiries about the services privacy practices.


Input: [Clause] Experience Space [Applies to] proposal or statement [Required in Every Proposal] yes [Default Type of Label] set of URIs [May be Defined in Vocabulary] no [Description]

Output: The space where a particular statement is valid


Input: [Clause] Practice [Applies to] statement [Required in Every Proposal] yes [Default Type of Label] none [May be Defined in Vocabulary] yes [Description]

Output: What a service will do with data


Input: [Clause] Qualified Data Set [Applies to] statement [Required in Every Proposal] yes [Default Type of Label] see definition below [May be Defined in Vocabulary] no, but qualifier and category components may be [Description]

Output: The data a service proposes to collect or requests


Input: [Clause] Qualifier [Applies to] proposal, statement, or clause [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary] yes [Description]

Output: Used by the creator of a vocabulary to provide extra functionality beyond that in the base P3 Proposal Grammar


Input: [Clause] Required [Applies to] practice clause, qualified data set clause, or statement [Required in Every Proposal] no (defaults to 1 when not present) [Default Type of Label] 0 or 1 [May be Defined in Vocabulary] no [Description]

Output: A binary value indicating whether a particular practice, qualified data set, or statement is required in an agreement


Input: [Clause] Schema [Applies to] proposal [Required in Every Proposal] yes [Default Type of Label] URI [May be Defined in Vocabulary] no [Description]

Output: A URI that identifies a particular P3 proposal vocabulary


Input: [Clause] Signature [Applies to] Proposal or statement [Required in Every Proposal] no [Default Type of Label] none [May be Defined in Vocabulary] yes [Description]

Output: Signature and attribution information as defined by the Digital Signature effort


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

Output: The user agent begins looking for media data, as part of the resource selection algorithm.


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState equals NETWORK_LOADING [Dispatched when...]

Output: The user agent is fetching media data.


Input: [Event name] suspend [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState equals NETWORK_IDLE [Dispatched when...]

Output: The user agent is intentionally not currently fetching media data, but does not have the entire media resource downloaded.


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

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


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

Output: The user agent stops fetching the media data before it is completely downloaded.


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

Output: An error occurs while fetching the media data.


Input: [Event name] loadend [Interface] ProgressEvent [PROGRESS] [Preconditions] One of load, abort, or error has just fired. [Dispatched when...]

Output: The user agent stops fetching the media data, for whatever reason.


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

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


Input: [Event name] stalled [Interface] ProgressEvent [Preconditions] networkState is NETWORK_LOADING. [Dispatched when...]

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


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

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


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

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


Input: [Event name] loadedmetadata [Interface] Event [Preconditions] readyState is newly equal to HAVE_METADATA or greater for the first time. [Dispatched when...]

Output: The user agent has just determined the duration and dimensions of the media resource.


Input: [Event name] loadeddata [Interface] Event [Preconditions] readyState newly increased to HAVE_CURRENT_DATA or greater for the first time. [Dispatched when...]

Output: The user agent can render the media data at the current playback position for the first time.


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

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


Input: [Event name] playing [Interface] Event [Preconditions] readyState is newly equal to or greater than HAVE_FUTURE_DATA, paused is false, seeking is false, or the current playback position is contained in one of the ranges in buffered. [Dispatched when...]

Output: Playback has started.


Input: [Event name] canplay [Interface] Event [Preconditions] readyState newly increased to HAVE_FUTURE_DATA or greater. [Dispatched when...]

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


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

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


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

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


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

Output: The seeking DOM attribute changed to false.


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

Output: The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously.


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

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


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

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


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

Output: The duration attribute has just been updated.


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

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


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

Output: Visual

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

Source Access Mode (before augmentation)


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

Output: Visual

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

Source Access Mode (before augmentation)


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

Output: Visual

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

Source Access Mode (before augmentation)


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

Output: Auditory

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

Source Access Mode (before augmentation)


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

Output: Auditory

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

Source Access Mode (before augmentation)


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

Output: Auditory

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

Source Access Mode (before augmentation)


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

Output: Visual

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

Source Access Mode (before augmentation)


Input: [Expected Values] braille [Augmented Access Mode] Tactile [Description] braille content or alternative is available (e.g., eBraille or print braille) This can have extensions for the different types of braille, /ASCII, /music, /math, /chem or /nemeth) (also consider /contracted and /gradeII or other nomenclature... pretty open)

Output: Visual or Textual

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

Source Access Mode (before augmentation)


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

Output: Visual

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

Source Access Mode (before augmentation)


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

Output: Visual

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

Source Access Mode (before augmentation)


Input: [Commentor] LC-421 on behalf of I18N WG [Working Group decision] The Best Practices do not set requirements on user agents, only on content; we already give recommendations on input mode for the content (see AVOID_FREE_TEXT and DEFAULT_INPUT_MODE]. Any further consideration would better fit in the techniques related to these best practices, on which we welcome contributions: link link [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 6 At link Editorial/substantive: S Owner: FS Location in reviewed document: Sec. 2.2 [link] Comment: We propose to add to this section on \"input\" the requirement to provide an adequate input method for the user. Especially for complex scripts like Chinese or Japanese, this is a crucial requirement.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-422 on behalf of I18N WG [Working Group decision] We have not found sufficient support for this encoding scheme in mobile devices. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 7 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec.2.3 [link] Comment: In some character encodings like UTF-8, scripts with a similar number of characters (e.g. latin versus indic scripts) vary in space requirements. To avoid high bandwidth / cost related to scripts, you might propose for such cases the use of the compression scheme for unicode [link] .

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-433 on behalf of I18N WG [Working Group decision] We have added a link to the I18N tutorial on specifying the encoding and have added the specific case you mention in the related technique: link (note that the document only focuses on XHTML, not on HTML) [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 18 At link Editorial/substantive: S Owner: RI Location in reviewed document: 5.4.12 Comment: The section mentions the use of the XML declaration for declaring in-document the encoding of XML documents, but makes no mention of the standard in-document declaration of encoding for HTML documents or XHTML served as text/html, which uses the Content-Type meta element. This seems a strange omission. Please add text describing this.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-436 on behalf of I18N WG [Working Group decision] After futher discussion with Richard Ishida, we have added more specific recommendations as to why using Unicode is a smart thing to do: "Encoding of the content to a desired character encoding is dependent on the authoring tools being used, Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1] and [CHARSET2]. Unicode is a good choice for representing content when served in multiple languages. The amount of bandwidth required to transmit content can vary significantly depending on the character encoding used. Text consisting principally of characters from the Latin alphabet will encode more efficiently in UTF-8, whereas text consisting principally of characters from ideographic scripts will encode more efficiently in UTF-16. When choosing a character encoding, consider the efficiency of the available encodings. Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8. " [Commentor reply] yes [Comment]

Output: Comment from the i18n review of: link Comment 21 At link Editorial/substantive: S Owner: RI Location in reviewed document: General Comment: We believe the document should encourage all participants in the mobile value chain to support Unicode. This is extremely helpful in ensuring international use of this technology and ease of localization of content.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-393 on behalf of Nokia [Working Group decision] Timezone inaccuracies in the client don't normally affect caching since it relies on GMT time. Clock skews aren't specific to mobile devices and should be handled as a case of deficiency in the implementation when specific to a given mobile device. As such, we haven't modified the document, but would welcome a technique on this specific item: link [Commentor reply] no reply from commenter [Comment]

Output: 5.4.15 Cache Headers Proposal for adding a statement [CACHE_CLOCK_SKEW]. Ensure the site will function acceptably without cache, but explicitly set cache headers with long expiration times to allow for clock or time zone inaccuracy in the client.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-366 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] The Default Delivery Context (section 1.4 in the Last Call Working Draft) provides the assumed minimum-level requirements alluded to. [Commentor reply] no reply from commenter [Comment]

Output: We believe that Web site access through mobile devices would benefit from the provision of some minimum-level requirements on terminal capabilities and browser features. If this cannot be achieved, other work should be referenced.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-367 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] The group took inspiration from WCAG 1.0 (and links back to it), but the accessibility experts are in the WAI groups. As such, we think further work on accessibility in the mobile context is out of our scope. [Commentor reply] no reply from commenter [Comment]

Output: Accessibility should be addressed more specifically, as the mobile Web (and its specific issues) does not seem to be in the scope of the WAI/WCAG guidelines 2.0, currently under updating. The provided cross-referencing is beneficial but it does not provide enough substance.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-368 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] This is out of scope of the current phase of work of the Best Practices, as stated in our scope document: """ As the Mobile Web Initiative is primarily concerned with accessing content that would currently be rendered in a desktop or laptop browser, the BPWG's focus is currently on best practices that are most pertinent to "traditional" browsing. However, in future phases, the group may broaden the scope of its work in order to take into account other content presentation options that may be available on mobile devices - e.g., using the emerging multimodal technologies.""" link [Commentor reply] no reply from commenter [Comment]

Output: Access to the mobile Web through a speech user interface is not covered by the present draft version. We believe it should be addressed (also as there is excellent work in W3C to cross-reference), as it is an important accessibility enabler to young and older users and users with temporary or permanent functional abilities.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-370 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] Setup and configuration is out of scope for the Mobile Web Best Practices which only focus on the delivery of content to Mobile Web devices. [Commentor reply] no reply from commenter [Comment]

Output: Setup and configuration is currently considered by consumers as a major difficulty, when trying to access mobile services and applications. As this document does not address setup and configuration-specific issues and it does not provide such guidelines, it should reference available recommendations and best practices developed in other standard bodies and fora, in order to improve the user experience.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-385 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] The group thinks this topic would be a better fit as part of the techniques, on which we welcome contributions: link [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.2.2.2, How to do it: Provide advice on how to implement device-based wrapping.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-388 Bruno von Niman (ANEC W3C) on behalf of ANEC [Working Group decision] Telling providers to check their error logs is out of scope for this document. [Commentor reply] no reply from commenter [Comment]

Output: Chapter 5.4.13, Error messages: The purpose of error messages should be dual: 1. To provide information to the user; and 2. To provide information to the service provider. The recommendation should cover both aspects.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-358 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We don't have any best practice regarding security, and deploying a secure service on the Web and on mobile devices require much more guidance than simple best practices. As a consequence, the group doesn't feel the document should talk about HTTPS. [Commentor reply] no reply from commenter [Comment]

Output: 3. Security In order to build commercial services on the web, secure connections are necessary. In addition, these are widely implemented already. Is there no requirement to support https connections in the mobile space as a best practice?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-394 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We have added a new best practice on text effects: "[FONTS] Do not rely on support of font related styling." but we think the particular aspect of justification would be better handled by a technique that was started at: link [Commentor reply] yes [Comment]

Output: BP Not covered: 1. Don\'t format text as justified. Text aligned to be justified on both sides is often problematic on the web in general - on mobile devices with a relatively small range of fonts and display options, it seriously reduces legibility of content, often at a cost of some extra processing.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-395 Charles McCathieNevile on behalf of Opera Software [Working Group decision] We think this would be a better fit for a technique rather than a specific best practice. A technique has been started in: link [Commentor reply] yes [Comment]

Output: BP Not covered: 2. Identify word breaks. (This is related to the previous point) Long words which can be broken should include useful information about appropriate points to do so by including a  or similar. display options, it seriously reduces legibility of content, often at a cost of some extra processing.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-267 Ian Jacobs [Working Group decision] Yes and no: yes, HTTP has been added in the default delivery context -- but no, it also belongs here -- as a clarification of what "One Web" means in the context of this document. [Commentor reply] yes [Comment]

Output: "From the perspective of this document this means that services should be available as some variant of HTML over HTTP." Why is the previous statement here? It sounds like it is an assumption about delivery and belongs in the next section.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-285 Ian Jacobs [Working Group decision] * "exploit is the word used in the Device Independence authoring techniques, so we prefer being consistent with them * we think it is important to inform the reader that a good user experience on a mobile devices needs most of the time to be adapated to the device * the techniques document is the place where the reader can learn more on actual ways to learn about device capabilitiles * we have also clarified that we mean more client capabilities than just the ones required to implement the other best practices. [Commentor reply] yes [Comment]

Output: * The word "exploit" seems like it is being used in the French sense of "make use of". I find that in (American) English it carries a negative connotation, as when one "exploits" a security hole. * This statement is so broad that it should be dropped as a best practice note. Instead, I recommend that you create a section a the top of the document that explains what the best practices notes strive to allow people to do. For example: By following the guidance of this document, designers can: * Learn to optimize their designs for delivery to a mobile device by taking full advantage of device capabilities. * .... In short, this best practice note doesn't actually teach me anything useful. Instead, I would like to learn from the document how to do the thing you are talking about. I realize that there is an "abstract" layer and a "techniques" layer and that the abstract point is to take advantage of device capabilities, but I do not believe you have captured the right level in the above note. Instead, if you are thinking of one or two slightly more specific points, I recommend stating those instead of this very general point.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-287 Ian Jacobs [Working Group decision] We think that reasonable is an appropriate word to use. We expect you to try, but don't expect you to break your back. [Commentor reply] yes [Comment]

Output: * Please delete "reasonable" (if you keep this one).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-288 Ian Jacobs [Working Group decision] The "silently recovering from error" point is relevant to user agent requirements which is out of scope. We believe the text already addresses the issues you've raised. [Commentor reply] yes [Comment]

Output: * This can be a dangerous point if not worded carefully. See the relatedprinciple in Webarch: " Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf." I realize that in this context one may not always be interacting directly with the user. But "silently recovering from error" is one of the things that I believe the TAG feels strongly is a bad thing.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-290 Ian Jacobs [Working Group decision] We decided to keep the best practice as is, but we have added text to the default delivery context to mention that no get-out clauses apply in the default delivery context. [Commentor reply] yes [Comment]

Output: * Below you say something more interesting, which I paraphrase as "It's ok to not follow some of the other best practices in this document when you need to work around errors." That's a big gate and you should strive to narrow it. Furthermore, you seem to define conformance below "then content providers must comply..." Does that statement belong in 5.1.3.1 or is it a general statement that belongs in a conformance section?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-291 Ian Jacobs [Working Group decision] We are writing for Web people who may not have realised that there is even more variation in browsers on mobile than there is on the desktop. We do indeed talk about when it is ok not to follow other good practices. [Commentor reply] yes [Comment]

Output: * In my opinion, unless you adopt something more along the lines of what is stated below (a kind of "exception" provision for error conditions) then I think you should delete this one, which, as stated, seems to me to amount to "Do useful things." Again, the note has a very different impact if you are talking about when it's ok to not follow _other_ good practices.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-293 Ian Jacobs [Working Group decision] Generally speaking, we think the imperative voice better convey our message across. For the specific best practice on short URIs, we have added a explanatory words and examples, but have kept the best practice mostly as is. [Commentor reply] yes [Comment]

Output: I realize that you have chosen to write the good practice notes in the imperative voice. I also realize that more information is provided below. However, I think the reader might take away a lot more if the points included more rationale. Any many people (including myself initially) may simply look at the checklist and not take time to read the entire document. For instance: "Short URIs require less effort to type, are less prone to errors when typing them, and are easier to remember." In light of my previous comment about short labels for the statements, you might end up with: [Short URIs Are Friendly] Short URIs require less effort to type, are less prone to errors when typing them, and are easier to remember. This is not much longer than what you have and I think the rationale provided (likely imperfect as proposed) makes the statements much more meaningful.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-302 Ian Jacobs [Working Group decision] Yes, access key support on mobile devices is interoperable among mobile devices and with some desktop implementations. [Commentor reply] yes [Comment]

Output: * Access key support on traditional desktop devices is problematic at best. I do not know about the current state of support from the WCAG WG for access keys (looking in the WCAG 2.0 techniques, I find only a placeholder). Is access key support on mobile devices expected to be more interoperable?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-304 Ian Jacobs [Working Group decision] Most content adaptation systems rely on a database of known devices, with information on which format the device support. If you use such a system, you can annotated only the links you know may not be supported; if you don't, you fallback on the default delivery context, which tells you that only XHTML, JPG and GIF are supported formats (we have amended the text to clarify this). [Commentor reply] yes [Comment]

Output: * I am not sure what you mean by this checkpoint. Through Internet protocols I believe two parties can agree on whether a client supports a particular format available on the server. So do you mean that after such a negotiation, in (adapted) content you serve, you don't have to provide information about the format? I don't think you mean that, in particular because I think that would imply lots of communication about all the links in a document to determine the format of identified resources. * Other than through Internet protocols dynamically, I don't know how you can "know the device supports" a given format unless you are designing in a very closed environment, and I thought that the purpose of these guidelines was to explain how to design effectively in anopenenvironment. * Perhaps you can shorten this, therefore, to something like "To help users reduce the cost of unnecessary downloads, for pieces of content in formats that are not part of the default delivery context, identify the format in links."

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-305 Ian Jacobs [Working Group decision] The document is about delivered content. The inference for a content author is that if they specify an image map, then under certain circumstances this will not work so they should in addition consider an alternative linear arrangement of links. We have shortened the best practice to: "Do not use image maps unless you know the target client supports them effectively." and explained "effectively" in the text with the remainder of the BP as it is now put. We have also included a note to the effect that Image Maps on the Mobile Web are a bad idea. [Commentor reply] yes [Comment]

Output: * I have a similar concern as above about "unless you know." I think that some of these checkpoints make more sense at certain points in a pipeline than at others. For instance, I as a human author probably don't know whether a particular user agent supports this or that. On the other hand, a piece of software that is actively involved in some protocol negotiation and that is doing content adaptation may very well have that information available. But the points are written for multiple audiences and therefore may be confusing. * What is "an available geometric shape"? I think you mean that the format supports the shape.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-307 Ian Jacobs [Working Group decision] We don't mean to be prescriptive about providing a means of helping the user choose, we do mean that there must be a way of telling the user that the page will refresh and of stopping refresh once it has started. Any other consideration is more to do with User Agents, which is out of scope for this document. [Commentor reply] yes [Comment]

Output: * In developing UAAG 1.0, which addresses these topics, we distinguished two concerns (1) the (visual or other sensory) disorientation caused by suddenly opening windows and (2) the change in focus. * I urge you to recast these in terms of thecheckpoints of Guideline 5of the UAAG 1.0 Recommendation. I am happy to discuss them further with you to help answer any questions. * In particular, an important point is that it's ok to do these things when the user says it's ok. * For the point about "unless you have informed the user", that may be locking up the barn after the horse has been stolen. I think it's more important to provide an alternative.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-308 Ian Jacobs [Working Group decision] As explained in the text, we simply mean that you're rarely interested in very detailed and long texts when using the web on a mobile devices, but that you would be generally speaking looking for specific information: "Users in a mobile context are often looking for specific pieces of information, rather than browsing. Content providers should consider the likely context of use of information and, while providing the option to access all information, should offer appropriate information first." [Commentor reply] yes [Comment]

Output: * Please delete this point. I believe the purpose of this entire document is to explain to the reader what it means for content to be suitable for use in a mobile context. Do you mean "suitable" in the sense of "not offensive"? [I don't think you do; just checking.]

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-309 Ian Jacobs [Working Group decision] The point is less to be measurable and more to provide best practice guidance. We are saying in the explanation below that a discursive style is usually less appropriate in the mobile context. It's an important point and we have kept it. [Commentor reply] yes [Comment]

Output: I believe that the above checkpoint no longer exists in WCAG 2.0. I have not followed that debate recently, but I believe that it is so contentious as written (and not verifiable in any obvious way in that formulation) that you will regret having included it. I recommend talking to the WCAG WG about the evolution of their thinking in this area.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-311 Ian Jacobs [Working Group decision] No, as we explain in the text below. The idea is to be mindful of the users' costs etc and not send them advertising and so on that is not relevant to their needs and at their expense. [Commentor reply] yes [Comment]

Output: * How are you defining "what the user has requested?" Does that mean "Implement HTTP GET"?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-313 Ian Jacobs [Working Group decision] We believe the explanation under the best practice makes it clear what we mean by usable size. [Commentor reply] yes [Comment]

Output: * I think the point of this document is to define what "usable" means. Therefore, I don't think you should have a checkpoint that says divide pages into usable pieces. Tell us instead what makes a piece usable.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-319 Ian Jacobs [Working Group decision] We keep this best practice as it is a classical problem in mobile web design and want to insist on this type of practical issue. On the 2nd point, we've included discussion on downloading items (under link_target_format). [Commentor reply] yes [Comment]

Output: * The first sentence of the second point here can be generalized to be "don't do things that the device can't handle." Because I don't think that is known in all cases, I suggest you delete the first sentence. Perhaps rephrase the point in terms of the default delivery context: "Very large or high-resolution graphics are unlikely to achieve their desired goal when rendered on devices with small screens. Avoid them unless there is no other way to provide the information in question." * In some cases, people may wish to download images for viewing on another device (e.g., I store something on my phone then view it on my desktop computer). You may wish to remind the author of that scenario.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-322 Ian Jacobs [Working Group decision] We stick close the WCAG 1.0 - the current W3C Recommendation. [Commentor reply] yes [Comment]

Output: * Please stick very close to WCAG 2.0 on this one as well (I think it is 1.4.3).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-330 Ian Jacobs [Working Group decision] Given that style sheets are part of the default delivery context, this get out clause is needed when a site adapts its content for a device that doesn't support style sheets. [Commentor reply] yes [Comment]

Output: * Please delete "unless the device is known not to support them" in favor of a general section on handling this sort of thing (as described above).

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-331 Ian Jacobs [Working Group decision] It may have been a WCAG point but the mobile interpretation is that some devices don't do style sheets. [Commentor reply] yes [Comment]

Output: * This also comes from WCAG, but I no longer see it in WCAG 2.0. Have you asked them why it was deleted? (I don't see it in the23 Nov 2005 draft)

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-333 Ian Jacobs [Working Group decision] We think these are separate concern that deserve separate contexts. While we may have chosen to organize the best practices in the way you suggest, we haven't found enough benefits behind your proposed re-organization to work on a major re-organization as you suggest. [Commentor reply] yes [Comment]

Output: * Delete this point and add to the list of things to "keep short": markup.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-335 Ian Jacobs [Working Group decision] The point is that: * simple standard content negotiation works poorly in the mobile space. * It may not be possible to do it if you're not using content adaptation. * Respect the markup format the client is asking for. [Commentor reply] yes [Comment]

Output: * Please delete "Where possible" * I suggest merging these two into a single point about following standard protocols for content type negotiation.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-336 Ian Jacobs [Working Group decision] We prefer to have well-focused practical best practices rather than generic lists of items that fit under a same principle. [Commentor reply] yes [Comment]

Output: * "to a minimum" is not well-defined. * Add this to the list of things to keep short.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-340 Ian Jacobs [Working Group decision] We have removed the duplication of "appropriately". We have split the best practices in two to separate the concerns of labeling and positioning, but the proper positioning of labels with forms controls depends too heavily on the context to be specified more precisely. [Commentor reply] yes [Comment]

Output: * Delete "appropriately" (twice) * By "explicitly" do you mean "through markup language features" (such as the "for" attribute in HTML)? * Please be more explicit about what appropriate positioning is rather than make this general statements. Is "before" better than "after" in reading order?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-346 Ville Karinen [Working Group decision] As stated in the "Classes of products" section [2], we're only dealing with "content as it gets delivered to a Web user agent". The way it is authored, adapted or proxied along the delivery chain is thus out of scope for our document, although we briefly explain where content adaptation fits in there [3]. Furthermore, a W3C Technical Report would not be the right place to present vendor-specific solutions for content adaptation. Nevertheless, the Techniques the Working Group has started to work on will present a set of technical advices regarding how to put the best practices in application; as these techniques will be open for contributions, maybe could you then suggest something along the lines of your email message? In the meantime, is there a way to rephrase your comment in a way that would fit in the scope of our best practices? Thank you very much for the time you took to review and comment on the document. Dom 1. link 2. link 3. link [Commentor reply] yes [Comment]

Output: Hello all, i remember there was some discussion whether MWBP promotes One Web or not, but in any case, i guess one goal of the *document* is to explain different kind of approaches or strategies how Web can be served for/accessed via mobile device. "The primary goal is to improve the user experience of the Web when accessed from such devices." However, it seems that the document is concentrating mainly on authoring process. As we can change the existing Web very slowly, it would be informative for non-mobile Web experts to illustrate already existing Web to Mobile adaptation processes, which are based on proxy based conversion. These conversion proxies provide the most widest Web to Mobile resource today. Here are some examples which kind of proxies i mean: WEB TO MOBILE Google's quite new HTML -> XHTML MP converter: MWBP document (WAI) conversion as an example. This converter can handle even forms. (Opera Software MIDP browser based on proxy adaptation. This combination enhances site and browser usability) HTML-> WML conversion (handles forms also) Maybe it should explained more clearly, why WAI guidelines - for example - do not cater mobile devices enough. In my opinion, different kind of Web to Mobile proxies should be studied in the future working groups - especially with content conforming relevant (and existing) WAI guidelines. It is said, that the mobile handset can be the only Web device for many users in the third world. That is why it is important to note, that conversion proxies might be someties the only way to get information from the Web. Kind Regards, Mr. Ville Karinen Student (Agr. & For.)

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-352 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Working Group decision] The Best Practice is about site entry points, to which this technique doesn't really apply. [Commentor reply] no reply from commenter [Comment]

Output: _5.3.1 URLs of Site Entry Points_ Here, if URLs for a menu system running into more than 5 pages can follow a URL syntax containing page numbers such as: link then it becomes easy for the user to navigate between pages, just by changing the page number on the URL, through the bookmark. Of course, if the browsing application itself could provide a page browser using this syntax, the user\'s task of navigating through pages would be much easier

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-353 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Working Group decision] This is a user agent issue and so out of scope. We do recommend use of access keys which can achieve the same goal of easing navigation. [Commentor reply] no reply from commenter [Comment]

Output: _5.3 Navigation and Links _All the URLs for each page, must be listed in the options(or right click) menu, so that if a user he/she wants to go to a URL on the page, he/she just has to scroll through the options(or right click) menu to reach the required URL. then it becomes easy for the user to navigate between pages, just by changing the page number on the URL, through the bookmark. Of course, if the browsing application itself could provide a page browser using this syntax, the user\'s task of navigating through pages would be much easier

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-351 Werner Egipsy Souza (Jataayu Software) on behalf of Jataayu Software [Working Group decision] We think this suggestion would be a good fit for a technique related to this best practice; we welcome techniques contributions in our wiki at: link [Commentor reply] no reply from commenter [Comment]

Output: _5.3.7 Link Target Identification _The cost of following a link,as in the case of articles, should be identified in the number of pages which are required by the article, as is done by the BBC Wap page. Hence we get a link at the bottom of the first page of the article, which says \"_Continued Page 2/4_\". The user is then able to choose whether he/she wants to read a 4 page article, or whether he/she should look for another article.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-398 Zev Blut [Working Group decision] We decided not to include the screen height because: * research showed that even being able to view only a few lines (4) was sufficient for a reasonable user experience * we didn't want to fix the aspect ratio [Commentor reply] no reply from commenter [Comment]

Output: 1.4 Default Delivery Context There is an entry for screen width, but not height. I think that there should be some value for a default screen height.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-399 Zev Blut [Working Group decision] The "back button" is not mandated by any of the specifications that defines the default delivery context, and in particular, there doesn't seem to be any evidence that any device supporting XHTML-basic would feature a back button. As such, we have kept our text regarding the back button as is. [Commentor reply] no reply from commenter [Comment]

Output: 2.2 Input Discusses the potential lack of back button support, but in section 1.4 the default device supports XHTML- Basic. Is it not reasonable that if the default is assuming XHTML-Basic then the target default handsets have back buttons?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-401 Zev Blut [Working Group decision] No specific values have been defined for lengths of URLs because it was felt that specifying precise value might in practice prove too restrictive This BP should be interpreted as meaning if you have the choice between link http://example.com as the access point for your site you should choose the shorter one, which we have tried to clarify through additional examples. [Commentor reply] no reply from commenter [Comment]

Output: What does the group consider a proper range for short URLs?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-403 Zev Blut [Working Group decision] This is a WCAG checkpoint and a fairly common usablity rule. Put the important stuff first. Note that the Best Practices and the mobileOK trustmark, while related, are different and it is not defined yet which best practice will be included in the definition of the trustmark. [Commentor reply] no reply from commenter [Comment]

Output: 5.3.4 Navigation Bars etc. This is a good idea, but it makes me wonder how possible the one web vision becomes. If one wants to create a page that can provide an optimal display, the developer would need to do quite some work or use a powerful platform. I fear that some developers may give up trying to get the mobileOK mark if it becomes too difficult.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-405 Zev Blut [Working Group decision] We have clarified that specifying the intrinsic dimensions of an image allows that the browser doesn't have to re-flow the page in the course of displaying it (re-flowing creates usability problems due to changes of focus, and also may have a bad CPU/battery impact). [Commentor reply] no reply from commenter [Comment]

Output: 5.4.6 Image Size [IMAGES_SPECIFY_SIZE] Are there actual examples where not setting the width and height of an image actually hurts the display of the image by the browser? I am not so sure how necessary this is, especially when considering that providing this information increases the size of the page.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-406 Zev Blut [Working Group decision] Good point but clearly the content author can't do anything about this User Agent deficiency [Commentor reply] no reply from commenter [Comment]

Output: 5.4.13 Error Messages This is also a great idea, but some handsets ignore the developer’s custom HTTP 5xx response and shows a built in error message to the user.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-416 on behalf of I18N WG [Working Group decision] We have removed the section on participants in the mobile value chain altogether since it was not necessary to the comprehension of the document. [Commentor reply] yes [Comment]

Output: Please say about the participants in the mobile value chain s.t. like "these participants are working with multiple languages ...".

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-417 on behalf of I18N WG [Working Group decision] Our position on this is that if we reference other work we do so because of a specific mobile interpretation. As far as we are aware we do not make reference to any internationalisation as we feel that internationalization recommendations "are general to all forms of Web access". Please come back to us if we are mistaken. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 2 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.3 [link] Comment: On scope of MWBP 1.0: Please give internationalization as another example of general good practice which have a specific mobile interpretation.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-418 on behalf of I18N WG [Working Group decision] We do not think that this has a specific mobile interpretation; the section on usability has been removed in any case. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 3 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.3.2 [link] Comment: On aspects of usability: Please mention that proper localization is part of localizability, e.g. in the case of site usability, device usability or browser usability.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-423 on behalf of I18N WG [Working Group decision] Non availability of resources in the language of your choice is not a mobile specific issue. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 8 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 2.4 [link] Comment: Travel related information might not be useful in a mobile context, since there might be no resource for translating. Please mention the need to make it explicit in the content that such resources are missing.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-425 on behalf of I18N WG [Working Group decision] We don't think this has a specific mobile interpetation. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 10 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 2.7 [link] Comment: Your mention the importance of mobile devices for developing countries. Esp. for these countries, internationalization and localization issues are crucial (e.g. support of a font for the script). such requirements should be made explicit in this document.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-426 on behalf of I18N WG [Working Group decision] Yes, it is intended as the document is non normative. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 11 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: You don\'t have any normative references. Is this intended, and if yes, why?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-427 on behalf of I18N WG [Working Group decision] No, as some of the sections are not applicable to some of the best practices. We have clarified that "what to test" is left out on non-testable best practices. [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 12 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: In sec. 4.2, you describe the structure of Best Practice Statements\". Nevertheless, many Best Practice Statements leave parts of this structure out. Will this be changed in a future version of this document?

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-429 on behalf of I18N WG [Working Group decision] We have mentioned "language" as being one of thing worth mentioning as part of the LINK_TARGET_FORMAT: "Links to content that is in a different format or different language to that of the page the link is on (i.e. content that can only be interpreted by other applications or downloads) should be human signposted" [Commentor reply] yes [Comment]

Output: Comment from the i18n review of: link Comment 14 At link Editorial/substantive: S Owner: FS Location in reviewed document: Sec. 5.2.7 [link] Comment: Please mention that if in the content there is a link to something which is not in the same language, it would be good to make it explicit.

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006


Input: [Commentor] LC-432 on behalf of I18N WG [Working Group decision] Recommending that HTTP errors be handled by the device itself would go contrary to the web architecture (e.g. preventing the content provider to give detailed information to the user as to what the error is and what may have caused it). [Commentor reply] no reply from commenter [Comment]

Output: Comment from the i18n review of: link Comment 17 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 5.4.13.2 [link] Comment: \"Please consider proposing that it would help bandwidth to store standard messages in the device itself, rather than download them each time.\"

Disposition of Last Call comments for the Mobile Web Best Practices 1.0 dated January 13 2006