Application Foundations all

From W3C Wiki

1.Security and Privacy: Wendy

Privacy and Security: Application Foundations

A goal of Application Foundations is to class the interfaces of the Open Web Platform into subsystems or modules that help WebApp developers to use them effectively. In security and privacy, that means organizing the work to a) to share meaningful guidance with those looking to increase their apps' security and privacy and b) enable developers to build secure and private apps by default.

Foundational Standards and Components: Numerous W3C Recommendations and Rec-track specifications help developers to build secure and privacy-preserving Web Applications. In particular we focus on the work of the Web Application Security WG (WebAppSec) and Web Cryptography WG, and review and architectural work by PING and TAG:

The security of a user's interaction with a Web site or Web app depends on the user's getting what he or she requested, without interference or interception by third parties. Many of the requirements of this interaction are defined elsewhere: [1] W3C standards build on and integrate many of these components.

Unless a site is delivered over HTTPS, it is vulnerable to on-network (man-in-the-middle) attacks as well as communication interception. Strong assurance thus begins by making it easier for developers to deploy HTTPS on their sites. Some features, such as those that provide access to sensitive personal information, should be used only when users can get assurance of the provenance and integrity of the site asking for that information.

HTTPS for Secure Communication

The TAG's guidance: Securing the Web [2], concludes “ that server authentication and integrity are baseline requirements for the continued success of the Web. Furthermore, confidentiality -- while arguably not always strictly necessary -- is often needed. Since the necessity of confidentiality may only become apparent in hindsight, we should also consider it as being crucial to the continued success of the Web.”

Therefore, the TAG finds that:

  • The Web platform should be designed to actively prefer secure communication — typically, by encouraging use of "https://" URLs instead of "http://" ones (although exceptions like "localhost" do exist).
  • Barriers to adopting "https://" should be removed where feasible.
  • The end-to-end nature of TLS encryption must not be compromised on the Web, in order to preserve trust.

Privileged Contexts (FPWD, WebAppSec/TAG) provides guidance for dealing with features that self-designate as requiring a privileged context to be enabled. The recommendation will include non-normative advice on when a feature might designate itself as requiring a secure context and provide a normative algorithm for determining if a given context is privileged.

HTTPS Migration

Since today's Web is not yet fully HTTPS, several specifications help developers to get there.

Upgrade Insecure Requests (FPWD, WebAppSec) creates a mechanism to assist sites in migrating from HTTP to HTTPS by allowing them to assert to a user agent that they intend a site to load only secure resources, and that insecure URLs ought to be treated as though they had been replaced with secure URLs.

Mixed Content (CR, WebAppSec) recommends treatment for resources loaded over insecure channels in a secure web application. Use cases includes standard behaviors for user agents to follow when encountering insecure resource loads in a secure context. This might include definitions of “active” and “passive” content that must be blocked or can be loaded with a warning, and possibly ways for secure applications to consume insecure but non-sensitive resources (such as a weather feed).

Crypto Functionality

WebCrypto gives access to crypto primitives in the browser, easily enabling developers to incorporate new functions in their apps.

WebCrypto API (CR, WebCrypto) specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes an API for applications to generate and/or manage the keying material necessary to perform these operations. Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. This will promote higher security insofar as Web application developers will no longer have to create their own or use untrusted third-party libraries for cryptographic primitives.

Secure Site Development and Maintenance

WebAppSec also gives developers tools for building and maintaining their sites:

Content Security Policy Level 2 (CR, WebAppSec) provides a policy language intended to enable web designers or server administrators to declare a security policy for a web resource. The goal of this specification is to reduce attack surface by specifying overall rules for what content may or may not do, thus preventing violation of security assumptions by attackers who are able to partially manipulate that content, for example by script injection or cross-site request forgery. Content Security Policy Pinning defines a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.

Cross-Origin Resource Sharing (CORS) (Rec, WebApps and WebAppSec) defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.

Subresource Integrity (FPWD, WebAppSec) offers a recommendation for uniquely identifying resources loaded in a secure web application to detect and prevent potentially malicious modification. Use cases include adding integrity protections to sub-resource loads from HTML documents. This mechanism would have the goals of allowing resource authors to specify the exact hash value of cross- origin sub-resources. Possible future features may include allowing optimistic loading of such resources from content- aware caches or over insecure transports, provided appropriate privacy and security guarantees can be achieved.

Referrer Policy (FPWD, WebAppSec) A recommendation for a header and meta tag allowing resource authors to specify a policy for the values sent as part of the HTTP Referer (sic) header. Use cases include making this policy more restrictive to protect applications which include security capability tokens in the URL, or allowing more permissive sharing of referrer information from secure to insecure origins to remove barriers which today prevent applications from moving to secure origins.


Secure Authentication

Authentication remains a common need. Credential Management API (FPWD, WebAppSec) offers a standardized API to address use cases related to assisted management of user credentials, including traditional username/password pairs.

