Activity | Score | Part of Standards Core Web | Candidate for Standards Core Web | Non-Core Standard that pragmatically W3C should work on | Non-Core Standard that W3C should not work on |
---|---|---|---|---|---|
HTML | 36 | 9 | 0 | 0 | 0 |
Rich Web Client | 35 | 8 | 1 | 0 | 0 |
Graphics | 34 | 7 | 2 | 0 | 0 |
Style | 34 | 8 | 0 | 1 | 0 |
Internationalization | 33 | 7 | 1 | 1 | 0 |
Security | 32 | 6 | 2 | 1 | 0 |
Video In the Web | 31 | 6 | 2 | 0 | 1 |
Fonts | 31 | 5 | 3 | 1 | 0 |
Semantic Web | 31 | 6 | 1 | 2 | 0 |
XML | 30 | 6 | 1 | 1 | 1 |
Ubiquitous Web Applications | 29 | 4 | 4 | 0 | 1 |
WAI Technical | 28 | 6 | 0 | 2 | 0 |
Privacy | 27 | 3 | 5 | 0 | 0 |
Math | 26 | 3 | 2 | 4 | 0 |
Synchronized Multimedia | 25 | 3 | 3 | 1 | 2 |
Voice Browser | 25 | 2 | 3 | 4 | 0 |
Social Web | 25 | 2 | 4 | 2 | 1 |
Mobile Web Initiative | 23 | 2 | 3 | 2 | 2 |
Audio | 22 | 3 | 3 | 0 | 1 |
Web Services | 20 | 1 | 1 | 6 | 1 |
WAI International Program Office | 19 | 3 | 1 | 2 | 0 |
Semantic Sensor Network | 19 | 0 | 3 | 4 | 2 |
XForms | 18 | 1 | 2 | 3 | 2 |
Library-Linked Data | 17 | 1 | 2 | 3 | 1 |
Multimodal Interaction | 17 | 0 | 5 | 0 | 2 |
Open Web Education | 16 | 1 | 1 | 4 | 1 |
Provenance | 16 | 1 | 2 | 2 | 2 |
Model-based User Interfaces | 16 | 0 | 2 | 4 | 2 |
MashSSL | 13 | 0 | 3 | 0 | 4 |
eGovernment | 13 | 0 | 0 | 5 | 3 |
Decisions and Decisions-Making | 8 | 0 | 1 | 1 | 3 |
This is Part of Standards Core Web.
Core: any (X)HTML-related specifications/technologies that are intended to be implemented natively in browsers.This is 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.This is 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.This is Part of Standards Core Web.
Critical component to enable Web usageThis is 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.This is 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.This is 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.This is 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.This is Part of Standards Core Web.
The Web is turning into a Web of Applications. We need to spearhead this effort.This is 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.This is 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.This is 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...This is Part of Standards Core Web.
SVG is part of Standards Core Web, WebCGM is Non-Core Standard that W3C should not work on.This is Part of Standards Core Web.
SVG, clearly. WebCGM probably more in the non-core, pragmatic category.This is 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.This is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
In my view all we need in a low-level maintenance activity.This is 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.This is 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.This is 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.This is 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.This is Part of Standards Core Web.
We need a single Web so it has to be internationalThis is 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.This is Candidate for Standards Core Web.
XML Security is part of the Core.This is 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!This is 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.This is 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.This is Part of Standards Core Web.
To the man on the street privacy and security are what is most important.This is 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.This is 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.This is 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.This is Part of Standards Core Web.
Critical technology, but flawed in its current approach. See SMIL.This is Candidate for Standards Core Web.
Seems like a good extension for a richer Web experience.This is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
Low-level maintenance is all that is neededThis is 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.This is 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.This is 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).This is 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.This is 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.This is 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.This is Part of Standards Core Web.
XML has proven its worth as a core standard for information transfer and storage.This is 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.This is 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.This is Part of Standards Core Web.
"The XML Stack."This is Non-Core Standard that W3C should not work on.
The XML Standards are pretty much done. We should not spend additional resources on them.This is Non-Core Standard that W3C should not work on.
"Ubiquitous Web Applications" is an amorphous abstract term and is not itself core.This is Part of Standards Core Web.
I agree that Device API and Geolocation are part of the Core.This is 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.This is 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.This is 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.This is Candidate for Standards Core Web.
Seems important. Not sure.This is 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.This is Part of Standards Core Web.
Critical work on ensuring that core Web standards support accessibility.This is 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.This is Part of Standards Core Web.
Needs to continue to produce more great technically-focused specs like WAI-ARIA.This is 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.This is Candidate for Standards Core Web.
Policy languages are probably in the Core. Privacy as a broad topic is much broader than Core.This is 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!This is 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.This is Part of Standards Core Web.
To the man on the street privacy and security are what is most important.This is 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.This is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
We have MathML. Further refinement does not seem like a good use of scare resourcesThis is 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.This is 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.This is 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.This is 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.This is Candidate for Standards Core Web.
not quite sure how much it's used and how closely it's tied to core workThis is Part of Standards Core Web.
Seems important but really don't know enough about this.This is 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.This is 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.This is 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.This is Candidate for Standards Core Web.
Needs tighter integration into graphical browser tech, which I believe is their goal.This is 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.)This is 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.This is 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.This is 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.This is 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.This is 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.This is 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.This is 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.This is Part of Standards Core Web.
Many predict that this is the direction that the Web will grow in.This is 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.).This is 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.This is 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.This is 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.This is 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?This is 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.This is Part of Standards Core Web.
Mobile access as a seamless Web experience is important.This is 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.This is 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.This is Part of Standards Core Web.
Huge potential, relatively low cost. Digitizable sense that's been overlooked on the web.This is 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.This is 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.This is 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.This is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
To be honest, I don't know enough about this.This is Non-Core Standard that pragmatically W3C should work on.
This work is mostly wrapping up.This is Non-Core Standard that W3C should not work on.
The requisite standards are in place or almost in place.This is Candidate for Standards Core Web.
I don't know what this is...This is 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.This is Non-Core Standard that W3C should not work on.
Not core by any stretch of the imagination, as far as I can see.This is Candidate for Standards Core Web.
I need to learn more about this. XG for now?This is 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?This is 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.This is Non-Core Standard that pragmatically W3C should work on.
Interesting, if we have the right stakeholders.This is 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.This is 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.This is 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.This is 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.This is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
Low-level maintenance is all that is neededThis is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
another application area for the semantic web; Incubator.This is 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.).This is 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.This is 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.This is 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.This is 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.This is Candidate for Standards Core Web.
Another broad topic that requires more definition.This is Part of Standards Core Web.
Missing third pillar of W3C:This is 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.This is Non-Core Standard that W3C should not work on.
Others can and want to do this.This is Non-Core Standard that W3C should not work on.
No idea what this even is.This is Candidate for Standards Core Web.
Need more information. XG?This is Candidate for Standards Core Web.
Another Incubator Group. Provenance underpins trust, and as such is fundamental challenge for the Web.This is Non-Core Standard that W3C should not work on.
Not sure what that is.This is Non-Core Standard that pragmatically W3C should work on.
Really interesting, if it can be moved to bear fruit in a reasonable timeframe.This is Part of Standards Core Web.
This incubator works on a key missing piece for the semantic web technology stack.This is Non-Core Standard that W3C should not work on.
Not core by any stretch of the imagination, as far as I can see.This is Candidate for Standards Core Web.
I need to learn more about this. XG for now?This is 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.This is Non-Core Standard that pragmatically W3C should work on.
What's the diff with Multimodal, xform model ?This is 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.This is 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.This is Candidate for Standards Core Web.
Speculative work that could eventually lead to a better authoring environment. Might end up core, might end up fringe.This is Non-Core Standard that W3C should not work on.
No idea what this even is.This is Candidate for Standards Core Web.
Need more information. XG?This is Non-Core Standard that W3C should not work on.
Don't know off my head.This is Candidate for Standards Core Web.
I don't know enough about this.This is Candidate for Standards Core Web.
experimental protocol workThis is 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.This is 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.This is Non-Core Standard that pragmatically W3C should work on.
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.This is 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.This is 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.This is Non-Core Standard that W3C should not work on.
Not our business. Govt. should take care of what is necessary.This is Candidate for Standards Core Web.
Need more information. XG?This is Non-Core Standard that pragmatically W3C should work on.
I don't know enough about this.