Input: [Commentor] LC-374 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 1.3.3, One Web: With the currently available technologies and implementations (and considering the product generation gaps), it is not always desirable, beneficial nor affordable to consumers to access the same information, provided on the same format, regardless of the access network and device. Although technology will improve continuously, consumer requirements will be strongly influenced by the context of mobile use (on the move, limited screen and keyboard, disturbing environment, et cetera), will not change that radically. Due to the context of mobile use, terminal capability variations, bandwidth issues, access rights and mobile network capabilities, this principle should be reconsidered. Even if it is easier to develop content for one Web, there are specific issues that need to be addressed. Providing a good and affordable mobile Web user experience becomes even more important to roaming consumers (presently, there is no low-cost global roaming tariff plan for mobile data devices). We would like to discuss the approach taken and would appreciate to hear your arguments for the “One Web” approach taken. [Working Group decision] We already address these issues, but we have slightly revised part of the One Web definition to be more explicit and use the word "representation" (as defined in the DI glossary) in the following text: "As discussed in [Scope] One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However it does not mean that exactly the same information is available in exactly the same representations across all devices. This is due to issues such as the context of mobile use, terminal capability variations, bandwidth issues and mobile network capabilities. Furthermore, some services and information are more suitable for and targeted at particular user contexts." We have also added a link to the Thematic Consistency Best Practice, which give more context on this point. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-375 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 1.4, Default Delivery Context: More detailed specifications should be provided. In addition, possible fall-back solutions should be mentioned. [Working Group decision] We have added links to the details of the specifications referenced in the default delivery context. The fall-back solutions belongs in the techniques document. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-384 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 5.2.1, URIs of Site Entry Points: The recommendation should be updated to cover aspects of direct manipulation (clickable) and character entry support. [Working Group decision] We have added a note on non-URI-typing access to a web site: "it is expected that users will prefer to use alternative methods of obtaining URIs when available - such as following a hyperlink (from an e-mail, SMS or other Web page), WAP Push, 2D bar code, color bar code, RFID tag and Bluetooth." [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-387 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 5.2.6.1, What it means: This is a far more complex problem than just the limited keyboard (12-key keypads and soft-and hardware-based keyboards should be covered). In addition, aspects relating to the support, handling, mapping, sorting and transmitting characters should be addressed. [Working Group decision] This is a specific best practice on use of "access keys" whose support is known to be quite uniform across mobile devices. We have added a clarification on the limitations of these accesskeys and the devices keyboards: "When building a list of links use numbered lists and assign access keys appropriately. It is recognized that not all characters can be used as access keys as many mobile devices have a limited keyboard." [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-357 Charles McCathieNevile on behalf of Opera Software [Comment] 2. Colours: There are a number of interpretations of "websafe" colours - please provide a reference that unambiguously states which colours are expected to be available. [Working Group decision] We have added the definition that a Web safe color as one which has Red/Green/Blue components chosen only from the values 0, 51, 102, 153, 204, and 255. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-359 Charles McCathieNevile on behalf of Opera Software [Comment] 4. HTTP It is not clear that any transport protocol is guaranteed on the device. Given the requirements to support the regular web, and in particular such things as 30x HTTP responses, it would be appropriate to specify a level of HTTP support in the default characteristics. mobile space as a best practice? [Working Group decision] We do say in 1.3 "From the perspective of this document this means that services should be available as some variant of HTML over HTTP." but indeed HTTP wasn't part of the default delivery context. We have added HTTP 1.0 as part of the default delivery context. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-360 Charles McCathieNevile on behalf of Opera Software [Comment] 5. Style sheets XHTML Basic does not include any support for internal styles. It makes sense, given the problems of latency that are a key constraint in the mobile space, to mandate support for internal styling, but it is not clear from the current wording what support can be expected (and therefore, as an implementor, what support we are implicitly being required to provide). [Working Group decision] We have clarified the default delivery context, and now it only allows external style sheet as required by XHTML Basic. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-361 Charles McCathieNevile on behalf of Opera Software [Comment] There are many types of content which do not require any adaptation. There is no point in these services determining any kind of context. Further, there is no point in determining context in any circumstances for a service that cannot make use of the information. This is not a best practice in itself, merely a technique that can be used to meet some others. In addition, as has been noted by others, having it appear first gives an impression of a strong bias against the one web goal stated elsewhere. cheers Chaals [Working Group decision] We agreed with this and moved this Best Practice as a technique. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-396 Charles McCathieNevile on behalf of Opera Software [Comment] BP Not covered: 3. Use Device-independent event triggers in HTML, the onmouse* and onkey* triggers are somewhat difficult to trigger from the range of devices available. onclick is generally implemented in such a way that any device can trigger it, and mutation events (form changes, page load, etc) do not rely on a particular user interface anyway. [Working Group decision] We have added the following sentence in the "how to do it" section: If scripting is used, do not use onmouse and onkey triggers, use onclick. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-397 Charles McCathieNevile on behalf of Opera Software [Comment] BP Not covered: 4. Balance page weight and latency In a number of cases it will be appropriate to provide a choice between a large page and the same page broken into appropriate chunks. (Browsers like Opera mini will in any case break a page into appropriate sized pieces for phones that need this done). It can also be important to decide what resources to include externally, and which to include in the page. Use of the data: URI scheme can allow small images to be included inline (as can SVG where supported by the browser), and stylesheets and scripts can likewise be incorporated in the page, reducing latency effects caused by fetching multiple resources, or linked to allow efficiency from decisions on whether to load them and from caching. [Working Group decision] We agree and have added a new best practice to that effect (EXTERNAL_RESOURCES), which combined with the BALANCE Best Practice covers the suggestion. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-408 Charles McCathieNevile on behalf of Opera Software [Comment] The requirement expressed by [CONTEXT] is only necessary for some kinds of sites - it is really a technique that needs to be used to meet some other requirements in certain circumstances. In addition, having it first in the list of best practices suggests that there is a huge amount of work to be done in order to deliver any worthwhile content to the mobile web that is not required on the web in general. This is simply not true as a general statement. cheers Chaals [Working Group decision] The group agreed and decided to drop this as a Best Practice. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-409 Charles McCathieNevile on behalf of Opera Software [Comment] There may be some other exceptions required to this, for borders and margins. These are commonly specified in pixels, and this may be appropriate in a number of cases. cheers Chaals [Working Group decision] We have noted that borders and margins may sometimes usefully be specified in pixels. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-415 Charles McCathieNevile on behalf of Opera Software [Comment] There are some types of image, such as SVG, where a pixel-based size is unnecessary or inappropriate. In such cases it is often appropriate to use CSS to specify width/height rather than HTML attributes. cheers Chaals [Working Group decision] We have clarified that only images with an intrinsic size should have their dimensions specified in the markup. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-345 Dan Connolly [Comment] This draft is better than previous drafts in that it has an explicit "One Web" section. But the first best-practice guideline is still: "[CONTEXT] Take all reasonable steps to find out about the device/browser (client) capabilities, adaptation and other transformation that takes place for any instance of an access to a resource." -- link Guideline #1 should be: design for device-independence. Or something like that. In simple cases, one HTML document should work well across a variety of devices. But even for high-profile sites with dedicated production staff, where server-side content adaptation is worthwhile, designing for device independence is still a good idea; lots of content and navigation should be shared across devices. Ah... 5.2.4 Thematic Consistency of Resource Identified by a URI Much better. How about starting with that one? It's a bit of a mouthful, though. I don't see much justification for "... find out capabilities..." and I notice there's no "what to test" subsection for it. [Working Group decision] Thematic Consistency has been moved as the first Best Practice in the latest draft. Design for device independence, does not have a specific mobile interpretation, it does not appear to be testable and it is hard to know what techniques one would cite to support it, unless it is the totality of the techniques that we suggest in support of the best practices. We've removed the [CONTEXT] Best Practices as it did not appear to fit well with the other best practices, and has been moved as a technique instead. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-344 Elliotte Harold [Comment] Section 5.3.7 states: [BACKGROUND_IMAGE_SUPPORT] Do not use background images unless you know the device supports them. (Normative) I don't see any reasoning in the document to justify this one, and I can't think of any myself. Won;t a device that doesn't support background images simply ignore them without any detrimental effects? I can;t think of any examples in practice where the background image was a critical part of the content. This feels like it would degrade gracefully. At a minimum, I would ask that this normative rule be explained more. But if there's no good explanation for this, then this rule could simply be dropped. [Working Group decision] The group agreed this Best Practice wasn't very relevant and decided to remove it. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-264 Ian Jacobs [Comment] The terms "easily" and "efficiently" are almost unused in the document. In my opinion that do not add much information where they are used and might be safely deleted from this part of the document and from the best practices below. I suspect this entire section could be reduced without significant loss of information to the following: The quality of the user's Web experience via a mobile device depends significantly on the usability of Web sites, of browsers, and of the device itself. Although browser usability (for reading, navigating, and interacting with content) and device usability are important, this document focuses primarily on best practices for improving site usability. [Working Group decision] We agree and we have integrated your suggested rewrite in the section on Phasing, having removed the section on usability as such. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-277 Ian Jacobs [Comment] "As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web will go where you go. No longer will you have to remember to do something on the Web when you get back to your computer. You can do it immediately, within the context that made you want to use the Web in the first place." The previous paragraph needs to be adjusted. The text (which may have come initially from the Communications Team!) suggests that there are two Webs: one fixed and one mobile. That is not a message we want to communicate. The point is that we want one Web and that we want to improve mobile access to it. [Working Group decision] We have changed the term to "Mobile Web access" to clarify that it's not the mobile web but mobile access to the Web. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-283 Ian Jacobs [Comment] This point is problematic on several fronts: * "Reasonable" is not well-defined. That term may work well in some contexts (such as a patent policy, where people are used to it). I think you should avoid it in this document. Alternatively, say once up front in the delivery context section what you mean by "reasonable". * I am not sure who is responsible for carrying out this task. Is this the responsibility of someone who is producing content? It doesn't feel like it. * You say to do this for "any instance of an access." Even when there is caching? It may be that in that case I haven't accessed the resource, but I'm not sure of that, so it may be worth clarifying. * This should not be the first best practice note --- this is about content adaptation. I think it is important to start with the message: Design for one Web! Then, talk about how to improve the user experience above and beyond that. * The statement seems overly general. What about saying something a bit more specific, like "Follow published standards when determining device capabilities for the purpose of content adaptation." [Working Group decision] We agree that this best practice didn't fit very well with the rest of the documents, and was more a general technique than an actual best practice. As such, we have redistributed the text between some other parts of the document as well as in the Techniques. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-289 Ian Jacobs [Comment] * How do you define a "deficient" implementation? It sounds quite subjective to me. Do you mean implementations that do not conform (strictly) to standards? Otherwise how would you classify something as deficient or not? Do you mean "known bugs"? [Working Group decision] We have added a clarification of the intended meaning of deficient: "By deficient we mean non-support of mandatory features of a relevant standard or recommendation and other bugs or errors in implementation." [Commentor reply]

Output: yes

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


Input: [Commentor] LC-297 Ian Jacobs [Comment] * If you really mean "should be enough" then say "Provide between 2-4 links at the top of a given page for navigation to important parts of the page." That seems to me to be more useful than saying "minimal navigation." Find the 80% point, say it, and then let people adapt for other cases as required (and explain to them when they might encounter those cases). * In the same spirit as my comment on the previous point, you might rephrase this as:[Navigation helps in small doses] Providing 2-4 links at the top of a page to important content in the page facilitates navigation. Many more than that hinders navigation. [Working Group decision] We have reworded the explanatory text about navigation bars, noting in particular that the navigation bar shouldn't prevent the user from seeing the core of the content. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-299 Ian Jacobs [Comment] * Does "link on page" mean that it links to something on the current page, or could it also be a link that points to a different page? * I don't know what "balance" means here. I imagine it means "roughly equal to in number," but it may not be about equality. * Does "depth of navigation" mean "to other pages"? * Do you mean something like "Users tend to give up if they have to follow more than 2-3 links in order to find something." * I hoped I would understand this point better by reading the "What it means" text, but the first sentence is confusing: it uses "navigation links" and "navigate multiple links" as though they mean something different, but the phrases are very similar. [Working Group decision] We have substantially reworded the Best Practice on balance to clarify that the balance was between the number of links per pages and the number of pages the user has to download to go to his or her intended result. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-300 Ian Jacobs [Comment] * You refer to "links"; do you mean "what you get when you follow the link?" * I suggest expressing this point in terms of serving roughly equivalent representations rather than in terms of links. * You might want to citeWebarch section 3.5.1, which says "A URI owner SHOULD provide representations of the identified resource consistently and predictably". * Since this is the "One Web" point, I think it belongs at the front of the document. You might want to retitle it "One Web Principle" rather than "Thematic Consistency". * You might want to simplify to "[One Web Principle] Because you never know for sure who will be reading your content (and their device, browser, and human capabilities), you should start by designing for a broad audience, then optimize your content for targetted audiences." [Working Group decision] We have changed the Best Practice to mention URIs instead of links, and the text now refers to the Web Architecture principle. We have not renamed it since the wording "thematic consistency" is about the expected goal not the implied principle. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-303 Ian Jacobs [Comment] * You might want to shorten this and combine it with the next point as follows:[Describe Link Targets] To help users decide whether to follow a given link, provide this information about the target of the link: * What it is, in clear language * How large it is (which may imply a time-consuming download) * The file format (which the user may know is not supported by the device). * I would note that in UAAG 1.0 we require the user agent to provide some of these services so the author doesn't have to; seecheckpoint 10.5. That helps address part of the goal of the following point about "knowing" whether the device supports a given format. [Working Group decision] We have shortened the best practice by moving it in the explanatory text that also has been clarified. We haven't combined it with link_target_format since we want to to be clear on both these points. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-314 Ian Jacobs [Comment] * Delete "if they can be determined". This is an instance of a qualifier that weighs down the point you are making and should be described elsewhere. [Working Group decision] We have removed the conditional statement since it is indeed taken into account by the default delivery context. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-315 Ian Jacobs [Comment] * What do you mean by "direction"? Do you mean "down, not up"? Do you mean "Don't make people scroll horizontally? * Delete "unless secondary scrolling cannot be avoided." In general, delete "except where impossible" as I've mentioned above. [Working Group decision] We have added the following explanatory paragraph: "The page should lay out so that simple repeated scrolling in the same direction (axis) allows the user to experience all its content." We have kept the opt out clause, with explanations on cases where this might be needed (e.g. a map). [Commentor reply]

Output: yes

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


Input: [Commentor] LC-316 Ian Jacobs [Comment] * I do not understand how this point differs from the previous one. [Working Group decision] We agreed and removed the second best practice on scrolling. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-321 Ian Jacobs [Comment] * This is another instance of the general point "Don't do X". I think you should regroup all of those points in one and relate them to the default delivery context. [Working Group decision] The Best Practice was dropped, so this comment doesn't apply anymore. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-325 Ian Jacobs [Comment] * Please stick very close to WCAG 2.0 on this one as well. [Working Group decision] WCAG 2.0 is still a Working Draft, so the group has chosen to align with WCAG 1.0 which is a Recommendation. In particular, we have syncronized the text of this BP with the WCAG 1.0 guideline. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-334 Ian Jacobs [Comment] * Perhaps you can be more specific about HTTP (is it "accept" headers?) since that is an explicit assumption above. * The user may wish to receive content even if its device does not directly support it (e.g., to save and use it later). Please make it clear that the user can, on demand, request content that is not supported by software on the client. [Working Group decision] We have clarified that a user should always be able to at least download items (in LINK_TARGET_FORMAT), no matter the level of support his or her device has for the said format. We have also mentioned the various ways one can determine which format is supported or not. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-402 Zev Blut [Comment] 5.2.2 Navigation Bar I am not quite certain if having a navigation bar on the top page and having the navigation links on the same line is really a best practice that I agree with. Perhaps providing a definition or example of what a navigation bar is for a mobile site would help those who disagree with this. In many cases having navigation items like home and back links of the top of the page distracts the user from viewing the content that the user is currently looking for. The user must skip through a number of links before getting the view the content, which is not desirable in some cases. In such an example I think that having the navigation bar at the bottom is preferable when the user has found the searched for content. Although, in the case that the current page is not what the user is looking for having the navigation at the top is certainly better, for the quickness of getting out of the page. Perhaps this section could use a bit more explanation. This may be a difference of interpretation depending upon the if the handsets force the user to traverse each link or can skip links that are on the same line. [Working Group decision] We have clarified that only a few links should be placed at the top of the page, leaving the rest of the navigation links to the bottom, and added a note to the effect that user should be able to see the content of the page without scrolling. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-404 Zev Blut [Comment] 5.4.5 Non Text Items The way that current i-mode handsets deal with handsets that cannot support the object tag differs from this recommendation. This may make many i-mode sites break the best practices rules. You can refer to the following link for more detail: link [Working Group decision] The DoCoMo way of doing this is in the spirit of this BP i.e. the user will receive an appropriate message if his or her phone does not support the OBJECT tag, but we agree that the Best Practice was a worded a bit too restrictively. We have changed the wording of the Best Practice to: [OBJECTS_OR_SCRIPTS] Do not rely on embedded objects and/or scripts. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-407 Zev Blut [Comment] 5.4.14 Cookies Does this prevent systems that make use of Set-Cookie to determine if the phone supports cookies from getting the mobileOK mark? [Working Group decision] We have clarified that we really meant "do not rely on cookies being available"; i.e. it is indeed fine to make use of Set-Cookie to determine if the phone support cookies. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-419 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 4 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.4 [link] Comment: Please point to the specification XHTML Basic [link] . [Working Group decision] We have added a reference to XHTML Basic. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-420 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 5 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 1.6 [link] Comment: This section seems to fit better at the beginning of the document. [Working Group decision] We agreed and moved it to section 1.2 and move the other sections down correspodingly. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-424 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 9 At link Editorial/substantive: E Owner: FS Location in reviewed document: Sec. 2.7 [link] Comment: Please correct the line break before \"communications.\". [Working Group decision] We have removed the spurrious line break. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-428 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 13 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: CDFWG is in the references, but not in the text. [Working Group decision] This was a Dangling Reference from an earlier version which did make reference to CDF. The reference has been removed. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-430 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 15 At link Editorial/substantive: E Owner: FS Location in reviewed document: General Comment: UAProf is mentioned several times in the text, but not in the references. We guess you mean UAProf profile repository [link] . [Working Group decision] Thanks for pointing this out. We have included a reference to the OMA documentation on UAPROF. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-431 on behalf of I18N WG [Comment] Comment from the i18n review of: link Comment 16 At link Editorial/substantive: E Owner: RI Location in reviewed document: Sec. 5.4.12 [link] Comment: Please refer to the tutorial on Character sets & encoding in XHTML, HTML and CSS [link] , and the QA on Setting encoding in web authoring applications [link] , instead of the \"HTTP charset\" document. [Working Group decision] We have added references to these documents. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-438 Al Gilman on behalf of WAI [Comment] section 3.1 which ever content adaptation implementation model is used, the model must retain necessary accessibility information (alt, label, etc.) and convey that information to the mobile device and the user. [Working Group decision] We have added the following note to the section on content adaptation: "Whatever the adaptation model at work, the process of adaptation should not diminish accessibility." [Commentor reply]

Output: yes

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


Input: [Commentor] LC-371 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 1.1, Purpose of the Document: The purpose should stretch beyond “…to promote more effective delivery…” and provide design guidelines applicable to the usability and accessibility of the mobile Web or, at least, specifics of interacting with mobile Web sites. [Working Group decision] We agree and have changed the text to read "to improve the user experience of the Web on mobile devices." [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-380 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 2.7, Advantages: “Connected” should be added to the popularity reasons. [Working Group decision] We have added that aspect to the list of advantages. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-383 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 5.1.4, Testing: Update the recommendation to “…devices and provided specific software versions…”. [Working Group decision] We have added the suggested mention of software versions. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-386 Bruno von Niman (ANEC W3C) on behalf of ANEC [Comment] Chapter 5.2.4.1, What it means: Connectivity and download speed issues should be mentioned. [Working Group decision] We've added a note to the sentence "irrespective of differences in presentation capabilities": "and access mechanism." [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-342 Charles McCathieNevile on behalf of Opera Software [Comment] This Best Practice should require that content not rely on scripting, unless the delivery context is known to support them. Some mobile browsers allow the user to turn off javascript (handy where you are trying to save battery). It should also lean away from using script unless necessary - it is one of the more battery-intensive ways to do most things. It should also cross-reference requirements on page size, and a best practice on page size vs latency (see Opera's comment on "missing points") cheers Chaals [Working Group decision] We have updated the document to clarify that content should not rely on scripting, and avoid using scripting as much as possible due to battery considerations. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-356 Charles McCathieNevile on behalf of Opera Software [Comment] 1. Meaning The text does not make it clear whether the characteristics are minimum specifications, or actual specifications that should be assumed. For example should a developer assume in the absence of other information that the width of a device is 120 px, or that there may be no more than 120 px width available. [Working Group decision] We have qualified the screen width as being a minimum. [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-410 Charles McCathieNevile on behalf of Opera Software [Comment] [This is a comment on Mobile Best Practices, but cc'ed to WCAG as a comment for them on text the are currently using] The wording "Ensure that perceivable structures within the content can be programatically determined", copied verbatim from the WCAG working draft, has proven to be very difficult to understand for the majority of the developers I have ased to comment on this draft (which is only a couple of dozen). Perhaps something more straightforward, like "use markup, properly" is simpler for a title, with the current title moved into the "what it means" session as a couple of sentences. cheers chaals [Working Group decision] We have changed the wording to: "Use features of the markup language to indicate logical document structure." [Commentor reply]

Output: no reply from commenter

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


Input: [Commentor] LC-411 Charles McCathieNevile on behalf of Opera Software [Comment] Testing for the absence of tabindex, and the absence of complex layouts (absolute positioning, etc) should also be enough. cheers Chaals [Working Group decision] We have reworded the "how to test" section accordingly. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-412 Charles McCathieNevile on behalf of Opera Software [Comment] Another test for this is to see if there is rendered content that is not inside a table - if there is none, it is quite likely that tables are being used for layout. (Even more so if there is no caption or summary element on the outermost table). cheers Chaals [Working Group decision] We have added a test along these lines in the "what to test" section. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-413 Charles McCathieNevile on behalf of Opera Software [Comment] Rather than the negative "Do not take a least common denominator approach", this could be better phrased as "... to maximise usability" or something similar. It needs to be clear that while thispractise does authorise sending enhanced content to users who are clearly able to make use of it, it does not authorise breaking the "one web" principle and simply ignoring users (provided they have at least a "baseline-capable" device). cheers Chaals [Working Group decision] We have changed the wording to read: "[CAPABILITIES] Exploit device capabilities to provide an enhanced user experience.". [Commentor reply]

Output: yes

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


Input: [Commentor] LC-258 Ian Jacobs [Comment] Please start early with the "One Web" message, for example by adding something like this to the end of the preceding sentence: "An important Web design principle (discussed, for example, insection 4.3of "Architecture of the World Wide Web") is to design content that is flexible enough to enable a valuable user experience for a variety of devices. This document explains how to design for "one Web" while also optimizing for the mobile experience." [Working Group decision] We have elevated THEMATIC CONSISTENCY to the most prominent in the document and hence have given it the precedence it deserves. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-259 Ian Jacobs [Comment] What does "in context" mean? [Working Group decision] We have removed the incriminated sentence. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-260 Ian Jacobs [Comment] I suggest merging the previous two paragraphs; I otherwise was unsure about the mobileOK trustmark in the paragraph where it was introduced. [Working Group decision] The paragraph boundary was indeed unnecessary and we have merged the two paragraphs accordingly. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-263 Ian Jacobs [Comment] The first reference to "phase of work" is confusing. Does it mean "phase of this WG?" or "phase of this document"? Please clarify. It may be described in [Scope], but I think you need to provide a short summary of what "phasing" means or of what the phases are. [Working Group decision] We have expanded the consideration on phasing and have added a mention of the expected longevity of the document. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-265 Ian Jacobs [Comment] What does "perhaps" mean here? [Working Group decision] We have replaced perhaps by "for example" and "for instance". [Commentor reply]

Output: yes

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


Input: [Commentor] LC-266 Ian Jacobs [Comment] The document says "as far as is possible." When is it not possible? I think you can safely say that it is considered "best practice not to exclude access." You don't have to add disclaimers. If there are specific cases that you are thinking of (e.g., there may be privacy or security reasons), please call them out rather than say "as far as possible." I make similar comments below. [Working Group decision] We have reworded this to read "not to exclude access from any particular class of device, except where this is necessary because of device limitations." [Commentor reply]

Output: yes

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


Input: [Commentor] LC-268 Ian Jacobs [Comment] The first sentence confused me because the title of the section includes "context" and the first sentence includes "content". I thought it was a mistake at first. It might help to say very quickly that there are two things discussed; context and content. [Working Group decision] We have reworded the introduction to the default delivery context section and think it sets now more clearly what concerns the content and what concerns the device/context. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-270 Ian Jacobs [Comment] I find "pointer to" to be very informal. [Working Group decision] The incriminated text has been removed. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-271 Ian Jacobs [Comment] I think "Appendices" is more common than "Annexes" in W3C specs. [Working Group decision] We have replaced "annexes" by "appendices". [Commentor reply]

Output: yes

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


Input: [Commentor] LC-273 Ian Jacobs [Comment] What is an "entertainment application"? Do you mean a game? [Working Group decision] We have reworeded the paragraph to read: "Equally, mobile users are typically less interested in lengthy documents or in browsing. The ergonomics of the device are frequently unsuitable for reading lengthy documents, and users will often only access such information from mobile devices as a last resort, because more convenient access is not available." [Commentor reply]

Output: yes

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


Input: [Commentor] LC-276 Ian Jacobs [Comment] I am not sure what implicit user identification means. Also, it sounds ominous to me, and therefore I'm not convinced it is always an "advantage". Do you plan to address privacy concerns? [Working Group decision] We have removed the reference to this aspect, as we agreed it's not always something you get with mobile access. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-278 Ian Jacobs [Comment] See also previous comment on "phase"; I suggest a link to where the term is first explained. [Working Group decision] We have added link to the discussion on the phasing of our work. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-279 Ian Jacobs [Comment] I think you can cut this entire section (4.1). The explanations do not add more than the text in the . I find they are not necessary anyway to my understanding of the document. [Working Group decision] We have removed the section accordingly. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-280 Ian Jacobs [Comment] There is an editorial problem around "by using URI reference composed" in the previous paragraph. Also, I think you should use "URI: instead of "URI Reference". [Working Group decision] We have removed the wording altogether and have instead created a list of the best practices with the links pointing to the relevant URIs. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-281 Ian Jacobs [Comment] In both WAI Guidelines and theWebarchdocuments I worked on, we found it useful to provide short mnemonic labels for best practices and similar statements. In Webarch, we created a navigation bar to the statements at the top of the document (after the TOC), so people could access them individually and rapidly. [Working Group decision] We have resolved to keep the labels the same, but we have added a table of BPs. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-296 Ian Jacobs [Comment] You say "how to do it" and then don't say how to do it --- you just say "don't make the user do X." Instead, what about talking about how to configure the server to do the right thing for index.html or similar? [Working Group decision] We agreed with the weakness of the section and have added more detailed advice on shortening URIs. Meanwhile, we keep the specifics of configuring a server to that end for the techniques. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-298 Ian Jacobs [Comment] If "The device will take care of wrapping" is true enough to be stated as you have done, then add a best practice note: "Do not put explicit line breaks in navigation bars because browsers on mobile devices will do the right thing." or something more eloquent. [Working Group decision] We have removed the incriminated sentence. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-301 Ian Jacobs [Comment] * Because the word "use" suggests "user", I recommend making this sound a bit more clearly like it is intended for authors. "Provide navigation mechanisms that are consistent across pages." [If you mean something else, then that's another issue.] [Working Group decision] We have replaced "use" with "provide" as suggested. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-317 Ian Jacobs [Comment] * The key [CENTRAL_MEANING] is less communicative than "Frontload important information". See my earlier comment about using short labels that capture the essence (even if imperfectly) of the point. [Working Group decision] This one is meant to be about not putting banner ads, and other clutter in advance of the text. The "frontloading" aspect is discussed under [CLARITY]; we have added a link from one to the other to highlight their relationship. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-318 Ian Jacobs [Comment] The first sentence of the previous paragraph is more communicative than 5.2.2 as written. [Working Group decision] We have referenced the text of this Best Practice from the text of the best practice on navigation bar, with clarification on why it is important to keep navigation bars short in the mobile context. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-327 Ian Jacobs [Comment] * Why do you use "Always" here and not in other points? I recommend deleting "Always" for the same reason I suggest deleting "when possible". * What about markup languages that don't support this? [Working Group decision] We have removed the word "always" and have instead clarified in the explanatory text that this is an exception to the best practices on relative measures. All the markup languages in scope for this document (XHTML Basic and above) have support for this feature. [Commentor reply]

Output: yes

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


Input: [Commentor] LC-332 Ian Jacobs [Comment] * Delete "as possible", and * Add this to the list of things to "keep short" [Working Group decision] We have removed "as possible". [Commentor reply]

Output: yes

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


Input: [Commentor] LC-339 Ian Jacobs [Comment] * Perhaps "tab order" is the term of art. Do people use a tab key on mobile devices? In UAAG 1.0 we talk about "sequential navigation" (distinguished from "direct navigation" through keyboard shortcuts). [Working Group decision] We have removed the word "tab" and used a more generic wording about navigation order. [Commentor reply]

Output: yes

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


Input: [Expected Values] annotations [Description]

Output: The work includes annotations from the author, instructor and/or others.


Input: [Expected Values] bookmarks [Description]

Output: The work includes bookmarks to facilitate navigation to key points.


Input: [Expected Values] index [Description]

Output: The work includes an index to the content.


Input: [Expected Values] printPageNumbers [Description]

Output: The work includes equivalent print page numbers. This setting is most commonly used with ebooks for which there is a print equivalent.


Input: [Expected Values] readingOrder [Description]

Output: The reading order of the content is clearly defined in the markup (e.g., figures, sidebars and other secondary content has been marked up to allow it to be skipped automatically and/or manually escaped from.


Input: [Expected Values] structuralNavigation [Description]

Output: The use of headings in the work fully and accurately reflects the document hierarchy, allowing navigation by assistive technologies.


Input: [Expected Values] taggedPDF [Description]

Output: The structures in a PDF have been tagged to improve the navigation of the content.


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

Output: alignment

Table 2-3. EXI Options


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

Output: compression

Table 2-3. EXI Options


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

Output: fragment

Table 2-3. EXI Options


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

Output: preserve

Table 2-3. EXI Options


Input: [Description] Identifies the schema used during encoding [EXI Option]

Output: schemaID

Table 2-3. EXI Options


Input: [Description] Identifies any pluggable CODECs used to encode the body [EXI Option]

Output: codecMap

Table 2-3. EXI Options


Input: [Description] Specifies the block size used for EXI compression [EXI Option]

Output: blockSize

Table 2-3. EXI Options


Input: [Description] User defined headers may be added [EXI Option]

Output: [user defined]

Table 2-3. EXI Options


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

Output: alignment

EXI Options in Options Document


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

Output: compression

EXI Options in Options Document


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

Output: strict

EXI Options in Options Document


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

Output: fragment

EXI Options in Options Document


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

Output: preserve

EXI Options in Options Document


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

Output: selfContained

EXI Options in Options Document


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

Output: schemaId

EXI Options in Options Document


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

Output: datatypeRepresentationMap

EXI Options in Options Document


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

Output: blockSize

EXI Options in Options Document


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

Output: valueMaxLength

EXI Options in Options Document


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

Output: valuePartitionCapacity

EXI Options in Options Document


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

Output: [user defined meta-data]

EXI Options in Options Document


Input: [Function] op:to [Meaning]

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

XQuery 1.0 and XPath 2.0 Functions and Operators -- Review Version


Input: [Function] fn:id [Meaning]

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

XQuery 1.0 and XPath 2.0 Functions and Operators -- Review Version


Input: [Function] fn:idref [Meaning]

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

XQuery 1.0 and XPath 2.0 Functions and Operators -- Review Version


Input: [Function] fn:doc [Meaning]

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

XQuery 1.0 and XPath 2.0 Functions and Operators -- Review Version


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

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

XQuery 1.0 and XPath 2.0 Functions and Operators -- Review Version


Input: [Function] fn:collection [Meaning]

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

XQuery 1.0 and XPath 2.0 Functions and Operators -- Review Version


Input: [Type] NotFoundError [Message (Optional)]

Output: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened.


Input: [Type] InvalidStateError [Message (Optional)]

Output: An operation was called on an object on which it is not allowed or at a time when it is not allowed. Also occurs if a request is made on a source object that has been deleted or removed. Use TransactionInactiveError or ReadOnlyError when possible, as they are more specific variations of InvalidStateError.


Input: [Type] InvalidAccessError [Message (Optional)]

Output: An invalid operation was performed on an object. For example transaction creation attempt was made, but an empty scope was provided.


Input: [Type] AbortError [Message (Optional)]

Output: A request was aborted, for example through a call to IDBTransaction.abort.


Input: [Type] TimeoutError [Message (Optional)]

Output: A lock for the transaction could not be obtained in a reasonable time.


Input: [Type] QuotaExceededError [Message (Optional)]

Output: The operation failed because there was not enough remaining storage space, or the storage quota was reached and the user declined to give more space to the database.


Input: [Type] SyntaxError [Message (Optional)]

Output: The keypath argument contains an invalid key path.


Input: [Type] DataCloneError [Message (Optional)]

Output: The data being stored could not be cloned by the internal structured cloning algorithm.


Input: [Property] address [Expected Type] PostalAddress [Description]

Output: Physical address of the item.


Input: [Property] aggregateRating [Expected Type] aggregateRating [Description]

Output: The overall rating, based on a collection of reviews or ratings, of the item.


Input: [Property] geo [Expected Type] GeoCoordinates or GeoShape [Description]

Output: The geo coordinates of the place.


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

Output: A URL to a map of the place.


Input: [Property] photos [Expected Type] ImageObject or Photograph [Description]

Output: Photographs of this place


Input: [Property] reviews [Expected Type] Review [Description]

Output: Review of the item


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

Output: The telephone number.


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

Output: lexical

Static Context Components


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

Output: lexical

Static Context Components


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

Output: lexical

Static Context Components


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

Output: lexical

Static Context Components


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

Output: module

Static Context Components


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

Output: lexical

Static Context Components


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

Output: module

Static Context Components


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

Output: lexical

Static Context Components


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

Output: lexical

Static Context Components


Input: [0] The cells in [1] this table [2]

Output: should go


Input: [0] green when [1] you hover [2]

Output: the pointing


Input: [0] The rows in [1] this table [2]

Output: should go


Input: [0] dark green [1] when the [2]

Output: pointing device


Input: [0] is over the [1] five pixel [2]

Output: border spacing


Input: [0] Including here, [2]

Output: blank cells.


Input: [Description] The work includes annotations from the author, instructor and/or others. [Expected Values]

Output: annotations


Input: [Description] The work includes bookmarks to facilitate navigation to key points. [Expected Values]

Output: bookmarks


Input: [Description] The work includes an index to the content. [Expected Values]

Output: index


Input: [Description] The work includes equivalent print page numbers. This setting is most commonly used with ebooks for which there is a print equivalent. [Expected Values]

Output: printPageNumbers


Input: [Description] The reading order of the content is clearly defined in the markup (e.g., figures, sidebars and other secondary content has been marked up to allow it to be skipped automatically and/or manually escaped from. [Expected Values]

Output: readingOrder


Input: [Description] The use of headings in the work fully and accurately reflects the document hierarchy, allowing navigation by assistive technologies. [Expected Values]

Output: structuralNavigation


Input: [Description] The structures in a PDF have been tagged to improve the navigation of the content. [Expected Values]

Output: taggedPDF


Input: [event name] received [event type] MessagingEvent [short description] handles received messages [event handler]

Output: onreceived


Input: [event name] sent [event type] MessagingEvent [short description] handles sent messages [event handler]

Output: onsent


Input: [event name] deliverysuccess [event type] DeliveryReportEvent [short description] handles successful delivery reports [event handler]

Output: ondeliverysuccess


Input: [event name] deliveryerror [event type] DeliveryReportEvent [short description] handles failure delivery reports [event handler]

Output: ondeliveryerror


Input: [event name] serviceadded [event type] ServiceChangeEvent [short description] handle new messaging services [event handler]

Output: onserviceadded


Input: [event name] serviceremoved [event type] ServiceChangeEvent [short description] handle disabled messaging services [event handler]

Output: onserviceremoved


Input: [Status] Proposal [Summary] Proposal for new Audiobook Type and abridged property for Book. [Vocab] Audiobook subtype of Book and of AudioObject, adds readBy property [Topic]

Output: Audiobook

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


Input: [Status] Proposal [Summary] Proposal for new Collection Type and part properties for CreativeWork. [Vocab] Collection subtype of CreativeWork hasPart & isPartOf properties for CreativeWork [Topic]

Output: Collection

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


Input: [Status] Proposal [Summary] Extension for describing accessibility properties of a CreativeWork. [Vocab] Add accessMode, mediaFeature, hasAdapation, isAdaptationof, ATCompatible and accessHazard to creativeWork. Also add accessAPI and controlFlexibility to softwareApplication. Goal is to allow accessible content to be discoverable. [Comments] Draft V.6 published to elicit feedback, comments tracked on wiki page. [Topic]

Output: Accessibility

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


Input: [Status] Accepted [Summary] Add one property 'department' to Organization, to allow local businesses to describe their depts (e.g. opening hours) in detail. Final discussion on whether to call it subOrganizationOf instead. [Vocab] department property (range and domain both Organization) [Comments] Proposal very greatly simplified after WebSchemas discussion. [Topic]

Output: Add Organization department property

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


Input: [Status] Proposal [Summary] Add one type, 'QuotationSchema', a kind of CreativeWork, alongside some supporting properties. [Vocab] Quotation, spokenByCharacter, incorrectlyAttributedTo, aboutEvent, fromEvent, addressee. [Comments] Several other requirements are addressed by re-use of existing properties. Debate about whether incorrectlyAttributedTo is worthwhile. Some details to finalise. [Topic]

Output: Add Quotation type

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


Input: [Status] Proposal [Summary] Add handlers and potential actions to Action type. [Vocab] See full entry and proposal for details. [Comments] The schema.org team solicit comments on this draft via public-vocabs@w3.org. [Topic]

Output: Actions in Schema.org (part 2)

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


Input: [Status] Proposal [Summary] "While schema.org already supports marking up offers to sell products (pre-transaction), it does not currently provide schema for the common kinds of confirmations and notifications around orders (post-transaction)". [Vocab] Adds classes OrderStatus, Order, DeliveryMethod plus associated properties. [Comments] Complements Actions proposal, but independent. [Topic]

Output: Orders in Schema.org

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


Input: [Status] Proposal [Summary] This proposal includes new types for describing reservations and tickets [Vocab] Adds classes Reservation, ReservationStatus, ProgramMembership, Flight, TrainTrip, TrainReservation, FoodEstablishmentReservation, FlightReservation, EventReservation, ReservationPackage, BusReservation, BusTrip, RentalCarReservation, RentalCar, Car, LodgingReservation plus associated properties. [Comments] Complements Actions proposal, but independent. [Topic]

Output: Reservations in Schema.org

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


Input: [Status] Proposal [Summary] This proposal adds a single new type, EmailMessage [Vocab] EmailMessage is a CreativeWork representing email messages, just as WebPage already represents Web pages. [Comments] No properties currently defined; proposals welcomed. [Topic]

Output: EmailMessage type

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


Input: [Status] Proposal [Summary] Describing public civic services [Vocab] A proposal extending schema.org to cover various kinds of civic services. [Comments] GovernmentService, several kinds of CivicPermit, CivicAudience, BusinessAudience; various properties [Topic]

Output: Civic Services

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


Input: [Status] Accepted [Summary] This proposal adds a single new type, WorkersUnion, addressing issue 17 in the WebSchemas tracker. [Vocab] "A Workers Union (...) is an organization that promotes the interests of its worker members by collectively bargaining with management, organizing, and political lobbying."" [Comments] One type, see draft schema. [Topic]

Output: Workers Union type

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


Input: [Status] Accepted; published in next version [Summary] Proposes modest changes and additions to support TV and radio (from EBU and BBC). [Vocab] Adds Series, Season, Episode under CreativeWork. Existing TVSeries, TVSeason, TVEpisode under Series/Season/Episode. Adds RadioSeries/RadioSeason/RadioEpisode alongside. Adds Programme/Clip for programmes other than episodes. Adds description of a service with Service/PublicationEvent for broadcast, streaming, VoD, etc. [Comments] See also background notes and [[1]]. Draft initially from EBU/BBC/NoTube discussions. Nearby vocab: see VideoObject, AudioObject; Movie. Event re scheduling. See also UserPlays, a kind of UserInteraction. Comics and TV/Radio also share a concern for describing fictional characters and narratives. [Topic]

Output: TV and Radio proposal

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


Input: [Status] Some initial discussions. [Summary] Several parties are working towards a Sports Vocabulary proposal. See query from Paul Kelly (SportsML), Microdata + Sports Stats post describing earlier ESPN/Google collaboration, and the Sports Ontology used by BBC, Press Association and others. See also sports-schema-collab mailing list. [Vocab] Several sources including a full draft from the ESPN+Google work. Needs summary here. [Comments] March 2nd - posted writeup of the ESPN/Google Microdata vocabulary; next is discussion on finding common basic sports vocab for schema.org. [Topic]

Output: Sports

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


Input: [Status] Discussing Proposals [Summary] Proposal from Marvel (see examples). [Vocab] Adds PeriodicalSeries (under Intangible(?)), PeriodicalIssue (under CreativeWork), Comic Issue (under PeriodicalIssue), GraphicNovel (under Book). Approx 6-9 properties for each of these classes. [Comments] Generally well received and specified, but some detailed discussion re fine-grain detail of comics (imprint, page count etc.). Can those properties be shared with Book/numberOfPages, or ScholarlyArticle? Should PeriodicalSeries be intangible? [Topic]

Output: Comics and Serials

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


Input: [Status] Hopefully Final Proposal - please review [Summary] Proposes some modifications to Event based on deployment experience. [Vocab] Adds eventStatus, previousStartDate, previousEndDate; eventCategory; makes startDate/endDate repeatable. Encourages use of 'url' from Thing. [Comments] Fairly modest proposals based on implementor feedback. May2013 update addresses the last open issue on repeating events. [Topic]

Output: Event schema update

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


Input: [Status] Proposal [Summary] The historical-data.org site proposes some extensions to schema.org to address historical and genealogical (family history) scenarios. [Vocab] Adds HistoricalRecord, HistoricalEvent (subclass of Event), overrides attendees, subEvents, superEvent to point to HistoricalEvent. [Comments] There is an associated implementation, github repository, and blog. [Topic]

Output: Historical Data proposal

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


Input: [Status] Proposal [Summary] A schema extension for describing biological databases, Sagace. [Vocab] Adds a class 'BiologicalDatabaseEntry' as a kind of CreativeWork, introducing 'entryID', 'isEntryOf', 'taxonID'. Adds 'BiologicalDatabase' also subclass of CreativeWork, with no special properties. Both also use 'breadcrumb' from WebPage. [Comments] Others have also mentioned interest in adding some notion of species. [Topic]

Output: Biological Databases

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


Input: [Status] Proposal [Summary] A proposal resolving current problems handling breadcrumbs. [Vocab] Adds Breadcrumb type with child property and supposes to use this class on breadcrumb property of a WebPage. An important schema, but needs attention. See discussion on using literal values. [Topic]

Output: Breadcrumbs

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


Input: [Status] Proposal [Summary] A proposal extending schema.org for describing online discussion forums and message boards. [Vocab] Adds attachmentURL, contributorType, discussionState, interestedUsers, postCount, postType, votedHelpful. [Comments] Addition candidate [Topic]

Output: Discussion

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


Input: [Status] Proposal [Summary] A proposal extending schema.org for describing Innovation and related concepts. Discussion found here: [2] [Vocab] Covers concepts and terms such as Need, Benefit, Usage, Disruption, Innovator, Innovation, Embodiment, to name a few. See [3] for complete list of terms. [Comments] Addition candidate [Topic]

Output: Innovation

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


Input: [Status] Proposal [Summary] Add a dissolutionDate property to Organization. [Topic]

Output: dissolutionDate

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


Input: [Topic]

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


Input: [Status] How far along [Summary] Summary of contribution. [Vocab] Overview of new terms [Comments] Comments on status, particularly regarding integration, overlaps and open issues. [Topic]

Output: Proposal name

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


Input: [Name] boxdl [Unicode] U+2510 [Description] lower left quadrant [Unicode Name]

Output: BOX DRAWINGS LIGHT DOWN AND LEFT


Input: [Name] boxdL [Unicode] U+2555 [Description] lower left quadrant [Unicode Name]

Output: BOX DRAWINGS DOWN SINGLE AND LEFT DOUBLE


Input: [Name] boxDl [Unicode] U+2556 [Description] lower left quadrant [Unicode Name]

Output: BOX DRAWINGS DOWN DOUBLE AND LEFT SINGLE


Input: [Name] boxDL [Unicode] U+2557 [Description] lower left quadrant [Unicode Name]

Output: BOX DRAWINGS DOUBLE DOWN AND LEFT


Input: [Name] boxdr [Unicode] U+250C [Description] lower right quadrant [Unicode Name]

Output: BOX DRAWINGS LIGHT DOWN AND RIGHT


Input: [Name] boxdR [Unicode] U+2552 [Description] lower right quadrant [Unicode Name]

Output: BOX DRAWINGS DOWN SINGLE AND RIGHT DOUBLE


Input: [Name] boxDr [Unicode] U+2553 [Description] lower right quadrant [Unicode Name]

Output: BOX DRAWINGS DOWN DOUBLE AND RIGHT SINGLE


Input: [Name] boxDR [Unicode] U+2554 [Description] lower right quadrant [Unicode Name]

Output: BOX DRAWINGS DOUBLE DOWN AND RIGHT


Input: [Name] boxh [Unicode] U+2500 [Description] horizontal line [Aliases] HorizontalLine [Unicode Name]

Output: BOX DRAWINGS LIGHT HORIZONTAL


Input: [Name] boxH [Unicode] U+2550 [Description] horizontal line [Unicode Name]

Output: BOX DRAWINGS DOUBLE HORIZONTAL


Input: [Name] boxhd [Unicode] U+252C [Description] lower left and right quadrants [Unicode Name]

Output: BOX DRAWINGS LIGHT DOWN AND HORIZONTAL


Input: [Name] boxhD [Unicode] U+2565 [Description] lower left and right quadrants [Unicode Name]

Output: BOX DRAWINGS DOWN DOUBLE AND HORIZONTAL SINGLE


Input: [Name] boxHd [Unicode] U+2564 [Description] lower left and right quadrants [Unicode Name]

Output: BOX DRAWINGS DOWN SINGLE AND HORIZONTAL DOUBLE


Input: [Name] boxHD [Unicode] U+2566 [Description] lower left and right quadrants [Unicode Name]

Output: BOX DRAWINGS DOUBLE DOWN AND HORIZONTAL


Input: [Name] boxhu [Unicode] U+2534 [Description] upper left and right quadrants [Unicode Name]

Output: BOX DRAWINGS LIGHT UP AND HORIZONTAL


Input: [Name] boxhU [Unicode] U+2568 [Description] upper left and right quadrants [Unicode Name]

Output: BOX DRAWINGS UP DOUBLE AND HORIZONTAL SINGLE


Input: [Name] boxHu [Unicode] U+2567 [Description] upper left and right quadrants [Unicode Name]

Output: BOX DRAWINGS UP SINGLE AND HORIZONTAL DOUBLE


Input: [Name] boxHU [Unicode] U+2569 [Description] upper left and right quadrants [Unicode Name]

Output: BOX DRAWINGS DOUBLE UP AND HORIZONTAL


Input: [Name] boxul [Unicode] U+2518 [Description] upper left quadrant [Unicode Name]

Output: BOX DRAWINGS LIGHT UP AND LEFT


Input: [Name] boxuL [Unicode] U+255B [Description] upper left quadrant [Unicode Name]

Output: BOX DRAWINGS UP SINGLE AND LEFT DOUBLE


Input: [Name] boxUl [Unicode] U+255C [Description] upper left quadrant [Unicode Name]

Output: BOX DRAWINGS UP DOUBLE AND LEFT SINGLE


Input: [Name] boxUL [Unicode] U+255D [Description] upper left quadrant [Unicode Name]

Output: BOX DRAWINGS DOUBLE UP AND LEFT


Input: [Name] boxur [Unicode] U+2514 [Description] upper right quadrant [Unicode Name]

Output: BOX DRAWINGS LIGHT UP AND RIGHT


Input: [Name] boxuR [Unicode] U+2558 [Description] upper right quadrant [Unicode Name]

Output: BOX DRAWINGS UP SINGLE AND RIGHT DOUBLE


Input: [Name] boxUr [Unicode] U+2559 [Description] upper right quadrant [Unicode Name]

Output: BOX DRAWINGS UP DOUBLE AND RIGHT SINGLE


Input: [Name] boxUR [Unicode] U+255A [Description] upper right quadrant [Unicode Name]

Output: BOX DRAWINGS DOUBLE UP AND RIGHT


Input: [Name] boxv [Unicode] U+2502 [Description] vertical line [Unicode Name]

Output: BOX DRAWINGS LIGHT VERTICAL


Input: [Name] boxV [Unicode] U+2551 [Description] vertical line [Unicode Name]

Output: BOX DRAWINGS DOUBLE VERTICAL


Input: [Name] boxvh [Unicode] U+253C [Description] all four quadrants [Unicode Name]

Output: BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL


Input: [Name] boxvH [Unicode] U+256A [Description] all four quadrants [Unicode Name]

Output: BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL DOUBLE


Input: [Name] boxVh [Unicode] U+256B [Description] all four quadrants [Unicode Name]

Output: BOX DRAWINGS VERTICAL DOUBLE AND HORIZONTAL SINGLE


Input: [Name] boxVH [Unicode] U+256C [Description] all four quadrants [Unicode Name]

Output: BOX DRAWINGS DOUBLE VERTICAL AND HORIZONTAL


Input: [Name] boxvl [Unicode] U+2524 [Description] upper and lower left quadrants [Unicode Name]

Output: BOX DRAWINGS LIGHT VERTICAL AND LEFT


Input: [Name] boxvL [Unicode] U+2561 [Description] upper and lower left quadrants [Unicode Name]

Output: BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE


Input: [Name] boxVl [Unicode] U+2562 [Description] upper and lower left quadrants [Unicode Name]

Output: BOX DRAWINGS VERTICAL DOUBLE AND LEFT SINGLE


Input: [Name] boxVL [Unicode] U+2563 [Description] upper and lower left quadrants [Unicode Name]

Output: BOX DRAWINGS DOUBLE VERTICAL AND LEFT


Input: [Name] boxvr [Unicode] U+251C [Description] upper and lower right quadrants [Unicode Name]

Output: BOX DRAWINGS LIGHT VERTICAL AND RIGHT


Input: [Name] boxvR [Unicode] U+255E [Description] upper and lower right quadrants [Unicode Name]

Output: BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE


Input: [Name] boxVr [Unicode] U+255F [Description] upper and lower right quadrants [Unicode Name]

Output: BOX DRAWINGS VERTICAL DOUBLE AND RIGHT SINGLE


Input: [Name] boxVR [Unicode] U+2560 [Description] upper and lower right quadrants [Unicode Name]

Output: BOX DRAWINGS DOUBLE VERTICAL AND RIGHT


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

Output: FTCaseOption

Static Context Components


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

Output: FTDiacriticsOption

Static Context Components


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

Output: FTStemOption

Static Context Components


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

Output: FTThesaurusOption

Static Context Components


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

Output: Statically known thesauri

Static Context Components


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

Output: FTStopWordOption

Static Context Components


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

Output: Statically known stop word lists

Static Context Components


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

Output: FTLanguageOption

Static Context Components


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

Output: FTWildCardOption

Static Context Components


Input: [Component] FTCaseOption [Default initial value] case insensitive overwriteable overwriteable by prolog [Scope] lexical [Consistency rules]

Output: Value must be case insensitive or case sensitive.

Static Context Components


Input: [Component] FTDiacriticsOption [Default initial value] diacritics insensitive overwriteable overwriteable by prolog [Scope] lexical [Consistency rules]

Output: Value must be diacritics insensitive or diacritics sensitive.

Static Context Components


Input: [Component] FTStemOption [Default initial value] without stemming overwriteable overwriteable by prolog [Scope] lexical [Consistency rules]

Output: Value must be without stemming or with stemming.

Static Context Components


Input: [Component] FTThesaurusOption [Default initial value] without thesaurus overwriteable overwriteable by prolog (refer to default to augment) [Scope] lexical [Consistency rules]

Output: Value must be part of the statically known thesauri.

Static Context Components


Input: [Component] Statically known thesauri [Default initial value] none augmentable cannot be augmented or overwritten by prolog [Scope] module [Consistency rules]

Output: Each URI uniquely identifies a thesaurus list.

Static Context Components


Input: [Component] FTStopWordOption [Default initial value] without stopwords overwriteable overwriteable by prolog (refer to default to augment) [Scope] lexical [Consistency rules]

Output: Value must be part of the statically known stop word lists.

Static Context Components


Input: [Component] Statically known stop word lists [Default initial value] none augmentable cannot be augmented or overwritten by prolog [Scope] module [Consistency rules]

Output: Each URI uniquely identifies a stop word list.

Static Context Components


Input: [Component] FTLanguageOption [Default initial value] no language is selected overwriteable overwriteable by prolog [Scope] lexical [Consistency rules]

Output: Value must be castable to "xs:language" or "none".

Static Context Components


Input: [Component] FTWildCardOption [Default initial value] without wildcards no overwriteable by prolog [Scope] lexical [Consistency rules]

Output: Value must be without wildcards or without wildcards.

Static Context Components


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

Output: hidden


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

Output: text


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

Output: search


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

Output: tel


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

Output: url


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

Output: email


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

Output: password


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

Output: datetime


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

Output: date


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

Output: month


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

Output: week


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

Output: time


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

Output: datetime-local


Input: [State] Number [Data type] A numerical value [Control type] A text field or spinner control [Keyword]

Output: number


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

Output: range


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

Output: color


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

Output: checkbox


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

Output: radio


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

Output: file


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

Output: submit


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

Output: image


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

Output: reset


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

Output: button


Input: [Name] clip-path [Value] | [ || ] | none [Initial] none [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] as specified [Media] visual [Animatable] as specified for [CSS-SHAPES], otherwise no [Computed value]

Output: as specified, but with values made absolute


Input: [Name] clip-rule [Value] nonzero | evenodd [Initial] nonzero [Applies to] Applies to SVG graphics elements [Inh.] yes [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-image [Value] # [Initial] none [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified, but with URIs made absolute


Input: [Name] mask-mode [Value] # [Initial] auto [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-repeat [Value] # [Initial] no-repeat [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: Consists of: two keywords, one per dimension


Input: [Name] mask-position [Value] # [Initial] center [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] refer to size of mask painting area minus size of mask layer image; see text background-position [CSS3BG] [Media] visual [Animatable] as repeatable list of simple list of length, percentage, or calc [Computed value]

Output: Consisting of: two keywords representing the origin and two offsets from that origin, each given as an absolute length (if given a ), otherwise as a percentage.


Input: [Name] mask-clip [Value] [ | no-clip ]# [Initial] border-box [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-origin [Value] # [Initial] border-box [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-size [Value] # [Initial] auto [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] as repeatable list of simple list of length, percentage, or calc (This means keyword values are not animatable.) [Computed value]

Output: as specified, but with lengths made absolute


Input: [Name] mask-composite [Value] # [Initial] add [Applies to] All elements. In SVG, it applies to container elements without the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask [Value] # [Initial] see individual properties [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] see individual properties [Media] visual [Animatable] see individual properties [Computed value]

Output: see individual properties


Input: [Name] mask-border-source [Value] none | [Initial] none [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: none or the image with its URI made absolute


Input: [Name] mask-border-mode [Value] luminance | alpha [Initial] alpha [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-border-slice [Value] [ | ]{1,4} fill? [Initial] 0 [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] refer to size of the mask border image [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-border-width [Value] [ | | | auto ]{1,4} [Initial] auto [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] relative to width/height of the mask border image area [Media] visual [Animatable] no [Computed value]

Output: all s made absolute, otherwise as specified


Input: [Name] mask-border-outset [Value] [ | ]{1,4} [Initial] 0 [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: all s made absolute, otherwise as specified


Input: [Name] mask-border-repeat [Value] [ stretch | repeat | round | space ]{1,2} [Initial] stretch [Applies to] All elements. In SVG, it applies to container elements excluding the element and all graphics elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] mask-border [Value] <‘mask-border-source’> || <‘mask-border-slice’> [ / <‘mask-border-width’>? [ / <‘mask-border-outset’> ]? ]? || <‘mask-border-repeat’> || <‘mask-border-mode’> [Initial] See individual properties [Applies to] See individual properties [Inh.] no [%ages] n/a [Media] visual [Animatable] See individual properties [Computed value]

Output: See individual properties


Input: [Name] mask-type [Value] luminance | alpha [Initial] luminance [Applies to] mask elements [Inh.] no [%ages] n/a [Media] visual [Animatable] no [Computed value]

Output: as specified


Input: [Name] clip [Value] | auto [Initial] auto [Applies to] Absolutely positioned elements. In SVG, it applies to elements which establish a new viewport, elements and mask elements. [Inh.] no [%ages] n/a [Media] visual [Animatable] as rectangle [Computed value]

Output: as specified


Input: [Status] Proposal [Summary] To promote the 'citation' property currently on MedicalScholarlyArticle up to CreativeWork. [Vocab] Moves citation up to CreativeWork [Topic]

Output: Citation Promotion

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


Input: [Status] Proposal [Summary] Extension for describing accessibility properties of a CreativeWork. [Comments] Draft published to elicit feedback. [Topic]

Output: Accessibility

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


Input: [Status] Accepted [Summary] Add one property 'department' to Organization, to allow local businesses to describe their depts (e.g. opening hours) in detail. [Comments] Proposal very greatly simplified after WebSchemas discussion. [Topic]

Output: Add Organization department property

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


Input: [Status] Proposal [Summary] Property to indicate that a single identity is being described. [Vocab] Essentially same meaning as owl:sameAs, but suggesting a distinct name to make it easier to talk about; also schema.org data is typically scruffier than OWL re http-range-14. [Comments] Draft published to elicit feedback. [Topic]

Output: sameThingAs

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


Input: [Status] Proposal [Summary] A proposal for a new Action type. [Vocab] See full entry and proposal for details. May2013 version builds on two previously published designs. [Comments] The schema.org team solicit comments on this draft via public-vocabs@w3.org. [Topic]

Output: Actions in Schema.org

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


Input: [Status] Proposal [Summary] "While schema.org already supports marking up offers to sell products (pre-transaction), it does not currently provide schema for the common kinds of confirmations and notifications around orders (post-transaction)". [Vocab] Adds classes OrderStatus, Order, DeliveryMethod plus associated properties. [Comments] Complements Actions proposal, but independent. [Topic]

Output: Orders in Schema.org

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


Input: [Status] Proposal [Summary] This proposal includes new types for describing reservations and tickets [Vocab] Adds classes Reservation, ReservationStatus, ProgramMembership, Flight, TrainTrip, TrainReservation, FoodEstablishmentReservation, FlightReservation, EventReservation, ReservationPackage, BusReservation, BusTrip, RentalCarReservation, RentalCar, Car, LodgingReservation plus associated properties. [Comments] Complements Actions proposal, but independent. [Topic]

Output: Reservations in Schema.org

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


Input: [Status] Proposal [Summary] This proposal adds a single new type, EmailMessage [Vocab] EmailMessage is a CreativeWork representing email messages, just as WebPage already represents Web pages. [Comments] No properties currently defined; proposals welcomed. [Topic]

Output: EmailMessage type

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


Input: [Status] Accepted [Summary] This proposal adds a single new type, WorkersUnion, addressing issue 17 in the WebSchemas tracker. [Vocab] "A Workers Union (...) is an organization that promotes the interests of its worker members by collectively bargaining with management, organizing, and political lobbying."" [Comments] One type, see draft schema. [Topic]

Output: Workers Union type

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


Input: [Status] Accepted; published in next version [Summary] Proposes modest changes and additions to support TV and radio (from EBU and BBC). [Vocab] Adds Series, Season, Episode under CreativeWork. Existing TVSeries, TVSeason, TVEpisode under Series/Season/Episode. Adds RadioSeries/RadioSeason/RadioEpisode alongside. Adds Programme/Clip for programmes other than episodes. Adds description of a service with Service/PublicationEvent for broadcast, streaming, VoD, etc. [Comments] See also background notes and [[1]]. Draft initially from EBU/BBC/NoTube discussions. Nearby vocab: see VideoObject, AudioObject; Movie. Event re scheduling. See also UserPlays, a kind of UserInteraction. Comics and TV/Radio also share a concern for describing fictional characters and narratives. [Topic]

Output: TV and Radio proposal

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


Input: [Status] Some initial discussions. [Summary] Several parties are working towards a Sports Vocabulary proposal. See query from Paul Kelly (SportsML), Microdata + Sports Stats post describing earlier ESPN/Google collaboration, and the Sports Ontology used by BBC, Press Association and others. See also sports-schema-collab mailing list. [Vocab] Several sources including a full draft from the ESPN+Google work. Needs summary here. [Comments] March 2nd - posted writeup of the ESPN/Google Microdata vocabulary; next is discussion on finding common basic sports vocab for schema.org. [Topic]

Output: Sports

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


Input: [Status] Discussing Proposals [Summary] Proposal from Marvel (see examples). [Vocab] Adds PeriodicalSeries (under Intangible(?)), PeriodicalIssue (under CreativeWork), Comic Issue (under PeriodicalIssue), GraphicNovel (under Book). Approx 6-9 properties for each of these classes. [Comments] Generally well received and specified, but some detailed discussion re fine-grain detail of comics (imprint, page count etc.). Can those properties be shared with Book/numberOfPages, or ScholarlyArticle? Should PeriodicalSeries be intangible? [Topic]

Output: Comics and Serials

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


Input: [Status] Hopefully Final Proposal - please review [Summary] Proposes some modifications to Event based on deployment experience. [Vocab] Adds eventStatus, previousStartDate, previousEndDate; eventCategory; makes startDate/endDate repeatable. Encourages use of 'url' from Thing. [Comments] Fairly modest proposals based on implementor feedback. May2013 update addresses the last open issue on repeating events. [Topic]

Output: Event schema update

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