New Authentication Work

We also anticipate new work: Secure Web Authentication, based in the FIDO specifications for universal two-factor authentication (U2F) and universal authentication framework (UAF), a new WG will be chartered to develop a recommendation-track standard for secure authentication of entities (users, systems and devices) to enable high-security Web applications. Goals include standardized support of two-factor authentication as well as the elimination of passwords if allowed by device capabilities, while maintaining the same origin policy.

Hardware-Based Web Security will be chartered to develop recommendation-track documents that define a standard to provide secure services for high security Web applications. Use cases will include the ability to encrypt and to decrypt data using hardware based encryption modules, the ability to manage credential information for hardware based security modules, and the ability to access specific security sensitive services offered by hardware tokens.

Experimental New Work

Suborigin Namespaces Create and advance a recommendation to allow applications to place themselves into namespaces within a traditional scheme/host/port RFC 6454 Origin label to enable easier development of modular applications with privilege separation.

Confinement with Origin Web Labels Create and advance a recommendation for a robust JavaScript confinement system for modern web browsers, in a way that is backward-compatible with legacy web content. The goal of the specification is to define APIs for specifying privacy and integrity policies on data, in the form of origin labels, and a mechanism for confining browsing contexts (pages, iframes, etc.) according to these labels. This would allow Web application authors and server operators to share data with untrusted -- buggy but not malicious -- code (e.g., in a mashup scenario, cross-origin iframes) yet impose restrictions on how the code can further share the sensitive data. An additional goal is to define a light-weight, in-thread Web Worker. This would allow developers to build privilege-separated, compartmentalized applications

Entry Point Regulation for Web Applications (FPWD) Create and advance a recommendation to allow web applications to designate their entry points via a combination of headers and a policy manifest. Conformant user agents will restrict external navigations and other information flows into the application based on this policy to reduce the application's attack surface against Cross-Site Scripting and Cross Site Request Forgery. Restricting deep-linking for non-security purposes is not a goal of this deliverable, and it should give resource owners no additional ability to do so beyond current abilities of the web platform, e.g. by providing a simple to deploy mechanism using client-side state to supplement what can already be accomplished by a less-scalable web application firewall. Preserving the ability to link on the web platform will be prioritized.

Permissions API (FPWD) Create and advance a recommendation to allow web applications to be aware of the status of a given permission, to know whether it is granted, denied, or if the user will be asked whether the permission should be granted. This recommendation will not address user agent implementations of permissions, including their scope, duration, granularity, or user interface and experience for indicating, configuring, or asking for permissions.

Privacy and Security Reviews

PING, WebSec, and TAG contribute to the reviews of existing specs. While much of that review focuses on privacy and security considerations in the spec text or implementation, it may also include developer considerations that impact the privacy and security.

---Notes---

[1] DNS resolution provides an end-point based on the URL given to a client; DNSSEC, if used, can assure that it's the end-point intended by the domain registrant; TLS assures the integrity and confidentiality of the HTTP communications, while certificate validation provides some indication of the site-operator's identity.

[2] TAG Blog: Securing the Web, 23 January 2015.

2. Core Web Design and Development: Chris, Mike, PLH

The key technologies in this foundation help Web developers meet user expectations about the “look and feel” of Web applications. Users naturally expect user experiences with certain “look and feel” characteristics of a consistent level of quality across the different platforms on which they use applications—including the Web; for example, users of native mobile apps expect Web applications to have some of the same desirable “look and feel” UX characteristics that their native mobile apps have.

So in part, this foundation can be seen as aiming to provide developers with the tools they need to build applications with ”look and feel” UX characteristics of the same level of quality as they experience with native mobile apps and other application platforms.

This foundation includes CSS, graphics formats, animation mechanisms, typography, HTML, the DOM, and JavaScript—and the high-level goals are to have a “core toolbox” of technologies for controlling “look and feel” UX characteristics that is:

  • reliably interoperable across all browsers
  • as easy-to-use for developers as possible

Relevant specs:

Also the various language requirements guides: Japanese, Chinese, Indic, Latin etc and the requirements from digital publishing.

Goals

  • document developer use-case scenarios that fall under this foundation
  • document current developer “pain points” related to developing engaging and compelling Web applications using CSS, graphics formats, animation mechanisms, and typography; for example, lack of ability to easily create compelling users experiences with drag-and-drop mechanisms across browsers; or lack of ability to create compelling user experiences with rich-text editing across browsers
  • document "success stories" we've had so far for addressing developer pain points; e.g., Responsive Images (the picture element), CSS-TAG "Houdini" work just starting to make CSS layout more user extensible
  • define a prioritization framework for these various developer use cases can be addressed
  • evaluate how much of these use cases are currently achievable with existing techs
  • evaluate how much of the developer “pain points” are currently achievable with existing techs
  • for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed (Houdini working on this)
  • for pain points that are not addressable (or in unsatisfactory ways), determine which fixes/refinements are needed
  • among those that are needed and in progress, determine how to accelerate their development
  • among those that are needed and not in progress, determine how to get them started

