This is the list of proposed Community and Business Groups. To express support for a group, you must have a W3C account. Once a group has sufficient support (five supporters), W3C announces its creation and people can join it to begin work.
Not seeing a proposed group on this page? It may received enough support; check the current groups.
Log in to show support for groups.
To provide an standard/unified data model for data visualization, data visualization API, core model of data visualization methods and catagory, and domain specific data visualization methods (e.g. scientific data visualization), and further, data interactive ananlysis method.
A group for people who love pixels! This group is in support of exposing device pixel densities to web developers and letting web developers have the ability to use 'hardware pixels' instead of 'CSS pixels' on demand. Native developers have this affordance, why can't we? Hardware pixels! We want hardware pixels! ## What we want ## We want metrics! The hardware pixel density of a screen can live in the window.screen object as window.screen.pixelDensity, for example. The value would be the average of the vertical pixel density and the horizontal pixel density of the screen (in hardware pixels per unit). Vertical and horizontal pixel densities of the screen can be exposed in window.screen.verticalPixelDensity and window.screen.horizontalPixelDensity. Yes, the vertical and horizontal values don't always have a ratio of 1 across devices. Pixel Aspect Ratios are important for developers and designers that truly care about device-independence. ## How can it be done? ## Easy. The EDID data in modern screens tells us the width and height of a display in millimeters, the native resolution of the screen, and other interesting information. This info allows us to calculate a screen's hardware pixel density in pixels per millimeter with floating point precision. Exposing these values in window.screen is even more trivial. ## Why do we want these values? ## In this modern day, developers are moving towards device-independent development more than ever before. By exposing physical characteristics of a screen (when supported by the screen (just like how OpenGL is exposed through WebGL when supported by a device)) web developers will be able to make device-independent decisions on their development process. Currently, the lack of these metrics means that a web app can only look *almost* the same across devices, but not necessarily *exactly* as intended. We're engineers; *almost* is not enough. For example, suppose I want to make a push menu that is *always* 1 physical inch wide. This is currently not possible because inches in the web are "CSS inches", not physical inches. CSS units like centimeters, millimeters, and inches are currently unreliable across devices. You might think "why not just create a div element that is 1 cm wide, then get it's width in pixels and that's how many pixels per cm you have". Sure, that works, but those are *CSS* pixels per *CSS* centimeter. On top of that, not all operating systems operate at the same dpi, and to make matters worse not all devices have a devicePixelRatio of 1 (mines 2 by default in Mac OS X Yosemite). So the value that you'll get from this technique, if you adopt it right now, vary a *whole lot* across devices. We can't say with any confidence that something being displayed on various screens on multiple devices is 1 physical inch wide. Giving us these screen metrics will not only help us, it will help the future generation of developers because not only will exposing these screen metrics based on EDID info (when supported by the screen) get us closer to device-independent development more often, it will also promote the use of the EDID standard by screen manufacturers so that the next generation can benefit even more from the exposed screen metrics. ## Pixel Freedom for All! May the pixel be with you! ##
The aim of this group is to explore and develop a set of standards for Organisational Profile Documents (OPDs). In particular we are interested in the usefulness of a machine readable OPD for the automatic discovery of resources in UK higher education institutions. Possible outcomes of the project would be: · Produce a specification for OPD · Create the documentation/supporting materials for OPDs · Promote the OPD to new organisations There is some support/resource from a UKHE funded project, data.ac.uk, more information on OPDs http://opd.data.ac.uk
This community recommends an approach for exposing IEEE Learning Object Metadata (LOM), a metadata standard for educational contents, as Linked Data. It is intended as a bridge for linkage of educational metadata into Linked Open Data (LOD). This community aims to describe a mapping of IEEE LOM elements to RDF based on Linked Data principles.
This group's aim is to discuss and agree on the use of a custom protocol handler (math:) and standard parameters for enabling the export of mathematical expressions in MathML to other applications, such as assistive technologies, graphing calculators, math notebooks and other mathematics oriented applications, such as IPython and MATLAB. For more information, see https://wiki.benetech.org/display/MATH/Protocol+Handlers+for+External+Applications+to+Process+MathML
The primary objective of this group is be a discussion forum and to teach the necessity of accessibility within the Chennai region. A secondary objective is to raise awareness of Web accessibility among college students. This group will not produce specifications.