w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Core Mission and W3C Activities
The results of this questionnaire are available to anybody.
This questionnaire was open from 2010-06-11 to 2010-06-17.
10 answers have been received.
Jump to results for question:
- Graphics
- HTML
- Internationalization
- Math
- Rich Web Client
- Style
- Synchronized Multimedia
- Video In the Web
- XForms
- Fonts
- eGovernment
- Privacy
- Security
- Semantic Web
- Web Services
- Mobile Web Initiative
- Multimodal Interaction
- Ubiquitous Web Applications
- Voice Browser
- XML
- WAI International Program Office
- WAI Technical
- Model-based User Interfaces
- Semantic Sensor Network
- Social Web
- Open Web Education
- Provenance
- MashSSL
- Decisions and Decisions-Making
- Audio
- Library-Linked Data
1. Graphics
SVG, WebCGM.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 8 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Graphics | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | Core: graphics formats and APIs that are intended for the public Web and that are natively supported in browsers or that are intended to be natively supported in browsers. Not-for-W3C: graphics formats and APIs that are not intended for the public Web, and/or not natively supported in browsers, and/or not intended to be supported in browsers. SVG is core, WebCGM is not-for-W3C. |
| Dave Raggett | Part of Standards Core Web | SVG support is now widespread and will soon be even more so with IE9. SVG and Canvas are complementary, but we shouldn't limit ourselves to 2D, and networked 3D should be within scope. W3C is a caring parent for WebCGM for historical reasons, but it isn't core. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | Until recently, I would have put SVG into the NCStP3CCsho category but only because the Web needs a pictorial format. Ever since the cave days we've had symbolic and illustrative representation (words and pictures), and one of the core objectives of the Web is to link such representations together. We've also had audio communication (since the days of grunting) but it's only recently that we've been able to capture grunting in any semi-permanent manner, so I don't give it as high a priority (apologies to those who benefit by its added accessibility). As for video... I was tempted to describe SVG as non-core only because adoption has been a problem in the browsing world, but the days of plug-ins are numbered so it might be time for SVG to shine (or have some suitable gradient with a bright endpoint). When SVG is really an off-the-shelf batteries-included feature of everything, it will be truly Core, and that day might not be far off. |
| Doug Schepers | Part of Standards Core Web | SVG is part of Standards Core Web, WebCGM is Non-Core Standard that W3C should not work on. WebCGM is a niche market with a very few controlling vendors, and could and should be replaced by the judicious addition of a small number of features to SVG. |
| Thomas Roessler | Part of Standards Core Web | SVG, clearly. WebCGM probably more in the non-core, pragmatic category. |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web |
2. HTML
HTML, XHTML.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 10 |
| Candidate for Standards Core Web | |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on |
Details
| Responder | HTML | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | Core: any (X)HTML-related specifications/technologies that are intended to be implemented natively in browsers. Non-core: any (X)HTML-related specifications that are not intended to be implemented natively in browsers or that do not have an conformance criteria relevant to implementation is browsers. So XHTML Modularization is non-core (and also a standard that that the W3C should not work on). |
| Dave Raggett | Part of Standards Core Web | HTML enjoys massive use as the document format for visual web pages. It reflects the tumultuous history of the Web's evolution and as such is messy. XHTML is popular given the success of XML, and with IE9's improved support we may see XHTML as an increasingly important MIME type, although text/html will be with us for decades yet. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Part of Standards Core Web | HTML yes. XHTML is something that we did to HTML, probably for valid reasons at the time, and with plenty of good intentions but maybe we took on a bit too much. The world wasn't ready. Probably still isn't. Maybe we've learned a few good lessons from XHTML and can apply them in a way that will make HTML better. HTML is, and will be for a very long time, a Core standard. |
| Doug Schepers | Part of Standards Core Web | |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | Critical component to enable Web usage |
3. Internationalization
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 8 |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Internationalization | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | I'm not sure what is meant by this topic. Most of the topics on the survey are technical topics. Internationalization as a broad theme may have components that are part of the Core, and other components that are outside the Core. |
| Michael[tm] Smith | Part of Standards Core Web | Internationalization is an abstract concept, not a specific technology. But it is a core part of most W3C technologies, and needs to remain so. What is core about internationalization are the parts of any specifications that define specific implementation-conformance requirements related to internationalization. Any internationalization work that is not connected to defining specific implementation-conformance requirements related to internationalization is not core. |
| Dave Raggett | Part of Standards Core Web | The Web is global and as such can't afford to ignore the needs for supporting the languages of many languages and cultures. To do otherwise would fragment the Web core standards in the long run. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Non-Core Standard that pragmatically W3C should work on | There is always the danger that the Web will be developed in a way that only benefits a select portion of the world's population. We have a responsibility to be fair to humanity, especially when dealing with a resource that has such a profound impact on the world, and which has such enormous potential. Being able to communicate to the vast majority of the global population should be a key objective. The Web should be enabled to meet this objective. However, we must not be so arrogant as to assume that the W3C has a monopoly on i18n. The truth is that the W3C does not represent the world population. While it has members who are experts in the field, there are many others outside. Perhaps there needs to be a separate entity charged with dealing with i18n representational issues, to take the current W3C i18n work, Unicode and more. So long as it gets done, that's what matters. It does not matter if it gets done by W3C, and perhaps some might say that perhaps it shouldn't be done by W3C, given its current "Western" focus. |
| Doug Schepers | Part of Standards Core Web | |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | We need a single Web so it has to be international |
4. Math
MathML.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 4 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | 4 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Math | Rationale |
|---|---|---|
| Jeff Jaffe | Non-Core Standard that pragmatically W3C should work on | |
| Michael[tm] Smith | Part of Standards Core Web | Core: any parts of math-related formats and APIs that are intended for the public Web and that are supported in browsers or that are intended to be supported in browsers. |
| Dave Raggett | Candidate for Standards Core Web | Western popular culture is uncomfortable with science and engineering, despite the fact that the modern World is completely dependent on the successes in these spheres. Math is the lingua franca of science and engineering, and browser support for MathML is slowly improving, and will in time become a core part of the Web, and an everyday tool for education and scientific literacy. Why does this effect W3C? The answer is the need to tightly couple math, html and svg as part of web applications. |
| Daniel Dardailler | Non-Core Standard that pragmatically W3C should work on | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Non-Core Standard that pragmatically W3C should work on | I really really hate saying no to Math, especially as a qualified mathematician. But the truth is that the representation of math is a vertical domain, and perhaps it needs a different home. Maybe the people behind Mathematica could take over? (What? A commercial entity take over? Is that a problem??) It needs to continue. I'm just not so sure that W3C has to be the one carrying it. |
| Doug Schepers | Part of Standards Core Web | |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that pragmatically W3C should work on | We have MathML. Further refinement does not seem like a good use of scare resources |
5. Rich Web Client
CDF, WebApps.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 9 |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Rich Web Client | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | Core: any APIs that are intended for the public Web and that are supported in browsers or that are intended to be supported in browsers. IMHO, CDF should never have been put into the same category as WebApps (APIs for Web applications) to begin with, and should not remain in it. And CDF -- or any other general mechanisms for creating compound documents that do not have any likelihood of ever being supported natively in browsers -- is non-core/W3C-should-not-work-on. |
| Dave Raggett | Part of Standards Core Web | The Web is so much more than static documents. Web applications are dependent on standard interfaces and interoperable support for compound document formats. We are still at an early stage in realizing the potential, witness the discussions over integrating HTML and SVG. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | The Web has moved on, and is now a key element in the way our society interacts, and here I mean specifically "dynamic interaction". The Web is alive. Describing many sites as "Web Pages" is such a misnomer these days. They are often points of interaction. Assuming W3C wants to pursue the dynamic aspects of the Web, and not just static representation of resources, then WebApps will be core. |
| Doug Schepers | Part of Standards Core Web | CDF as a specification may not ever be relevant, but the contents of the spec can and should be included in SVG+HTML integration. |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | The Web is turning into a Web of Applications. We need to spearhead this effort. |
6. Style
CSS.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 9 |
| Candidate for Standards Core Web | |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Style | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | |
| Dave Raggett | Part of Standards Core Web | CSS has proved its worth as developers have come to realize the importance of being able to separately maintain styling from the document structure. There is a long way to go to fully realize the potential for separating out different design concerns for web application developers. CSS is not the end, but rather just the beginning of this journey. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Part of Standards Core Web | Yes, of course, but even Bert would say it needs some work. While we've been having some success getting people to implement the page markup features (almost) fully, there's a long way to go to encourage full implementations of CSS. Still, from experience to date, this one is worth getting right. |
| Doug Schepers | Part of Standards Core Web | CSS needs to be better integrated into the core web stack, including treatment of use-cases for webapps, and the scripting/eventing context. |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that pragmatically W3C should work on | In my view all we need in a low-level maintenance activity. |
7. Synchronized Multimedia
SMIL.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 4 |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | Synchronized Multimedia | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Any further work on synchronized multimedia should be done by including it other relevant specs; for example, in the CSS specs, HTML5, WebApps specs, SVG spec, etc. The SYMM WG should not be re-chartered after its current charter expires, and its charter should not be extended, and we should not start any new work on Synchronized Multimedia that is not targeted primarily for being natively supported in browsers. |
| Dave Raggett | Candidate for Standards Core Web | SMIL has not enjoyed huge success as an XML format, but its timing model is of great value for multimedia and animation, e.g. its adoption by SVG. I see SMIL as providing an architectural component rather than as a syntax. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | Non-Core Standard that W3C should not work on | It's lovely stuff, and opens up a lot of interesting possibilities, but there are already plenty of holes in the existing "bedrock" that perhaps SyncMM could be done elsewhere without causing us to disintegrate. |
| Doug Schepers | Candidate for Standards Core Web | We need to retain the core aspects of SMIL, such as the animation sandwich model, but the rest needs to be reexamined for suitability to the current implementation environment. |
| Thomas Roessler | Candidate for Standards Core Web | not quite sure how much it's used and how closely it's tied to core work |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | Seems important but really don't know enough about this. |
8. Video In the Web
Media fragments, Media Annotation, Timed Text.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 7 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Video In the Web | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | Core: any video-related formats and APIs that are intended for the public Web and that are natively supported in browsers or that are intended to be natively supported in browsers. Not-for-W3C: any video-related formats and APIs that are not intended for the public Web, and/or not natively supported in browsers, and/or not intended (from the earliest design stages of their specifications) to be supported in browsers. TTML/DFXP is not core and not further work on it should be done on it at W3C, unless that work is to replace it with something that browsers are willing to implement, and we get commitment from browser vendors to participate in its development. Also, maybe it's time we consider making this work "Video and Audio on the Web". |
| Dave Raggett | Candidate for Standards Core Web | Video is is a medium just as photographs are. Both are popular with users and W3C should strive for interoperability. Historically, W3C has been neutral on required support for media formats, leaving this to market forces, but perhaps we should do more! Our work on related standards is important for realizing the potential. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Non-Core Standard that W3C should not work on | More really lovely stuff, but video is very much a separate specialization that brings with it all kinds of issues right through the entire network/OS/App stack. The core Web standards should abstract the existence of Video and let the video specialists get on with their brand of magic on the other side of the fence. W3C should not get involved in any video technology that requires more than out-of-the-box browsers are likely to support. |
| Doug Schepers | Part of Standards Core Web | Critical technology, but flawed in its current approach. See SMIL. |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Candidate for Standards Core Web | Seems like a good extension for a richer Web experience. |
9. XForms
Forms.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 1 |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 3 |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | XForms | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Not-for-W3C unless/until we have any browser implementors who are interested in supporting it natively. |
| Dave Raggett | Non-Core Standard that pragmatically W3C should work on | Separation of concerns is a key to reducing costs for developers, but not a driver for browser vendors. W3C has to look after the needs of many different constituencies, and this requires a balancing act, and a eye to the future. We should support work aimed at interoperable authoring tools, as well as new delivery formats that can evolve independently of text/html. Rich forms are a good test case. |
| Daniel Dardailler | Candidate for Standards Core Web | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | Non-Core Standard that W3C should not work on | Always admired XForms, but there's a nagging feeling that perhaps an improved forms mechanism within HTML 5 might get more traction, and therefore be of more general benefit. So continue work on forms within the context of HTML, learning from the XForms experience. |
| Doug Schepers | Candidate for Standards Core Web | In it current incarnation, too politically unpopular for us to push to browser vendors. We should take the lessons learned and apply specific parts of XForms to particular pragmatic use cases, such as spreadsheet formulae and data binding. |
| Thomas Roessler | interesting case -- we once thought it was core (i.e., whatever a priori criteria we come up with should answer "yes" to it), but it's probably moved out more to the fringe now, given how the platform has evolved. | |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that pragmatically W3C should work on | Low-level maintenance is all that is needed |
10. Fonts
WebFonts.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 5 |
| Candidate for Standards Core Web | 4 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Fonts | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | |
| Dave Raggett | Candidate for Standards Core Web | Need for interoperable treatment of fonts as superior alternative to embedding text in images. This has a impact on improved search, effective delivery on different kinds of displays, and accessibility. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | In line with the importance of textual representation, the common support of language glyphs is important. Machine reading, assistive technology, search technology etc., all depend on the ability to represent our language without resorting to drawing the symbols. Without flexible fonts, it will still be possible to make Web pages that look good and can be read easily by people, but perhaps it will only be people that can read them, and that will diminish what we might be able to do otherwise. |
| Doug Schepers | Part of Standards Core Web | |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that pragmatically W3C should work on | Low-level maintenance is all that is needed |
11. eGovernment
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | 5 |
| Non-Core Standard that W3C should not work on | 3 |
Details
| Responder | eGovernment | Rationale |
|---|---|---|
| Jeff Jaffe | Non-Core Standard that pragmatically W3C should work on | s/eGovernement/eGovernment/. Maybe there should be a fifth choice above. The User task force is looking at what we do for Verticals. Verticals are not what I would call "core" - but by having a TF on "Users", we are being clear that certain verticals should be addressed by W3C. Ralph is answering that question. |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | I understand why the eGov work is important, but I think ideally it should take place in a different organization -- not the same organization where focused work on browser technologies takes place. Pragmatically speaking, I can also understand why it's not likely to be separated out. |
| Dave Raggett | Non-Core Standard that pragmatically W3C should work on | Transparency in government is of high value to society, and W3C's involvement in this will help to drive work on core Web technologies relating to data integration and search. |
| Daniel Dardailler | Non-Core Standard that pragmatically W3C should work on | |
| Sam Ruby | Non-Core Standard that W3C should not work on | |
| Rotan Hanrahan | Non-Core Standard that W3C should not work on | While we should encourage government engagement in Web technology, given the potential for governments to better serve their people through the Web, this is really a vertical space that could be done elsewhere. Finding somewhere will be a challenge. |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | |
| Thomas Roessler | Not core standards work, but outreach and community building around standards. Technical core work? no. But really important outreach for our technologies, with a likely shift towards Linked Government Data, and sector-specific ontologies for that area. Ill-formed question. | |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that W3C should not work on | Not our business. Govt. should take care of what is necessary. |
12. Privacy
Policy languages.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 4 |
| Candidate for Standards Core Web | 5 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Privacy | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | Policy languages are probably in the Core. Privacy as a broad topic is much broader than Core. |
| Michael[tm] Smith | Part of Standards Core Web | Non-core-at-all: Policy languages or any other privacy-protection mechanisms that don't have buy-in from browser implementors and/or that are not intended to be implemented natively in browsers. Privacy protecgion is an abstract concept, not a specific technology. But it is a core part of most W3C technologies, and needs to remain so. What is core about privacy protection are the parts of any specifications that define specific implementation-conformance requirements related to privacy protection. Any privacy work that is not connected to defining specific implementation-conformance requirements related to privacy protection is not core. Privacy-protection mechanisms related to browser technologies should be built directly into all relevant specs (e.g., HTML5, WebApps specs, etc.). |
| Dave Raggett | Candidate for Standards Core Web | The Web is transforming how information is collected along with the potential for harming individuals. Whether you live in a free society or one where there is a lack of regard for human rights, privacy matters. We are still at a very early stage when it comes to understanding how to best integrate support for privacy, but this has to be a key aspect of the core Web standards. Note that security, trust and identity go hand in hand with privacy! |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | Not sure about this one, but if we limit ourselves to the means of facilitating proper awareness of privacy issues through technological means (e.g. the representation of privacy policies) then since the Web encourages people to potentially engage the whole world, it's right that we support the means to represent aspects of privacy. The politics, sociology etc., is another matter that we should leave to others. |
| Doug Schepers | Candidate for Standards Core Web | |
| Thomas Roessler | Another difficult one: The privacy activity goes back to the roots of W3C, and historically is a "core" piece of our work. However, it's more recently focused on research (through PrimeLIfe) and community building, so it's not core standards work right now. The question here goes to the core of the "and society" part of T&S: W3C has, traditionally, a societal perspective on its technical work. Having the capability to be part of that dialogue is a core capability of W3C. However, it does not imply that having a separate standards activity that's active in the space is "core." I.e., the question is ill-formed. | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | To the man on the street privacy and security are what is most important. |
13. Security
Web Security Context, XML Security.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 7 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Security | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | XML Security is part of the Core. Security as a broad topic certainly has things that are outside the Core. |
| Michael[tm] Smith | Part of Standards Core Web | Non-core-at-all: Security-related specifications that don't have buy-in from browser implementors and/or that are not intended to be implemented natively in browsers. Security is an abstract concept, not a specific technology. But it is a core part of most W3C technologies, and needs to remain so. What is core about security are the parts of any specifications that define specific implementation-conformance requirements related to security. Any security work that is not connected to defining specific implementation-conformance requirements related to security is not core. Security mechanisms related to browser technologies should be built directly into all relevant specs (e.g., HTML5, WebApps specs, etc.). |
| Dave Raggett | Part of Standards Core Web | Security is better understood than privacy, and as such we are further along the path with security as part of core web standards. The same origin policy was a useful stepping stone, but is no longer adequate. Note that security, trust and identity go hand in hand with privacy! |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | There is much that the Web simply could not do without the assurances of secure communication, interaction, authentication etc. The Web removes you from direct contact, removes you from certain basic security mechanisms that society has built up over the millennia. So the Web needs to provide alternatives to ensure we have means of providing trust. Should it be W3C that does it? If we can attract the right expertise, yes. Otherwise, we will *need* to find this a home. |
| Doug Schepers | Part of Standards Core Web | |
| Thomas Roessler | Non-Core Standard that pragmatically W3C should work on | WSC was an experiment that was close enough to Core Web; it's wrapping up now. XML Security is as core or not as the overall XML work; the work (a) serves to keep the specifications up to date, and (b) looks into some more speculative directions to address issues that we've learned about. It's an example of almost-maintenance work. |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | To the man on the street privacy and security are what is most important. |
14. Semantic Web
OWL, SPARQL, Rules, RDFa, HealthCare, RDB2RDF.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 7 |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | 2 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Semantic Web | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | I understand why the SemWeb work is important, but I think ideally it should take place in a different organization -- not the same organization where focused work on browser technologies takes place. Pragmatically speaking, I can also understand why it's not likely to be separated out. |
| Dave Raggett | Part of Standards Core Web | The Semantic Web technologies are key to data integration and search on a Web scale. You can also think about this as logical progression from relational database technology, with greatly improved data models that work across vocabularies and servers. W3C could attract much greater levels of involvement by focusing of the potential for solving the challenge of data integration in enterprises and governments. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Part of Standards Core Web | There is so much going on here. The potential is huge. But we have not figured out (yet) how to make it go truly mainstream. However, we shouldn't be doing verticals (e.g. health care). |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | |
| Thomas Roessler | Part of Standards Core Web | HealthCare is, like eGov, an application area in which we do sector-specific outreach; it's not core work, but work that we should pragmatically take on. RDB2RDF, SPARQL, RDFa, OWL each address core pieces of the web of data. |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Candidate for Standards Core Web | Yes, we need to help the Semantic Web get stronger. Not clear how much we need to do and how much others will/can do. |
15. Web Services
SOAP-JMS, Policy, Resource.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 1 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | 6 |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Web Services | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | The whole split of Web services between W3C, Oasis, and others (DMTF?, WS*) is unclear to me. I'm comfortable with items under our guidance today, but would rather have a clearer picture of the entire space. |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | I understand why the WS work is important to some W3C members, but I think ideally it should take place in a different organization -- not the same organization where focused work on browser technologies takes place. Pragmatically speaking, I can also understand why it's not likely to be separated out. |
| Dave Raggett | Non-Core Standard that pragmatically W3C should work on | The complexity of the Web Services stack has limited its adoption beyond the enterprise. We should consider ways to spin this work off to other standards organizations, but there are pragmatic grounds for our continuing involvement. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | Non-Core Standard that pragmatically W3C should work on | We made WS over-complicated. We should only have a basic mechanism, and let others layer the complexities on top. |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | To be honest, I don't know enough about this. |
| Thomas Roessler | Non-Core Standard that pragmatically W3C should work on | This work is mostly wrapping up. |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that W3C should not work on | The requisite standards are in place or almost in place. |
16. Mobile Web Initiative
Best Practices, Social Development.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 3 |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 2 |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | Mobile Web Initiative | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | Mobile Web in general is certainly part of Core. Here, you've only listed "Best Practices and Social Development". Some I'm not sure what the scope of this item is. |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Work on addressing use cases and requirements related to browsing the Web on mobile devices be built directly into all relevant core specs (e.g., HTML5, WebApps specs, etc.). |
| Dave Raggett | Non-Core Standard that pragmatically W3C should work on | The blossoming of mobile access to the Web is being helped by W3C's work in this area. The core web standards shouldn't be limited to mobile devices, but that said, mobile is driving the development of interfaces for web applications to access device capabilities, and as such the start of what will become the Web of Things. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | Despite being a mobile specialist, I'm only putting this up as a candidate for core. Instead, I think we need something more generic. Something to deal with browser diversity and context, rather than focussing purely on mobile. Sure, mobile currently exhibits the biggest diversity and the greatest scope for context, but we might yet find this with wearable Web, embedded Web, tangible Web etc. There are a few technologies that we have started for mobile (context APIs, vocabularies, ontologies) that can be expanded for all the Web, and there are some efforts (e.g. Best Practices) that are specific to mobile. The BPs have the most obvious immediate benefits, but the former are long-term visions that might yet be adopted as Web Core. |
| Doug Schepers | Non-Core Standard that W3C should not work on | Some great work has come out of this, and Dom and Matt are amazing (I'm sure others are doing great work too, but those 2 stand out), but dividing the Web into desktop and mobile seems quaint at best in 2010. Why keep pretending that they are different? |
| Thomas Roessler | Non-Core Standard that pragmatically W3C should work on | I'm not sure I'd call the best practices work "core web" standardization from a technical perspective -- however, it was a piece of the puzzle of getting the mobile sector on board with core Web standards. Likewise, the social development work is about how to deploy web technologies in an important area of the Web. |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | Mobile access as a seamless Web experience is important. |
17. Multimodal Interaction
InkML, EmotionML, EMMA.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | |
| Candidate for Standards Core Web | 6 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | Multimodal Interaction | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Multi-modal mechanisms related to browser technologies should be built directly into all relevant core specs (e.g., HTML5, WebApps specs, etc.). |
| Dave Raggett | Candidate for Standards Core Web | Multimodal interaction is quietly making its way into mobile applications. The Web should not be fundamentally limited to visual interaction, and W3C needs to support its members interest in evolving the core web standards to support multimodal interaction. This is happening in an incremental way and the resources devoted to this work need to be commensurate with the benefits. |
| Daniel Dardailler | Candidate for Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | Increasing browser diversity is seeing a corresponding growth in MMI potential and it is having a profound effect on the relationship between people and the Web. Hopefully the MMI technologies will continue to evolve and will become part of the normal Web experience. |
| Doug Schepers | Non-Core Standard that W3C should not work on | I think InkML has a lot of potential, but it should be integrated better into the mainstream of W3C's work on web tech. From what I know of EMMA, it is an alternate framework that is interesting, but again divides our attention in a way we can't afford. |
| Thomas Roessler | I know too little about this work to give a useful answer. | |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Don't know enough about this. |
18. Ubiquitous Web Applications
Device API, Geolocation.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 4 |
| Candidate for Standards Core Web | 5 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Ubiquitous Web Applications | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | I agree that Device API and Geolocation are part of the Core. This is listed under a broader topic of Ubiquitous Web Applications. It is not at all clear that all ubiquitous web applications are in core. |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | "Ubiquitous Web Applications" is an amorphous abstract term and is not itself core. The Geolocation API work is core. Also care are any parts of Device API work that are intended for the public Web and that are supported in browsers or that are intended to be supported in browsers -- and for which we have discussions in which browser implementors are actively taking part. |
| Dave Raggett | Part of Standards Core Web | Interfaces for accessing device capabilities, especially location are becoming more and more important. One concern is that we may end up with a mess of APIs due to piecemeal development. |
| Daniel Dardailler | Candidate for Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Candidate for Standards Core Web | Not sure about this one. We need three forms of device API: 1) the ability for a device to inspect its own state, 2) the ability for a Web server to inspect the current state of a device, and 3) the ability for a Web server to discover the characteristics and potential states of a device. We've already solved number 3. Number 2 is being worked on by the likes of the OMA. So that brings us to number 1, a device inspecting itself. Geolocation is one such API, and this is probably core. What is important is to ensure that the representation of contextual information is compatible across all three API classifications, and this is where vocabularies and ontologies would help. So far we have only been able to work out vocabularies. Ontologies are harder, but given the breadth of application, W3C is the most appropriate place to do this. |
| Doug Schepers | Part of Standards Core Web | Device API and Geolocation are core. But again, see MMI... let's stop pretending these are separate from the desktop/mobile/device browser world in any sense but one of organizational details. This could happen under the Interaction Domain, for all intents and purposes. |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Candidate for Standards Core Web | Seems important. Not sure. |
19. Voice Browser
VoiceXML.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 2 |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 5 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | Voice Browser | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | VoiceXML is not itself core at all. And while I understand we have some member support for the Voice Browser work, I don't think it should be considered core work. |
| Dave Raggett | Candidate for Standards Core Web | The telephone remains an everyday device for communication with people and services, just as the visual web browser has become. Web technologies have colonized call centers, but we have yet to see the same kinds of links between voice based applications that we see with the visual web. Voice based search is growing in popularity with lots of investment by key players. In the long run, multimodal technologies will bridge the gap between the visual and voice webs. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Non-Core Standard that pragmatically W3C should work on | I see the voice work as a vertical space that should be slowly moved into a separate industry activity, maintaining contact with W3C but ultimately taking responsibility for its own evolution. |
| Doug Schepers | Candidate for Standards Core Web | Needs tighter integration into graphical browser tech, which I believe is their goal. |
| Thomas Roessler | Non-Core Standard that pragmatically W3C should work on | (Unfortunately, the survey doesn't permit undoing a selection. What I'm giving here is really a gut feeling based on the amount of [likely] deployment of this sort of work on the "traditional" Web; ultimately, I don't know enough about it to make a clear statement.) |
| Jace Voracek | Non-Core Standard that pragmatically W3C should work on | |
| Ashok Malhotra | Non-Core Standard that pragmatically W3C should work on | I am be mistaken but I think there is a standard and all we need is maintenance. |
20. XML
EXI, XML Core, XProc, Query, Schema, XSL.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 7 |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | XML | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | I understand why various XML specs developed at the W3C are important, but I think ideally that work on them should take place in a different organization -- not the same organization where focused work on browser technologies takes place. Pragmatically speaking, I can also understand why it's not likely to be separated out. |
| Dave Raggett | Part of Standards Core Web | XML has proven its worth as a core standard for information transfer and storage. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | Part of Standards Core Web | The XML specs are core. The technologies that then depend on the XML specs are not necessarily. In fact, most of them are not. If I were to narrow further, I'd see XML Core and Schema as the ring-fenced core technologies. |
| Doug Schepers | Candidate for Standards Core Web | EXI, especially since it can be used with any language described by a schema (like HTML5), should be of broad interest. XSL is not used enough, but actually appeals to many CSS-minded folk... needs better marketing, maybe? XML needs a revision, but is critical to W3C's mission. I can't speak to the others. |
| Thomas Roessler | Part of Standards Core Web | "The XML Stack." |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that W3C should not work on | The XML Standards are pretty much done. We should not spend additional resources on them. |
21. WAI International Program Office
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 3 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | 2 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | WAI International Program Office | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | |
| Dave Raggett | This is the people who are helping W3C to drive work on accessibility. | |
| Daniel Dardailler | Non-Core Standard that pragmatically W3C should work on | |
| Sam Ruby | Part of Standards Core Web | |
| Rotan Hanrahan | This isn't Standards Core, it's just Core. | |
| Doug Schepers | Candidate for Standards Core Web | I don't know what this is... |
| Thomas Roessler | Part of Standards Core Web | For this one (as for the other WAI related pieces), part of W3C's identity and value proposition has been built around having a view of the accessibility of its core work. There's probably a long (and intense) argument to be had whether it's a core function of W3C by first principles. My take is that we count it as a core function. |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Don't know enough about this. |
22. WAI Technical
Authoring Tool, Protocols and Formats, User Agent, Web Content.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 6 |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | 2 |
| Non-Core Standard that W3C should not work on |
Details
| Responder | WAI Technical | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | Accessibility is an abstract concept, not a specific technology. But it is a core part of most W3C technologies, and needs to remain so. What is core about the accessibility work are the parts of any specifications that define specific implementation-conformance requirements related to accessibility. Any accessibility work that is not connected to defining specific implementation-conformance requirements related to accessbility is not core. Accsessibility mechanisms related to browser technologies should be built directly into all relevant specs (e.g., HTML5, WebApps specs, etc.). |
| Dave Raggett | Part of Standards Core Web | Critical work on ensuring that core Web standards support accessibility. |
| Daniel Dardailler | Part of Standards Core Web | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | Part of Standards Core Web | As part of oversight on many other parts of W3C, the specifications and guidelines of WAI are enormously useful, not just to those who benefit most directly from accessibility. We all benefit. |
| Doug Schepers | Part of Standards Core Web | Needs to continue to produce more great technically-focused specs like WAI-ARIA. |
| Thomas Roessler | Part of Standards Core Web | |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Don't know enough about this. |
23. Model-based User Interfaces
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 4 |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | Model-based User Interfaces | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | I need to learn more about this. XG for now? |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Not core by any stretch of the imagination, as far as I can see. |
| Dave Raggett | Non-Core Standard that pragmatically W3C should work on | This has so far taken the form of an Incubator Group and a Workshop. W3C staff are involved in a limited capacity in research projects in this area that aim to greatly reduce the costs for developing multi-platform web applications that can dynamically adapt to the changing context. This has lots of potential for future Web authoring standards. |
| Daniel Dardailler | Non-Core Standard that pragmatically W3C should work on | What's the diff with Multimodal, xform model ? |
| Sam Ruby | Non-Core Standard that W3C should not work on | |
| Rotan Hanrahan | Non-Core Standard that pragmatically W3C should work on | This has huge potential, but it's got a medium- to long-term vision and might evolve into work outside of W3C. We should keep an eye on it, and decide eventually whether we want it to become core, or let it have a life of its own. |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | Interesting stuff, but we'd need to make sure we have a sufficiently large and engaged community to drive it forward. Unless we find a funding source for it, probably not a good use of Team resources, unless we do a 20% project thing, like some big companies. |
| Thomas Roessler | Candidate for Standards Core Web | Speculative work that could eventually lead to a better authoring environment. Might end up core, might end up fringe. |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Don't know enough about this. |
24. Semantic Sensor Network
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | |
| Candidate for Standards Core Web | 4 |
| Non-Core Standard that pragmatically W3C should work on | 4 |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | Semantic Sensor Network | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | I need to learn more about this. XG for now? |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Not core by any stretch of the imagination, as far as I can see. |
| Dave Raggett | Non-Core Standard that pragmatically W3C should work on | Incubator Group focusing on stimulating shared models for sensor networks. Incubator Groups provide a lightweight way for W3C members to collaborate as a precursor to work on standards. In this case, an incremental step towards realizing the potential for the Web of Things, and focusing on Semantic Web technologies. What limitations should W3C place on the scope of XG's? |
| Daniel Dardailler | Non-Core Standard that pragmatically W3C should work on | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | Non-Core Standard that W3C should not work on | This is a vertical space. W3C should be involved only to the extent of facilitating some incubation, but ultimately it should be done elsewhere. |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | Interesting, if we have the right stakeholders. |
| Thomas Roessler | Candidate for Standards Core Web | Massive data (and sensor networks) will eventually form an important applicatin area for the Semantic Web. AGain, this is an incubator that explores an area, hence Candidate. |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Candidate for Standards Core Web | This may help other kinds of data find its way onto the Web. But, not sure exactly what the direction is. |
25. Social Web
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 3 |
| Candidate for Standards Core Web | 4 |
| Non-Core Standard that pragmatically W3C should work on | 2 |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Social Web | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | I don't know whether we will ever define all standards for the Social Web, but I believe that some number of them will intersect W3C. It is key to this effort to define what parts are best done in W3C and which parts are best done outside of W3C. |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | Social Web is an abstract concept, and I unless/until we have specific technologies to consider that are related to social-web use cases and requirements, I don't think we should be spending any resources on it. |
| Dave Raggett | Candidate for Standards Core Web | The Web is used by vast numbers of people to socialize with one another. So far this has mostly been done within walled-gardens, but Web standards will be essential for distributed multi-vendor solutions. This is strongly related to work on privacy, trust, identity and security. This will lead to work on core web standards. |
| Daniel Dardailler | Candidate for Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Non-Core Standard that pragmatically W3C should work on | There's a lot of Web technology happening in this domain. However, it remains to be seen if a specific need arises that would need addressing directly by W3C. The potential is great, so it is worth being somewhat involved. |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | Interesting and powerful, if we have the right stakeholders. We have yet to see if there are technical specs we need to work on, like a Social API... if so, this could be a candidate for core web, but even if not, we should still work on this not only in the abstract, but also as an applied principle with how we conduct our core mission: we need to have a much better set of community tools, and to understand the dynamics of community involvement. |
| Thomas Roessler | Part of Standards Core Web | Outreach to the Social Web community. This group surveys technologies around us, some of which we'd probably count as core web standards, some of which we probably wouldn't. |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web | Many predict that this is the direction that the Web will grow in. |
26. Open Web Education
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 1 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | 4 |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Open Web Education | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | Another broad topic that requires more definition. |
| Michael[tm] Smith | Non-Core Standard that pragmatically W3C should work on | Education and outreach are important parts of increasing adoption of our technologies and getting a better return on investment for the resources we spend on technical work. |
| Dave Raggett | This is about engaging with the developer community including courses for school students and beyond. Such engagement will make it easier for people to bring standards work to W3C, and will put pressure on vendors to support standards for increased interoperability. | |
| Daniel Dardailler | Non-Core Standard that pragmatically W3C should work on | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | This isn't a Standards item, but it is an essential activity as it's a key means of ensuring that the work of W3C is effective. Won't rate it here, as the ratings are not appropriate. | |
| Doug Schepers | Part of Standards Core Web | Missing third pillar of W3C: 1) high-quality technical specifications (and the Process) 2) industry participation (financial support, implementations, feedback, engineering resources) 3) information dissemination and educator/student buy-in to our constellation of deliverables (including accessibility, i18n, markup and APIs, etc.) |
| Thomas Roessler | Non-Core Standard that pragmatically W3C should work on | Not standards work at all, but important education and outreach. The question is ill-formed for this one. |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Non-Core Standard that W3C should not work on | Others can and want to do this. |
27. Provenance
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 1 |
| Candidate for Standards Core Web | 2 |
| Non-Core Standard that pragmatically W3C should work on | 3 |
| Non-Core Standard that W3C should not work on | 2 |
Details
| Responder | Provenance | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | Need more information. XG? |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | No idea what this even is. |
| Dave Raggett | Candidate for Standards Core Web | Another Incubator Group. Provenance underpins trust, and as such is fundamental challenge for the Web. |
| Daniel Dardailler | Non-Core Standard that W3C should not work on | Not sure what that is. |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | Need more information. Anything to do with Certs, DigiSigs etc? | |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | Really interesting, if it can be moved to bear fruit in a reasonable timeframe. |
| Thomas Roessler | Part of Standards Core Web | This incubator works on a key missing piece for the semantic web technology stack. |
| Jace Voracek | Non-Core Standard that pragmatically W3C should work on | |
| Ashok Malhotra | Don't know enough about this. |
28. MashSSL
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on | 4 |
Details
| Responder | MashSSL | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | Need more information. XG? |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | No idea what this even is. |
| Dave Raggett | Another Incubator Group that may lead to standards work. | |
| Daniel Dardailler | Non-Core Standard that W3C should not work on | Don't know off my head. |
| Sam Ruby | Non-Core Standard that W3C should not work on | |
| Rotan Hanrahan | Need more info. | |
| Doug Schepers | Candidate for Standards Core Web | I don't know enough about this. |
| Thomas Roessler | Candidate for Standards Core Web | experimental protocol work |
| Jace Voracek | Non-Core Standard that pragmatically W3C should work on | |
| Ashok Malhotra | Non-Core Standard that W3C should not work on | This is a cool bit of technology that will help websites to cooperate but there are others with greater expertise in this area. |
29. Decisions and Decisions-Making
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 1 |
| Candidate for Standards Core Web | 1 |
| Non-Core Standard that pragmatically W3C should work on | 1 |
| Non-Core Standard that W3C should not work on | 3 |
Details
| Responder | Decisions and Decisions-Making | Rationale |
|---|---|---|
| Jeff Jaffe | Candidate for Standards Core Web | Need more information. XG? |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | |
| Dave Raggett | Another Incubator Group that may lead to standards work. | |
| Daniel Dardailler | Non-Core Standard that W3C should not work on | |
| Sam Ruby | Non-Core Standard that W3C should not work on | |
| Rotan Hanrahan | No idea. | |
| Doug Schepers | Non-Core Standard that pragmatically W3C should work on | I don't know enough about this. |
| Thomas Roessler | no idea | |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Don't know enough about this. Sounds like a fuzzy area. |
30. Audio
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 4 |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Audio | Rationale |
|---|---|---|
| Jeff Jaffe | Part of Standards Core Web | |
| Michael[tm] Smith | Part of Standards Core Web | Core: any audio-related formats and APIs that are intended for the public Web and that are natively supported in browsers or that are intended to be natively supported in browsers. Also, maybe it's time we consider putting video and audio work together into "Video and Audio on the Web". |
| Dave Raggett | Another Incubator Group that may lead to standards work. | |
| Daniel Dardailler | Candidate for Standards Core Web | |
| Sam Ruby | Candidate for Standards Core Web | |
| Rotan Hanrahan | Non-Core Standard that W3C should not work on | Not as essential as representation of text and static images. Probably more aligned with the needs of the multimedia/video community, and would probably be better supported as an independent activity within that specialist community. |
| Doug Schepers | Part of Standards Core Web | Huge potential, relatively low cost. Digitizable sense that's been overlooked on the web. |
| Thomas Roessler | Candidate for Standards Core Web | Since it's an incubator, I say "candidate"; however, this relates fairly directly to work that might end up being a core API. |
| Jace Voracek | Part of Standards Core Web | |
| Ashok Malhotra | Seems to be important in making broadening the reach of the Web but don't know enough about what's in place now. |
31. Library-Linked Data
.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Part of Standards Core Web | 1 |
| Candidate for Standards Core Web | 3 |
| Non-Core Standard that pragmatically W3C should work on | 3 |
| Non-Core Standard that W3C should not work on | 1 |
Details
| Responder | Library-Linked Data | Rationale |
|---|---|---|
| Jeff Jaffe | Non-Core Standard that pragmatically W3C should work on | This is not part of the core. But in Users we are trying to define what vertical work we should do in support of the Core. |
| Michael[tm] Smith | Non-Core Standard that W3C should not work on | |
| Dave Raggett | Another Incubator Group that may lead to standards work. | |
| Daniel Dardailler | Candidate for Standards Core Web | |
| Sam Ruby | Non-Core Standard that pragmatically W3C should work on | |
| Rotan Hanrahan | No opinion. | |
| Doug Schepers | Candidate for Standards Core Web | I think this is the same as linked data... ? If so, it's got good community and government push behind it, and has integration points with higher-level web stack stuff. |
| Thomas Roessler | Non-Core Standard that pragmatically W3C should work on | another application area for the semantic web; Incubator. |
| Jace Voracek | Candidate for Standards Core Web | |
| Ashok Malhotra | Part of Standards Core Web |
More details on responses
- Jeff Jaffe: last responded on 11, June 2010 at 10:39 (UTC)
- Michael[tm] Smith: last responded on 12, June 2010 at 01:58 (UTC)
- Dave Raggett: last responded on 12, June 2010 at 12:26 (UTC)
- Daniel Dardailler: last responded on 14, June 2010 at 11:55 (UTC)
- Sam Ruby: last responded on 14, June 2010 at 13:04 (UTC)
- Rotan Hanrahan: last responded on 14, June 2010 at 22:40 (UTC)
- Doug Schepers: last responded on 15, June 2010 at 00:10 (UTC)
- Thomas Roessler: last responded on 15, June 2010 at 09:53 (UTC)
- Jace Voracek: last responded on 16, June 2010 at 06:15 (UTC)
- Ashok Malhotra: last responded on 16, June 2010 at 17:06 (UTC)
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project