Potential milestones

  • Feb 15: document some existing ““core toolbox” technologies that are the most-severe pain points for developers; the model example of a document of this kind is the Editing Explainer developed by the HTML Editing Task Force
  • Feb 15: document some existing ”success stories” for “core toolbox” technologies that have solved some severe pain points for developers—with an eye toward figuring out how to reproduce those successes (e.g., Responsive Images (the picture element)
  • Feb 19: Review of capabilities of native platforms in this space
  • Feb 28: proposed framework for prioritizing consideration of the identified “priority pain points”
  • Feb 28: Outreach to the developers on the proposed framework
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

Progress

Over the last year to 18 months, work in several Core Design/Development groups has been informed by the notion of extensibility and in particular the composability of multiple extensions. Early work showed that single extensions were relatively easy t make in some areas, but tended to step on each other's toes. Applicattion Foundations has driven some of that, although the major impetus was the Extensible Web Manifesto.

As a result, functionality has been shifted from SVG to CSS with the expectation of using it in Web Components. CSS has done good work on styling the Shadow DOM, which allows integrating the styling of extensions into the overall site style; it has also started the Houdini project together with the TAG, to provide APIs that expose previously hidden functionality that already exists in the browser and which extensions would otherwise have to re-implement. Other changes include a focus on not specifying special-case functionality, but instead favouring generality and composability (particularly in layout models); and ongoing discussions about the styling and functionality of rich text selection, annotation, and editing.

There is starting to be a conversation on maintenance of large websites (in particular the CSS) and learning from frameworks like SASS which are increasingly used. On the downside, there is a tendency to ignore/reimplement large sections of te OWP in JavaScript, which is extension but is rarely composable.

The impact of extensibility on performance continues to be a hot topic. As an example, WebAudio abandoned a previous extensibility design (ScriptProcessor node) because it blocked the main layout thread; instead a new although more complex design was introduced (Audio Workers) which provides non-blocking and low-jitter extensibility, after content developer feedback raised significant concerns about the older design. Performance improvements based on responsive images are also increasingly discussed.

3. Device Interaction: Philipp, Dave

Description

Source: "Applications Foundations for the Open Web Platform" - Jeff Jaffe

"Closely related to the Core Foundation is the Device Interaction Foundation, which describes the ways that devices are used to control or provide data to applications. New Web APIs are proposed weekly to give access to all of the features offered by supporting devices. For mobile phones, APIs exist or are in development for access to camera, microphone, orientation, GPS, vibration, ambient light, pointer lock, screen orientation, battery status, touch events, bluetooth, NFC, and more.

The next generation of Web attached devices will introduce new challenges. For instance, the Automotive and Web Platform Business Group is developing APIs to access information about vehicle speed, throttle position, interior lights, horn, and other car data that could help improve driving safety and convenience. We anticipate some of that work will advance to the standards track. In general, wearables, personal medical equipment devices, home energy management devices, and the Internet of Things will drive developer demand for data in applications, and for Web abstractions to simplify what will be new complexity in underlying networks. To achieve that simplicity for developers, the TAG, Device APIs Working Group, Web Apps Working Group, and Systems Applications Working Group all have a role to play in capturing good practices for API design."

Next Steps

Quote form https://lists.w3.org/Archives/Team/w3mreq/2014Dec/0096.html

"W3M today concluded that it was time to take the current description to the next level. This would include:

  • comparing what we have in OWP with other platforms
  • gap analysis
  • prioritization
  • evangelizing.
  • It could also include a more detailed catalog of
    • what comprises each Foundation
    • what future requirements might be."

https://www.w3.org/2015/01/09-appfound-minutes.html

" as part of our workplan, I'd like to find developers we can talk to ... If we spend a month talking to devs ... if they say "they have no issues" -- great, nothing to do ... if they say "these issues" then we have next steps for conversation ... We should be flexible about what a workplan looks like ... different in an area where we're more established ... from one where we've had less traction ... If we're serious about an area, we have to do something"

https://www.w3.org/2015/01/16-appfound-minutes.html

"I'd like to get as broad an involvement from the public as possible"

" we should be calling on the AB, Membership and public for help ... we could put this on the agenda ... of the AB ... to keep them up-to-date"

" we get to a point where we want to create a conference or workshop ... there is an extensible web summit in April ... could be presented there ... or we can attach an app foundation summit and do something there"

"public survey, good idea,"

Workplan

"Focus is on what can be accomplished in time for the May AC meeting."

With that timeframe, focus should probably be on mobile.

  • Feb 15: Finalize list of relevant specs (for mobile, auto, wearables, personal medical equipment, home energy management, IoT)
  • Feb 28: First conversation with mobile developer scheduled (target: 5)
  • Mar 15: First draft of mobile gap analysis (including analysis of relevant literature/analyst reports etc.)
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

@@ All below is Foddder, please ignore

  • determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG
  • @@
  • Feb 6: finalize workplan

@@

  • Feb 15: identify sources of use cases not yet involved in W3C
  • Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)
  • Feb 28: proposed framework for prioritizing use cases
  • March 15: List of prioritized use cases
  • March 15: Review of capabilities of native platforms in this space
  • March 15: Map of use cases to Web technologies
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

