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
- Social Web
- Web of Data
- Digital marketing/advertising?
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?
- 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
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