Relevant specs:

  • Sysapps specs
  • DAP specs
  • NFC spec
  • Bluetooth API CG
  • Vehicle API spec
  • Second screen API
  • @@ to finalize

@@ Following is Fodder, please ignore

Goals

@@ copied from media plan - for device interaction, some of this sounds like lots of extra work in area where resources are already somewhat low - for some areas (WoT, Auto?) some of this is already planned as part of WG/IG work @@ dev outreach on sysapps, DAP, mobile IG - make that fit with HTML5Apps reviewer comments

  • document which use cases fall under this foundation
  • define a prioritization framework for these various use cases
  • evaluate how much of these use cases are currently achievable with existing techs
  • for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed
  • among those that are needed and in progress, determine how to accelerate their development
  • among those that are needed and not in progress, determine how to get them started
  • compare Web capabilities to native platforms
  • ensure consistencies of separately-developed specs

Potential milestones

"Focus is on what can be accomplished in time for the May AC meeting."

  • determined by workplans of WoT IG, Auto WG and BG, DAP WG, SysApps WG
  • @@
  • Feb 6: finalize workplan

@@

  • Feb 15: identify sources of use cases not yet involved in W3C
  • Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)
  • Feb 28: proposed framework for prioritizing use cases
  • March 15: List of prioritized use cases
  • March 15: Review of capabilities of native platforms in this space
  • March 15: Map of use cases to Web technologies
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

4. Application Lifecycle: Philipp, Dom, Mike, Xiaoqian

Description

People expect their apps to be useful even when there is no network (“offline”), to do the right thing when the network returns (“sync”), to take into account location-specific information (“geofencing”), to be easy to launch on their device (“manifest”), to respond to notifications (from the local device or remote server), to make the most of resource from the device ("battery level" and "wake lock"), and so on. The Application Lifecycle Foundation deals with the range of context changes that may affect an application.

From Application Foundations for the Open Web Platform

Use cases

Existing Work on the Web

Relevant specs:

Native equivalents

Work plan

Goals

  • accelerate development & deployment of these technologies (core to one of the biggest “gap to native”)
  • document a consistent view of how these technologies work together
  • identify gaps for a next generation of use cases in this space

Potential milestones

  • Feb 15: gather links to relevant use cases
  • Feb 28: proposed framework for prioritizing use cases
  • March 15: List of prioritized use cases
  • March 15: Review of capabilities of native platforms in this space
  • March 15: Map of use cases to Web technologies
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

5. Media and Real-Time Communications: Philipp, Dom, Yves, PLH

Relevant specs:

Goals

  • document which use cases fall under this foundation
  • define a prioritization framework for these various use cases
  • evaluate how much of these use cases are currently achievable with existing techs
  • for use cases that are not achievable (or in unsatisfactory ways), determine which technologies are needed
  • among those that are needed and in progress, determine how to accelerate their development
  • among those that are needed and not in progress, determine how to get them started
  • compare Web capabilities to native platforms
  • ensure consistencies of separately-developed specs

Potential milestones

  • Feb 15: identify sources of use cases not yet involved in W3C
  • Feb 15: gather links to existing use case documents (Web & TV, WebRTC / RTCWeb, 2nd Screen, MediaScape)
  • Feb 28: proposed framework for prioritizing use cases
  • March 15: List of prioritized use cases
  • March 15: Review of capabilities of native platforms in this space
  • March 15: Map of use cases to Web technologies
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

6. Performance and Tuning: PLH, Xiaoqian, Mike

Introduction

From Application Foundations for the Open Web Platform

Open Web Platform functionality has moved steadily to the client side, which creates a variety of new challenges related to security, application lifecycle management, but especially performance. JavaScript engines have improved dramatically in the past few years. But for high-end games, media streams, and even some simple interactions like scrolling, we still have much to do so that developers can monitor application performance and code in ways that make the best use of resources. This is the focus of our Performance and Tuning Foundation.

Today we are working on APIs for performance profiling such as navigation timing and resource hints. In various discussions and Workshops, people have asked for a number of enhancements: for understanding load times, enabling automatic collection of performance data, providing hints to the server for content adaptation, improving performance diagnostics, managing memory and garbage collection, preserving frame rates, using the network efficiently, and much more.

The responsive design paradigm mentioned in the Core Web Design and Development Foundation also plays a role in the world of performance: we can make better use of the network and processing power if we can take into account screen size and other device characteristics.

Who

  • Xiaoqian Wu
  • Philippe Le Hegaret
  • Mike Smith

Resources

Relevant specs

Reading list

Goals

  • Identify the most important bottlenecks related to lack of responsiveness in Web Applications in order to help developers provide a great web experience
    • Identify a subset of applications as target, such as tweetdeck.twitter.com and reach out to their developers
  • define a prioritization framework for these various bottlenecks
  • evaluate how much of these bottlenecks are currently addressed with existing techs
  • for bottlenecks that are unsatisfactory, determine which technologies or strategies are needed
  • among those that are needed and in progress, determine how to accelerate their development
  • among those that are needed and not in progress, determine how to get them started or focused

Under consideration: provide some sample cases/web pages to help evaluate the performance optimization.

Progress

In the past two years, the Web Performance Working Group has been trying to identify the potential performance bottlenecks of the Web, and specify UA features and APIs for developers to observe and improve their application performance.

We believe that a large part of these bottlenecks are currently addressed with existing techs. Still, we need to invest more on this topic.

For bottlenecks that are unsatisfactory, we managed to offer Web developers tools to gather detail information about their Web application, so that they can further the optimization.

One of our major concern was to the lack of responsiveness in Web Applications. To identify the most important bottlenecks in this area, we have started the work on Server Timing, which enables the server to communicate performance metrics about the request-response cycle to the user agent. Frame Timing, from another aspect, provides a new ability to measure page smoothness (i.e. Frames per Second and Time to Frame).

For most of the various known bottlenecks, we believe a prioritization framework would help to provide a better picture of the future works. The WG will publish primers or Best Practice documents to support this plan.

Among those specs that are needed and in progress, we will make sure the documents are moving the REC track properly. In some of the special cases, we’d like to continue our work in a second edition (f.ex. High Resolution Time, Performance Timeline, User Timing and Navigation Timing), so that we can meet the new changes of the Web. For those that are needed and not in progress, we managed to identify the difficulties and provided solutions accordingly. The GitHub issues and the Mailing List of the WG are active. We believe these open discussion helps to keep our specs moving forward.

Outreach

  • reach out to UI library developers
  • survey developers
  • look into browser vendors' unspecified optimization features

Potential milestones

  • February 1: start outreach
  • March 15: proposed framework for prioritizing bottlenecks
  • April 3: list of prioritized bottlenecks and application targets
  • April 15: Map of technologies and strategies to Web technologies
  • April 20: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

7. Usability and Accessibility: Richard, Bert, Judy

Usability, Accessibility, Internationalization

Goals across these three areas

  • Clarify goals in each area relative to Application Foundations
  • Map technologies for each area to Application Foundations
  • Identify staff and WG resource gaps
  • Recruit people and pursue resources to fill gaps
  • Report to Membership on status/progress of work in the area

Milestones across these three areas

  • February 2: Establish any common goals across these three areas
  • February 16: Each area start outreach
  • March 2: Prioritize bottlenecks and application targets for each of these three areas
  • March 16: Map technologies and strategies to Web technologies
  • March 30: Proposed prioritization of actions for staff
  • April 13: Suggestions for additional resources investment per area
  • April 20: Report on progress due for AC meeting
  • May 5: AC meeting starts

Accessibility

Relevant Accessibility Technologies

  • Accessible Rich Internet Applications (ARIA) 1.0, 1.1
  • Indie UI
  • Accessibility APIs
  • Web Technology Accessibility Guidelines (WTAG)
  • Media Accessibility User Requirements (MAUR)
  • [expand this list]

Accessibility Goals

  • Develop WAI2020 Framework including modular/flexible plan for accessibility guidance for AF & Verticals
    • Two public input discussions at CSUN, went well, additional in planning stage
  • Improve resources and mechanisms for coordination with expanded W3C scope of technical areas
    • WTAG progress, interest, engagement
  • Recruit accessibility experts interested in working in new areas of AF & Verticals
    • One presentation so far, needs refinement, need to put online
  • Develop a use-case and user-scenario library
    • Progress on interest, part of WAI2020
  • Expand testing resources for accessibility
    • Progress on potential contributions of testing resources
  • Create map of advanced accessibility architecture relative to OWP & AF
    • Further discussions, interest

Accessibility Milestones

  • February 2: Draft plan for WAI2020 Framework Discussion at CSUN 2015; announcements; initial outreach
  • February 16: Develop outreach plan for more accessibility experts for AF & Verticals
  • March 2: WAI2020 Framework discussion starts
  • March 16: Summary of CSUN WAI2020 Framework discussion & updated plan for G3ICT WAI2020 & AccessU
  • March 30: Recruitment-into-verticals presentation available
  • April 13: Summary of progress on testing resources
  • April 20: Draft of Web Accessibility Ecosystem architecture
  • May 5: Drafts on remaining except use case repository

Internationalization

Application Foundation Progress

The Internationalization Activity primarily supports development of application foundations by working with W3C Working Groups to ensure that features needed for international users are taken into account. There is good traction with the developers in the Working Groups, but the work is demanding and highly varied, and it is always hard to find people who are able and interested in the work of reviewing specs and guiding developers to make well-internationalized specifications.

Initiatives are under way to intersect with specification development work as early as possible, to relieve some of the pressure and trauma of discovering internationalization issues late in the day, but also work is under way to capture information in the form of documented lists of do's and don'ts, so that the Internationalization Working Group becomes less of a bottleneck for this guidance. See Internationalization Best Practices for Spec Developers (and it's task-based, quick-access page), as well as the documents listed below.

The Internationalization WG has to be flexible and prioritize issues as they arise, but major topics that are directly applicable to the developers of applications and need attention in the near and medium term include the following:

  • Choice and use of character encodings. This is a fairly well understood problem, and we already have the document Character Model for the World Wide Web: Fundamentals, but the Encoding specification will strengthen the commitment to UTF-8, reduce use of legacy encodings to a safer and more interoperable subset, and add APIs. The browser implementers are generally implementing the spec, but we are in need help to develop tests.
  • String matching and searching. A recurrent issue, this is much less well understood and is important for things like range selectors, annotations, identifier matching, and the like. We are assembling guidelines in Character Model for the World Wide Web: String Matching and Searching.
  • Handling of local formats, time zones, and locales. This area is still poorly understood but is becoming particularly important for applications such as form validation and input, CSV data management, web payments, etc. We have begun work on Language Tags and Locale Identifiers, but the area still needs a fair amount of research.

The Internationalization Activity is also providing resources which can support application developers.

There are significant gaps in support for display of non-Latin scripts. These are critical issues for applications using technologies such as CSS, SVG or Digital Publications, but until now there has been very little information available about requirements for text justification, line breaking, non-Latin emphasis, and many other typographic features needed to make the Web feel locally relevant and useable.

The Internationalization Activity has begun providing that information. We began with Japanese, and are now working on Korean, Chinese, and Devanagari requirements. There is still much work to do, however. Encouragingly, we have been approached by people who want to develop requirements for Arabic, Ethiopic, Mongolian, Tibetan, and Uighur scripts, and are preparing the way for that. (These initiatives also bring new people from user communities around the world into contact with the W3C.)

Once we have the requirements, we need to identify gaps and close them. In particular, the Internationalization WG is currently working with developers on:

  • Bidirectional text support. We recently helped the HTML5 developers add important features to improve support for the many millions of people using right-to-left scripts. We now need to address more deeply the needs of bidi support in plain text environments, such as WebVTT, CSV, JSON, etc.
  • Vertical text and ruby. These features were highlighted as pressing needs for Asian digital publications in a recent W3C workshop. The i18n Activity helped create a new model in HTML that has now been largely implemented in browsers, but ruby styling is still in development (although Firefox now has very good support for this, from a base of no ruby support at all just a few weeks ago.) Vertical text support in CSS has been many years in development, and there is now increased pressure to finally produce a solution. This has further to go than ruby, but work is in progress.
  • Other typographic requirements. The Activity aims to support CSS in particular and other working groups by pulling together pointers to most aspects of non-Latin typography in Improving text layout and typography on the Web and in eBooks, and compiling information until such time as it can be added to a larger layout requirements effort. This will serve as a resource for browser implementers and application developers.

As part of its work on identifying and closing gaps in features required for international deployment of W3C technologies, the Internationalization Activity is also developing internationalization-related tests and compiling the results of those tests for major browsers. The tests are being used by all major browsers (and are pushed to the Web Platform and CSS test repos), and the results regularly prompt implementers to address gaps in their international feature support. They are also a useful resource for all Web application developers.

While the work of the Internationalization Activity is well known in W3C Working Groups and regularly communicated at major internationalization-related gatherings (such as the Unicode Conference), and although published work is announced through the W3C home page, twitter accounts, etc., we don't really have information about how well known the work is among the general developer population. It may be helpful to identify new ways of communicating the work as long as they don't significantly stretch the already thin resources of the personnel involved in internationalization at the W3C.

Key activity areas of i18n WG

The following notes cover the work of the i18n Activity in general.

  • reviews, discussion & advice
  • developer guidelines
  • requirements development
  • gap analysis & bridging
  • test development
  • education & outreach
  • tracking collateral developments

Goals

Reviews, discussion & advice

  • continuous support of OWP development through review, discussion and advice with W3C Working Groups

Developer guidelines

  • produce guidelines for OWP spec developers about i18n issues, so that they can integrate i18n considerations into their work as early as possible, and lessen the requirement for involvement of i18n personnel
  • recycle experience in reviews into useful guidance
  • facilitate the new process by enabling a degree of self-review, and reduce the likelihood of big surprises near the end of development

Requirements

  • develop better understanding of requirements for support of non-Latin scripts on the Web and in eBooks
  • provide support, especially to CSS and Digital Publications work, on typographic and layout requirements on the Web and in eBooks, so that the needs of communities around the world are provided for
  • reach out to communities around the world that don't have such an active voice at W3C and include them

Gap analysis & bridging

  • do gap analysis of needs of the multilingual web as described by user requirements and support provided by key technologies of the OWP (esp CSS, HTML) and support initiatives to bridge those gaps
  • do gap analysis of needs for multilingual web content creation, including starting from monolingual content and doing translation (esp ITS2, XLIFF) and support initiatives to bridge those gaps

Tests

  • develop tests for i18n features being developed as part of the OWP and summarise current support by browsers and ebooks
  • support development of i18n features in OWP Working Groups by highlighting issues and successes, and clarifying status in implementation of i18n features of specifications, esp. CSS and HTML
  • contribute tests to W3C test suites
  • provide support for education and outreach information

Education & outreach

  • provide education and tools for users of OWP about how to apply i18n features

Tracking collateral developments

  • track other factors than those relating to the OWP technologies that affect the accessibility of OWP features, and work with other organizations or groups to assist in resolving those issues where needed

Current focus

See also the i18n WG project radar.

Reviews, discussion & advice

  • ongoing work, driven by Working Group activity

Developer guidelines

  • Encoding spec
  • Character Model for the World Wide Web: String Matching & Comparison (charmod norm)
  • needs and issues surrounding locale formats on the Web, including Language Tags and Locale Identifiers for the World Wide Web

Requirements

  • Chinese layout requirements, including Simplified & Traditional Chinese, Mongolian, Tibetan, and possibly Uighur
  • Indic layout requirements
  • Korean layout requirements
  • Ethiopic and Arabic/Persian layout requirements projects in preparation

Gap analysis & bridging

  • ruby markup in HTML5 and ruby styling in CSS
  • bidi markup in HTML5
  • Mongolian variant forms
  • vertical text support for CJK and Mongolian
  • support for CSS queries about typographic and layout requirements

Tests

  • Encoding specification
  • CSS & HTML tests, esp. to evaluate new i18n features being developed

Education & outreach

  • Custom Counter Styles for International Content
  • new article development, eg. use of new bidi features, new ruby features, vertical text features, etc
  • ongoing maintenance and updating of existing resources, particularly in light of changes to HTML and CSS
  • translations, conference presentations, MultilingualWeb workshops

Tracking collateral developments

  • Unicode developments
  • font and keyboard developments
  • language technology and localization
  • universal access and URLs

Useful tracking documents

Goals (Usability)

There are three kinds of usability: for the Web developer, for the user and for the implementer.

(See also an old essay of mine [BB]: What is a good standard?)

Usability for the implementer

  • Specifications are easy to read
  • Specifications are consistent with each other in style, structure and vocabulary
  • Specifications have clear examples
  • Specifications explain the necessary algorithms & data structures if they aren't obvious
  • Specifications have a long life: learning new standards every few years is costly
  • The Web Platform is modular: a team of implementers can each work on different aspects, and independent programs can each implement a part and work together (useful metaphors: the Unix pipe line, the mailcap system, plugin architectures)
  • Test suites are comprehensive
  • Test suites are easy to use (automated, if possible)
  • Individual tests are easy to read, to make it easier to determine why a test failed

Usability for the Web developer

  • There is consistency among the various formal languages and APIs
  • Common tasks need little code, uncommon things are still possible
  • Hard things (i.e., hard for most developers), such as i18n, device independence, accessibility, handling network errors, privacy and security, are, as far as possible, automatic and/or enforced
  • There is good documentation (in addition to the specifications)
  • There are good tools (validators, debuggers, simulators, preprocessors, IDEs)
  • There exist good documentation and good tools that are free (even if there also better ones that cost money)
  • There are both simple and advanced languages/APIs (because there are experienced developers, but also occasional and beginning ones)
  • Versions of a language or API are backwards compatible (because at any time on the Web there is a mixture of old and new applications and old and new implementations), or, stated differently: if new features are needed and cannot be added without breaking backwards compatibility, a new technology with a new name (i.e., a new MIME type) must be created
  • The Web Platform is modular: if you develop an application with a team, different team members can work on different aspects
  • Technologies are modular: there are optional parts that you don't have to know, while still being able to make complete applications
  • Things that aren't specific to the Web are done the same way as outside the Web (e.g., same programming languages, same tools, same terminology

Usability for the end user

Usability for the end user is a difficult goal for the creators of technology, because it is ultimately the implementers and, in the case of Web Applications, the Web developers who are responsible for the usability. Even the most well-designed technology, if it is powerful enough, allows people to make horrible applications. Still, W3C can do something:

  • Proven UI models are built-in (see also "Common tasks need little code..." above)
  • Proven UI models are efficient to implement (because speed is an important factor in the user's experience)
  • The metaphors in the languages and APIs correspond to metaphors in the UI, or are easily mapped (because we want end users to become Web developers themselves: The Web is a read-write medium)
  • If a technology has defaults (i.e., everything the developer can omit or forget), they are such that they are most likely to be useful for the end user (e.g., by default data is visible rather than hidden, communications are encrypted rather than cleartext, interaction follows the platform's UI guidelines rather than a fixed style)
  • Data and applications are independent and there are standards for all kinds of data (i.e., when a particular Web Application doesn't work for a user, the user can go to the app store for his platform and usually find some other application that does)
  • All interaction can be automated: the user can let his computer (a "User Agent" or "Intelligent Agent") do the interaction on his behalf, without requiring full AI
  • Technology is stable (new features arrive all the time, but the way you did it ten years ago also still works)
  • Web Applications are well integrated with the desktop on which they run (same mouse gestures, same keyboard shortcuts, cut & paste works, same save-file dialog, same fonts and colors…)

8. Services: Felix, Doug, Wendy

Technical subareas

According to http://www.w3.org/blog/2014/10/application-foundations-for-the-open-web-platform/ , we will take these four areas into account:

  • Web payments
  • Annotations
  • Social Web
  • Web of Data
  • Digital marketing/advertising?

Observations

There is a plethora of technologies to realize services. Some of these are part of the OWP; most are not. The four technical subareas of W3C normally are not associated with services on the Web, see e.g. http://en.wikipedia.org/wiki/Web_service : A Web service is a method of communication between two electronic devices over a network. This excludes the human in Web payments, Annotations, and Social Web. In Web of Data it excludes the question: who writes the data query?

A more complete inventory of each Foundation

One has to review the existing service technology stacks, which are spread across organizations, e.g. in the XML realm with a focus on OASIS. How do users and developers come into play?

Mapping to native platform

Analyse how services relate to native. This has to be specific to the subarea. E.g. in the Web of data there are selected competitors to our linked data tech. stack like ODATA. How can we bring the stakeholders behind this (e.g. SAP) on board again, without loosing the focus on developers and users?

The whole topic of services could be integrated by taking a usability approach: how can services be defined that they are easy to use by the end users and developers? That approach relates to cross domain W3C work areas like accessibility and internationalization (e.g. language of data descriptors may be a hindrance for working with a data set, see this example query against Japanese dbpedia: http://tinyurl.com/lkco6a9 ). Usability has two sub aspects: the graphical user interface and the software interface. The latter closely relates to the service technology stack developers are used to.

Evangelizing with colleagues and dependency mapping

Like the service subareas, colleagues working on them are spread across areas (e.g. W3C domains). A first step to tackle this challenge is to engage with them in conversations asking questions like: What are you primitives for services? What are you main related application foundations? Where is a gap in the OPW for building the relation?

Work plan

  • Feb 15: identify use case aspects that the four service areas have in common and that are different
  • Feb 23: identify native ways to realize the four service areas, check if there are use cases covered only by native
  • Feb 23: identify communities to involve (including both Web developer (sub) communities and industries not yet engaging in W3C
  • March 02: propose how to make services useable and accessible to everyone
  • March 15: List of prioritized use cases
  • March 15: Review of capabilities of native platforms in this space
  • March 15: Map of use cases to Web technologies
  • April 15: Proposed prioritization of actions for staff / WG with suggestions for additional resources investment
  • April 24: Report for progress on application foundation due for AC meeting
  • May 5: AC meeting starts

Feature Matrix

One of the distinguishing characteristics of a service is that it's a layer of abstraction for features to which a developer can delegate for additional functionality; this is desirable because it can encapsulate features that are complex, hard to get right, easy to get wrong, and frequently outside the expertise of the average developer. The service can be a software module or a third-party cloud-based service which may broker relationships and transactions with other services. This encapsulation limits exposure to unnecessary information (a la capabilities), and thus limits attack surfaces and liability.

Some services may be more foundational, while other may build on top of other foundational services.

The table below aims to identify patterns that characterize various services, to help in finding a useful level of abstraction.

  • ✓ Usually
  • ◐ Sometimes
  • ✘ Rarely


Service/Feature Identity Privacy Security Provenance Multi-party Publication Storage Federation
Web payments ✓ ✓ ✓ ✓ ✓ ✘ ✘ ✘
Web annotations ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Social Web ◐ ✓ ✓ ✓ ◐ ✓ ✓ ✓
Data Web ◐ ✓ ✓ ✓ ◐ ✓ ✓ ✓
Retrieved from "https://www.w3.org/wiki/index.php?title=Application_Foundations_all&oldid=80688"