May 17, 2013

koalie’s contemplations in markup

koaliemoon

Cher lecteur francophone,

C’est avec joie que j’ai utilisé mon ample temps libre pour traduire en français le billet que notre CEO Jeff Jaffe a publié la semaine dernière à l’occasion de la sortie controversée de ‘Encrypted Media Extensions‘ (EME) en première version de travail publique, par le groupe de travail HTML.

J’ai hébergé cette traduction sur mon site:

Perspectives sur Encrypted Media Extensions (Extensions pour médias chiffrés) qui atteint le statut de première version de travail publique

Je fais de la traduction en amateur et j’ai eu bien du mal à traduire certains termes que j’emploie tous les jours en anglais. Vos suggestions d’amélioration sont attendues avec anticipation (ici, via le blog).

Quant aux commentaires sur le fond, c’est directement sur le Blog du W3C que je vous invite à les laisser (attention, la lingua franca du Blog du W3C est l’anglais.)

Au plaisir de vous lire !

Coralie


by koalie at May 17, 2013 03:02 PM

May 15, 2013

W3C Blog

Perspectives on Encrypted Media Extension Reaching First Public Working Draft

The HTML Working Group has announced their decision to release a First Public Working Draft of the Encrypted Media Extension (EME) specification. A preliminary version of the document has been public for some time, prompting the Free Software Foundation and others to petition W3C not to publish this draft.

The purpose of this post is to inform the community that, while we welcome and value input from all parties, we intend to continue to work on content protection, and publish this draft.

The Requirement from our Community

I intentionally refer to "content protection." Different publishers use the Web differently, some choosing to make content available free of charge, others preferring to control access. Most people would agree that individuals and institutions in general should have the right to limit access to proprietary information, or charge for access to content they own. Against this backdrop, the W3C Director has established that work on content protection for the Web is in scope for the HTML Working Group. This would address a specific set of requirements on HTML that came to the HTML Working Group from the Web and TV Interest Group.

How W3C Develops Web Standards

It is useful to review the W3C process to develop Web standards. It is a consensus process whereby we bring together vast and diverse interested parties to collaborate and achieve consensus to address the never-ending ways in which the Web drives increased value to society. The key objective is to maximize interoperability and openness - values that have served us well. Once we receive requirements for enhanced functionality, we address those requirements in W3C Working Groups. Once a Working Group has been chartered with a particular scope, the group has autonomy in how it satisfies requirements within that scope. It is thus up to the HTML Working Group to do their best to address identified content-protection requirements with the ultimate goal of enhancing interoperability on the Web. At the current time, the only content-protection proposal put forth within the HTML Working Group is the EME specification. Other discussions about content protection and alternative solutions to the requirements are taking place in the Restricted Media Community Group, which could feed into the HTML Working Group standards effort.

It is typical at this early stage of development for there to be issues; EME is an early draft not a final Recommendation. The HTML Working Group will publish revisions, seek comment, respond to issues, and pursue consensus decisions, all part of the usual W3C process. All W3C specifications are developed under the W3C Patent Policy, with a goal of assuring that the final standards can be implemented on a Royalty-Free (RF) basis. The Working Group expects to see open source implementations of the EME specification.

The DRM Debate and How it Relates to Web Standards

Here is our understanding of why EME is a contentious specification, despite broad agreement that some form of content protection is needed for the Web. The EME specification defines Application Programming Interfaces (APIs) that would provide access to content decryption modules (CDMs), part of Digital Rights Management (DRM) systems. W3C is not standardizing CDM technology, but there is a concern that standardizing APIs could encourage CDM usage - which some view as being in opposition to open Web principles.

While this viewpoint is important to consider as part of the debate, we have heard multiple principled and practical arguments on both sides of the issue.

We all aspire for a rich Web experience. Principled arguments for content protection begin by pointing out that the Web should be capable of hosting all kinds of content and that it must be possible to compensate creative work. Without content protection, owners of premium video content - driven by both their economic goals and their responsibilities to others - will simply deprive the Open Web of key content. Therefore, while the actual DRM schemes are clearly not open, the Open Web must accommodate them as best possible, as long as we don't cross the boundary of standards with patent encumbrances; or standards that cannot be implemented in open source. It has also been noted that a number of widely deployed proprietary technologies are used with the Web, including some video codecs and technologies accessed through plug-in APIs. We are not supportive of proprietary video codecs but recognize that to have far-reaching standards that support interoperability it is essential to include connections to such proprietary elements, some of which may be replaced in time with open standards.

Some have argued that we should not standardize interfaces to CDMs which would have the effect of cordoning off protected content into its own walled garden. This would be a mistake. It is W3C's overwhelming responsibility to pursue broad interoperability, so that people can share information, whether content is protected or available at no charge. A situation where premium content is relegated to applications inaccessible to the Open Web or completely locked down devices would be far worse for all.

There have also been critiques about EME regarding its impact on open source software development, specifically the question as to whether it can be implemented in open source. It is worth noting that the proposed (non-proprietary) APIs would work equally well with proprietary CDMs as with non-proprietary content protection schemes that could be implemented in open source software. The latter might not offer the same degree of content protection - they could be breakable - and would rely more on social convention than on impenetrability. Candidly, we don't see these solutions as being acceptable to content owners for premium video today, but that could change in time, or it could be acceptable to others in the community with different content requirements.

Next Steps

W3C as an organization will weigh a variety of complex considerations to determine the right balance for the Open Web Platform. There are principles and practical arguments on both sides of the debate. If we engage with all, I believe we have a much better chance of success than if we do not. We invite the community to review the First Public Working Draft of the EME specification. We also invite those with alternate proposals for addressing the requirements to consider joining the HTML Working Group, or to discuss them in the Restricted Media Community Group.

by Jeff Jaffe at May 15, 2013 09:03 AM

May 13, 2013

W3C Blog

Sunnyvale DNT Meeting: Overcast With Skies Clearing

Since I became co-chair of the Tracking Protection Working Group in late 2012, we have faced a metaphorically-apt series of weather challenges for our Face-to-Face meetings: a record snowstorm in Boston in February, heavy snow for our Global Considerations meeting in Berlin in March, and even rain on the first day of our Face-to-Face meeting in Sunnyvale CA this week.

I am pleased to report, however, that the sun came out for the third and final day of the Sunnyvale meeting. We spent two and a half days (and some evenings) fleshing-out the roadmap laid-out in our February meeting in Boston: to build a Tracking Protection standard that will fulfill our W3C charter and bring us to Last Call. In this we were partially successful: the TPE specification (expertly managed by my Co-Chair, Mattias Schunter) is all but completed; but consensus on full text for the compliance document remains elusive. With less than 10 weeks left before the final compliance spec is scheduled to enter Last Call, the stakeholders must find ways to come together for success to be possible. No one who participated in this week's meetings --whether in-person or remotely-- wants all of our hard work to end in stalemate or failure.

To that end, the group reached consensus that there was sufficient progress to merit moving forward, as set forth below. The weeks ahead will not be easy, but the parties involved made it clear they wished to forge ahead. Teleconferences will continue. Importantly, members of the Working Group will need to continue the hard work of drafting text and making progress with each other.

We all know what needs to be done. As we heard at our Boston meeting: "Concessions are welcome, but expected."

Consensus Action Summary

At the close of the Face-to-Face Meeting on May 6-8, 2013 in Sunnyvale, the Tracking Protection Working Group has consensus that there was sufficient progress during the meeting to merit moving ahead with the Do Not Track standard, toward the July 2013 Last Call deadline. As part of the continued work on the current TPE and TCS specifications, the following specific tasks have emerged from this Face-to-Face:

  1. The group agrees to make the description of the audience measurement permitted use narrower and more precise. This includes normative and non-normative text. It also requires further investigation of the activities included in audience measurement and the concerns of privacy advocates. We agree to try to find audience measurement language that can substitute for the DAA's market research exception, in order to better align the DAA multisite principles with the DNT specification. We agree to assess both the merits and scope of this possible permitted use.
  2. The initial version of the Tracking Protection specification will be defined with reference to user agents that 1) can access the general browsable Web; 2) have an interface that satisfies the requirements for the user to choose; and 3) can implement the TPE, including the Javascript APIs. Other user agents warrant further study. The scope is vendor-neutral, at the level of principles rather than specific technology details.

    DNT should reflect explicit choice made by a user; there was commitment to explore anti-tampering measures to assure that the DNT state reflects the user’s choice.

    There will be continued exploration of the explanatory language, to provide meaningful information to users, such as in the settings and help screens, and further information published jointly where it can be linked-to from user agents and Web sites.

  3. There was agreement to examine a three-state de-identification process: red, yellow, and green states. A new action item was created to come up with text on these three states with proportionality requirements and transparency into retention limits for both the red and yellow states. New homework assigned to examine DAA code definition of de-identification as normative language with supplemental non-normative language.

    Retention periods for data collected for permitted uses remain an important issue to parties in the group. There is agreement among a broad set of participants that data retention for permitted uses should be proportionate and that there should always be transparency about the data retention periods. Significant work remains to be done on whether to include any specific time limits and on specific transparency requirements.

  4. There will be ongoing discussions of unique identifiers as a critical issue for advocates. We are inviting proposals on ways to solve this issue going forward.

by Peter Swire at May 13, 2013 07:18 PM

May 11, 2013

W3C Blog

Better design tools for responsive design of Web applications

Studies show that corporate websites are for the most part not designed for their usability on smart phones. Some companies provide native applications that users can install on the smart phones, but this is not a panacea. This situation is likely to get worse with an increasing range of devices and platforms. What's needed is more emphasis on the benefits of the Open Web Platform and responsive design techniques as a basis for applications that work effectively across desktop PCs, tablets, smart phones, connected TVs and so forth. Web technologies reduce the cost and increase the reach, avoiding the need to learn new programming languages and SDKs for each platform, and saving time and money by avoiding the overheads of native app stores. However, responsive design can be a little tricky to master and there is a need for improved awareness of best practices and for better design tools.

As part of my work for the EU FP7 Serenoa project, I have been studying ideas for a new breed of design tools based upon model-based techniques. The starting point is to agree on the business requirements, to map these into domain and task models, and to use these to automaticaly generate rough design proposals for each broad category of device. The designs can then be reviewed and adjusted as needed. For this to work, the scope for a given category of device needs to be matched to the context of use. For smart phones, the screen is smaller, and users tend to be highly task oriented, necessitating a design focusing on a specific task. On the desktop, there is greater freedom, so designs can address a broader range of purposes.

The architecture and technical means to address this are covered in a talk I am presenting in the Developer Track at the WWW2013 conference. The approach is essentially a collaborative expert system that searchs for designs that are consistent with the changes made by human designers through a direct manipulation interface. Some changes only effect a given category of devices, but other changes may have broader repercussions, effecting the domain and task models. This is very much a work in progress, and you are welcome to view the slides and follow up on the background. My hope is to inspire tool vendors to rise up to the challenge of responsive design and help realize the potential of the Open Web Platform to delivering apps and services to a broad range of devices.

Finally, I would like to thank my co-presenter Vivian Motti of the Université catholique de Louvain for her help.

by Dave Raggett at May 11, 2013 03:44 PM

May 07, 2013

W3C Blog

W3C Automotive and Web Platform Business Group on the road, get behind the wheel

The W3C Automotive and Web Platform Business Group held its first face to face meeting in Barcelona on the 22 April.

A lot of ideas were discussed during this meeting between BMW, VW, PSA, Visteon, Continental, Intel, KDDI, LG, Magneti Marelli, QNX, Ford, Strategy Analytics, Genivi and W3C with agreement on next steps to prepare the next face to face meeting in Tokyo (29 May).

In particular:

  • A first round of proposals for a Web Vehicle API was discussed, with proposals from Intel, QNX, Genivi (LG) and Webinos.
  • The group decided to first focus on an API that would provide read access.

Decision on next steps include:

  • Creating an overview of the superset of the proposed Vehicle APIs to look for overlaps and gaps.
  • Considering whether the mandatory dataset provided in OBDII could serve as a starting point for a common dataset to be shared by different OEMs via a Vehicle API.
  • Creating a document that maps current W3C work onto the requirements of the automotive sector (e.g. geolocation, packaging, ...).

Don't miss the opportunity to drive the automotive technology evolution, join the W3C Automotive and Web Platform Business Group.

by Bernard Gidon at May 07, 2013 08:45 AM

May 01, 2013

W3C Blog

Proposed Permissive Copyright Experiment in HTML Working Group

Today the W3C Director proposed to the W3C Membership a draft revision to the HTML Working Group charter. The charter is unique because of a provision that would let the group decide whether to publish extension specifications under CC-BY, which is more permissive than W3C's Document License. The proposal intends to encourage collaboration.

The W3C Membership reviewed a draft HTML Working Group charter in February when one Member registered a Formal Objection and requested changes around licensing. Given the importance of this issue and a new proposal focused on extension specifications, the Director now seeks feedback from the Membership.

This is not the first time have discussed licensing of specifications published by the HTML Working Group. In previous discussions we did not reach consensus around a licensing change. The HTML extension specifications present an opportunity to experiment with an alternate, more permissive license, in response to Member feedback. We anticipate that the experiment can inform broader licensing discussions.

We look forward to hearing from the full Membership on this important topic; Member feedback will play an important role in our next steps. I expect to have a public update in early June after the close of the charter review.

by Philippe Le Hégaret at May 01, 2013 08:40 PM

Dave Raggett's blog

Beyond 3D printing

3D printers are very much in vogue and used for everything from spectacle frames to jet engine components. They work by building up a 3D form one thin layer at a time. A variety of materials can be used depending on the desired properties of the resulting component.

I believe we should learn from nature. If you look at natural materials constructed by living organisms, it is really remarkable what has been achieved, for instance, hair, feathers, skin, teeth and bones. Insects are amazing to look at under the microscope and come in all sorts of weird forms. The structure of an insect’s antenna, or a butterfly’s wings are incredible.

The cell is a powerful molecular computer. At its heart, DNA provides the storage for the program. The human genome is said to be about three thousand million bits in size. The cell makes use of a complex set of molecules to determine which parts of the genome are being transcribed into proteins at any one time. The architecture is unlike any digital computer we are familiar with. The cell’s state is distributed across many components, and updated in complex chemical pathways. We are gradually improving our understanding of how they work together as a system.

It is now time to study how to create synthetic cells and learn how to utilize these to create complex materials we can use in a future generation of products. For this purpose, we will have to start relatively simply by studying particular subsystems without the need to fabricate the full complexity seen in living cells. This functional approach also has the great advantage of avoiding the risk of creating a new breed of organisms that can escape to the environment and replicate themselves unchecked.

The first step is to study how to create a molecular computer with DNA, RNA, ribosomes, enzymes and so forth. Can we build a system where we can design a program, translate it into DNA, and used it to switch on and off which parts of the DNA are being transcribed, and to update the state of the synthetic cell in predictable and controllable ways? Once that is achieved we could go on to develop the functional components needed to form a 3D assembler. These include counters and timers, as well as how to control the functioning of a synthetic cell according to its neighbours, or to chemical or electromagnetic gradients.

A working system would involve a means to design a program and translate it into DNA, to massively replicate this and assemble the synthetic cells from the raw ingredients, and then trigger them to start the assembly of the desired components in a carefully controlled environment. The synthetic cells would be unable to replicate themselves, and designed with only one purpose in mind.

The benefits of this approach would be the ability to create a very wide range of complex materials and forms from readily available raw materials in an energy efficient process. Today’s manufacturing processes aren’t sustainable in the long run as they use large amounts of energy and rely on materials that will increasingly be in short supply, for example, copper for electrical conductors and rare earths for electronic components and touch screens in smart phones. Biological processes by contrast make use of trace amounts of materials and as such are much more sustainable.

The time has come for a sustained programme of investment into research in molecular computing and synthetic cells. This is essential for sustaining a high standard of living as we move into a lasting era of increasingly expensive raw materials.

by dsr at May 01, 2013 07:00 PM

April 30, 2013

W3C Blog

Interview: Paul Groth and Luc Moreau on Provenance

Paul Groth (VU University Amsterdam) and Luc Moreau (U of Southampton) co-Chair the W3C Provenance Working Group. The group has just published 12 documents to support the widespread publication and use of provenance information of Web documents, data, and resources. I spoke with them to find out what their group's work —called PROV— will enable.

IJ: What are the main use cases that your Working Group was trying to address?

Paul: Though we studied a number of use cases, I would say there are three main scenarios. The first is attribution. People frequently quote or copy/paste on the Web. Remixing is good, and content creators often want due credit. The second is about aggregation and integration. Provenance information helps people judge the quality of information. Lately I've been talking about "fair trade" data. One example: TechCrunch ran an article in which they said that Google was going to buy a particular company. It turns out the information found it's way incorrectly into a PR databases. The third scenario is compliance, an important enterprise use case. You have a contract with someone and want to be able to prove that you performed according to specification.

Luc: Provenance information is an enabler of services that add value to data. For example, in the past I have spoken about creating a search engine for provenance. The search engine would give you provenance information for anything: products, information, whatever. So you might find yourself in a store with your mobile phone, scan a bar code, and retrieve the provenance. People would build services on top of the provenance information, for example ratings for products that don't rely on child labor.

IJ: Right, those sorts of services foster trust over the network.

Paul: Provenance is a foundation for trust judgments, but is not all that one would need. We think PROV does provide a foundation for trust judgments.

IJ: What are some examples that people have built?

Luc: As part of our progression to Recommendation we catalogued 66 applications. Some are interesting academic examples, others very practical. For me, one that stands out is NASA's use of PROV to provenance-enable the National Climate Assessment report. They are currently working on a prototype and I believe they will launch by the end of the year. NASA is also about to launch a satellite mission where data and processing is accompanied by provenance information.

Paul: One of the reasons NASA is interested in PROV is that they have data coming from multiple different systems and they need a common standard for provenance information that works across those systems.

IJ: How interoperable is PROV today?

Luc: There were at least 10 related vocabs out there, some more popular than others. PROV has brought those communities plus others to the table to agree on a common core.

IJ: And how is the market responding to the new interop?

Paul: People wanted to know what to use, and now they are moving toward PROV. They want to support the standard because it lets them move on to other topics like capturing and analyzing provenance information.

Luc: Most of the people working on older provenance models are either moving to PROV or extending PROV with features they like but that are not part of the new standard.

IJ: What challenges do people face when trying to assemble provenance data?

Luc: Sometimes you have to reconstruct provenance information because it wasn't recorded at the right time. This can be very tedious.

IJ: Can you indicate the reliability of your provenance data using PROV?

Paul: You can, through annotations, but we did not standardize a single weighting system for this. There will be a variety of systems for describing reliability.

IJ: What's the "hello world" example for PROV?

Paul: I wrote up some examples in a blog post in 2011. For example, in these two statements I say that a blog post was attributed to Paul (who is a person, not, say, a company):

  ex:post prov:wasAttributedTo ex:Paul.
  ex:Paul a foaf:Person.

IJ: Those are RDF triples. How heavily does PROV rely on using RDF?

Luc: The PROV model is independent of any particular data system. Provenance information is inherently cross-system - your data flows from system to system, and so you need independence from all those systems. You can serialize PROV data with RDF+OWL, or in XML, and we're working on other serializations as well so that developers can use their favorite data serialization.

Paul: RDF does give you super easy data integration.

Luc: The British Gazette is another example of an organization that will be using PROV, as well as other Semantic Web technology.

IJ: What do you think should happen next in the provenance space?

Paul: PROV provides a foundation for a vibrant provenance community. I anticipate a lot more implementation of PROV and an explosion in this space as there is a real demand for ways to be transparent. I hope to see a lot more tools emerge to support this.

Paul: There is also vocabulary work going on at W3C that builds on PROV (such as the "organization" ontology).

Luc: At the beginning Paul thought we would have more requirements for specific types of properties like revision and derivation. I think there are additional vocabularies that communities will want, and they will work on specialization of PROV for their needs. At some point those communities may decide to standardize on those vocabularies.

Luc: Paul and I writing a book on PROV...look for that as well!

Ian: Thank you both for your time!

by Ian Jacobs at April 30, 2013 02:04 PM

April 25, 2013

W3C Blog

Test the Web Forward Tokyo, June 7-8, 2013 - Registration now open!

After a very successful event in Seattle a couple of weeks ago, we're moving onward to Tokyo. It's already shaping up to be a great event with many working group members and W3C staff in town for F2F meetings. Plus, we already have many experts in Japan signed up and they're psyched to help make this another great one! Space is limited and we expect a full house, so register soon.

Register on the event page

Let's keep making the Web a better place!

#TestTWF

by Rebecca Hauck at April 25, 2013 03:27 AM

April 23, 2013

W3C Blog

Getting agreements is hard (some thoughts on Matthew Butterick’s “The Bomb in the Garden” talk at TYPO San Francisco)

UPDATE 2013-04-23: Brian Kardell has posted a related follow-up titled Off With Their Heads: Disband the W3C?. I recommend reading it.

These are some personal thoughts on Matthew Butterick’s “The BOMB in the GARDEN” talk at TYPO San Francisco“. They do not represent an official W3C position.

  • The W3C doesn’t “adopt” standards; the market does.
  • The W3C doesn’t really even create standards for Web browsers; browser vendors do.
  • The W3C brokers the creation of standards by providing a place for browser vendors and others to get together to reach agreement on details of new browsers technologies in such a way as they’re willing to actually implement them.
  • The W3C has zero means for “enforcing” standards for browser technologies.
  • Browser vendors make their own choices about what to implement and what not to, and when to implement, and how long they take to get around to implementing.
  • The plan Matthew Butterick seems to be proposing in this talk is that browser vendors quit working together to get agreement at any standards body & instead do… something else.
  • The only alternative he puts forward for that something-else part is a vague vision of “a web that’s organized entirely as a set of open-source software projects”.
  • He suggests Linux, Apache, Perl, Python, WordPress as precedents. None of those really have anything at all to do with client-side browser technologies. None of them is a model that could be used as a replacement for developing standards for browser technologies.
  • Standards are more than just software; they require very detailed, unambiguous specifications in order to achieve interoperability (if we have learned nothing else during the last 20 years, we have learned that—the hard way). And tons and tons of testing, too. And they require a lot of tough, time-consuming work to reach agreements on.
  • Getting agreements among implementors is the really hard part, and there’s no magic to make the process of reaching agreements quick, easy, and painless.
  • People disagree. Organizations disagree. The task of us all working together to try to overcome our disagreements is time-consuming, often very frustrating, and almost never easy.
  • Nowhere in Matthew Butterick’s talk is there a real proposal for how we could get agreements any quicker or easier or less painfully than we do now by following the current standards-development process.

by Michael[tm] Smith at April 23, 2013 08:55 PM

April 19, 2013

W3C Blog

Interview: Demonstrating Web Apps at Mobile World Congress 2013

Dominique Hazael-Massieux demonstrating Web apps at Mobile World Congress 2013

For Mobile World Congress 2013, W3C worked with several developers including Tomomi Imura (Nokia), Steren Giannini (Joshfire), and Dominique (Dom) Hazaël-Massieux (W3C) on two Web applications to demonstrate some of the new capabilities of HTML5 and related technology. I asked some of them about their experiences creating a camera app, a photo gallery app, and the server-side technology to stitch them together. The resulting demo worked as follows:

  • The camera app takes pictures, displays them on the camera, and can post them to various sites, including W3C's own server.
  • The W3C server receives the photos and publishes a feed that is updated as new photos arrive.
  • The gallery app reads the feed and displays the photos useful on a variety of devices, in our case: smartphone, tablet, television, and laptop.

The camera project began in the Core Mobile Web (Coremob) Community Group as a way to illustrate both the current capabilities and limitations of the Open Web Platform (OWP).

Ian: Tomomi, when did this project start?

Tomomi: Originally, the app was nothing more than a prototype I wrote for fun. John Kneeland, from Nokia also wanted to work an app that would showcase the capabilities of the OWP. The Coremob CG seemed like the right venue, and we developed the specs in the fall of 2012, shortly before a Coremob face-to-face meeting.

Ian: The Open Web Platform intends to lower the cost of cross-device development (see the related interview with Todd Anglin on the Kendo UI survey). As you built the camera app, what did you find was relatively easy to make work across devices? What was difficult (and how did you solve it)?

Tomomi: Creating a user interface that is platform independent is one of the keys to cross-platform development. When I created the UI for the camera app, I designed it to be independent of the platform's look-and-feel, so a common CSS was all I needed. Non-trivial CSS works fine on all targeted smartphone browsers so I can say that designing the UI was the easiest part. Also, canvas works as expected on most browsers so I did not need extra workaround to support cross-platform.

However, to be honest, it was not as easy to make it cross-platform as I initially expected. A big reason is that the app was meant to showcase new features, which means it relies on new Web technologies that are in the early phases of standardization and not yet broadly interoperable. I found there was no browser that implemented correctly all the APIs I used in the app. In particular, I struggled to use IndexedDB to write photos to local storage. At the time I was coding, only Firefox and IE10 had implemented IndexedDB according to specification. Chrome 18 (was the released version at that time. Now, finally Chrome 25 is out of beta) supports basic IndexedDB, but was using an older version of the specification with no blob support for the database. I had to write extra code to make the demo work on Chrome.

Beside the workaround code, I used PhoneGap for Windows Phone 8 because IE10 for mobile lacks HTML Media Capture capability, although all other features worked fine. This is a hybrid app that, I think, is useful for illustrating how to work with HTML5 in a transitional mode where features not yet available on certain platforms.

Ian: What would you like to do next with the camera app? It's an open source project - are you looking for help from the community on specific aspects?

Tomomi: We have a bunch of things in the pipeline, notably writing tutorials on all aspects of building this app (like providing camera access using HTML media capture, storing pics in IndexedDB, etc.). We also have a nice table with all the key features required to build this app and how well (or poorly) they are supported in different browsers. I definitely want to share our experience in more detail with developers. Before doing that, I plan to simplify some of the code (to remove some hacks). This will cause more browser incompatibility, but my goal is not to promote hacks and tricks, but rather working with Web standards.

Ian: Steren, Joshfire volunteered to be part of this project because you already had a Web-based gallery app. What has been your experience so far (generally) getting your app to work across different devices? In particular, the app works on some televisions. What has been your experience so far with Web technology on televisions?

Steren: Joshfire is creating tools to build applications for today's devices and the ones coming tomorrow. For us, Web technologies are the logical solution to build a multi-device application that is sharing the same codebase on all these devices. The Web Gallery was developed under this model: 80% of the code is shared by all the versions of the app, and the remaining 20% is just for layout adaptation, view hierarchies, and user interactions.

Web technologies have been selected by TV manufacturers as the official tool to build applications for connected TV. That's a good thing and their browsers are now getting better. It was not the case in 2011, where some TV browsers had critical bugs and suffered from major performance issues. Today, it is more easy to develop for TV, I would say it is similar to mobile web development.

Ian: From your perspective, what are the priority features of the Open Web Platform where you think we need to make progress in order to close the gap with native platforms?

Steren: I think developers need features, frameworks and documentation that will help them to build rich client side applications more easily. And to close the gap with native platforms, they also need to be able to access device specific sensors and features (as enabled by projects like Phonegap). Native platforms have application ecosystems that are more than simple URLs: they ask permissions, install locally and auto-update in background. I think the Open Web Platform should provide the same mechanisms. An important priority is also to identify browser problems in the implementation of the specifications. Today, developers notice too many implementation differences that do not appear to be a priority for browser manufacturers.

Ian: Dom, you built the server that hosted the camera and the gallery apps. What were your priorities in building the server? What solutions did you adopt?

Dom: As in any other project, my priority was to do as little as needed. In this case, the server mostly had to act as a go-between for the camera and gallery apps, receiving pictures from the former to display with with the latter.

I chose to develop a node.js-based solution, since I was confident it would let me assemble the various pieces I needed easily; also, one of the features that we were likely to use, Server-Sent-Events, is much easier to implement in an asynchronous environment such as the one provided by node.js.

Ian: We set up this apps to run in a local environment (that is, not on the Web). If we wanted to make available a Web version of these apps, what would you have to change in the server configuration? How would you deal with security? Privacy? Flooding our server with photos?

Dom: There are two options for having the app run in an open environment:

  1. Put some sort of access control in front of the upload feature, where only selected users would be allowed to upload pictures, or
  2. Put some sort of moderation in place so that any picture would need to be validated before being pushed to the gallery.

The first approach would require some changes in the camera app and the server-side component. The second would require a new client-side component, and would also benefit from different kinds of Denial of Service attack protection (e.g., rate limiting the number of pictures that can be uploaded, using techniques to avoid robot-based submissions, etc.).

I would probably handle privacy issues at a different layer. We would need a policy and a process to determine when and how a given picture can be posted (e.g., asking the submitted to vouch they're not posting a picture of someone without their agreement), and how pictures could be taken down.

Ian: Thank you all for the insights, and good luck with the evolution of these apps!

by Ian Jacobs at April 19, 2013 06:03 PM

April 17, 2013

W3C Blog

Open data for evidence based policy making

I spend a lot of my time thinking about and talking about open data. How it improves government transparency, how it can fuel innovation and how it can make government more efficient. The biggest user of open public sector data is the public sector itself - directories of people and organizations, maps of just about everything and so on. But data is increasingly used for evidence-based policy making.

This is one of the fields explored in the Crossover Project that I've been involved with on behalf of W3C since October 2011. A recent study, Case studies on specific applications of ICT solutions for policy modelling (PDF), conducted under the project looked at hundreds of examples of the use of ICT for governance and policy making. I didn't write the report so I can say without hesitation or self congratulation that it is particularly well written and interesting. It boils hundreds of cases down to just 4 show cases:

  • 2050 Pathways Analysis, a UK government tool for experimenting with different policies around energy production and climate change mitigation;
  • Opinion Space, a Web platform for discussing policy ideas in which policy makers can and do participate;
  • UrbanSim, a tool in widespread use for city planning;
  • GLEAM, a remarkable tool for modeling the spread of infections diseases.

What makes GLEAM interesting from my point of view is its use of data that was produced for entirely different reasons.

  • geographic distribution of people and major transport hubs
  • mobility of people, how they commute and travel around the world;
  • epidemiology model - complex disease scenarios and responses.

Only the third is actually related to epidemiology directly, the others were generated and used initially for quite different applications. GLEAM uses a mixture of open and closed data, but as more data becomes more open and greater use is made of common vocabularies and common identifiers, solutions of this type can be put in the hands of policy makers everywhere, helping them to make informed decisions.

The potential for what Crossover calls Policy Making 2.0 will be explored in detail at the project's final conference, held just ahead of the European Commission's Digital Agenda Assembly in Dublin this June. The center piece of the conference will be the Crossover Research Roadmap which encapsulates a huge body of research and input from the broad community on how governments can make smarter use of data, analytics, modeling, and more. The existence of the Web as a two way communication medium between governments and citizens is taken as a given. How the proliferation of open data and social media fits into that landscape is discussed in detail along with many other topics.

A short version of the document is available (and commentable) and it's also visualized on DebateGraph (not 100% cross browser).

Details of the International Conference on Policy Making 2.0 are being finalized but the dates and venue are now fixed: Trinity College Dublin, Monday 17 - Tuesday 18 June. It's an event I'm very much looking forward to.

by Phil Archer at April 17, 2013 12:07 PM

April 16, 2013

W3C Blog

mobiLead: a French startup joining W3C

We welcome mobiLead, a French startup that recently joined W3C as a Member.

Based on its commitment to promoting open standards and its expertise in Automatic Identification and Data Capture (AIDC), Near Field Communications (NFC) and in the Internet of Things (IoT), mobiLead has now joined the W3C NFC Working Group.

mobiLead is an expert group leader on QR Code, NFC and the Internet of Things (IoT) within AFNOR, the French national organization for standardization and its International Organization for Standardization member body (ISO).

Nice to see the French startups joining the W3C community to influence the Web.

by Bernard Gidon at April 16, 2013 09:10 AM

April 15, 2013

koalie’s contemplations in markup

koaliemoon

Aujourd’hui j’ai regardé quelques fois cette vidéo que l’INA (Institut National de l’Audiovisuel) a mise en ligne le 20 mars dernier : Le livre de poche et le mépris. C’est un court extrait (42 secondes) de l’émission de l’ORTF (Office national de radiodiffusion télévision française) L’avenir est à vous, datée du 21 septembre 1964.

Il y a quarante-neuf ans bientôt donc, un étudiant en médecine, appelons-le le lecteur aristocrate, qui bien qu’il ne sait pas s’il y appartient, affirme être persuadé qu’il faut une aristocratie de lecteurs. Interrogé sur le livre de poche, il déclare en penser beaucoup de mal. Je cite :

“Parce que ça a fait lire un tas de gens qui n’avaient pas besoin de lire, finalement, qui n’avaient jamais ressenti le besoin de lire. On les a amené là, avant ils lisaient Nous Deux ou La vie en fleurs, et d’un seul coup ils se sont retrouvés avec Sartre dans les mains. Ce qui leur a donné une espèce de prétention intellectuelle qu’ils n’avaient pas. C’est à dire qu’avant les gens étaient humbles, finalement, devant la littérature, alors que maintenant ils se permettent de la prendre de haut. Les gens ont acquis le droit de mépris maintenant. Ce qu’ils n’avaient pas avant.”

Ce que ça m’inspire  ?

Petit un, je chantonne Ah ! ça ira, ça ira, ça ira ! Les aristocrates à la lanterne !
Petit deux, je me demande si tous les gens parlaient comme ça à l’époque.
Petit trois, sait-on jamais, comme mon père était également étudiant en médecine à peu près à cette époque, je sais de quoi je vais lui parler à la prochaine occasion pour qu’on rigole un coup.
Et petit quatre, je tracerais bien volontiers un parallèle entre l’aristocratie de lecteurs telle que décrite par l’étudiant il y a 49 ans et l’aristocratie d’internautes.

Au risque de sembler élitiste ou de ne pas voir un défaut que j’ai moi-même –moi qui gribouille sur l’internet de temps à autre– quand je vois ce qui se tweet, ce qui se facebook, ce qui s’instagram, etc., j’ai du mal à séparer le bon grain de l’ivraie, et j’aspire à une modération sévère chez ceux qui inondent le Web de tout ce qui leur passe par la tête.


by koalie at April 15, 2013 11:30 PM

April 12, 2013

W3C Blog

Summer hacking with W3C #GSoC2013

W3C is pleased to announce that we've been accepted as a mentoring organization for the Google Summer of Code 2013. We work on standards and we have always known that code is king, which is why W3C worked for a long time on a browser/editor (Amaya), server (Jigsaw), and other tools (validators, etc.)

If you're a student interested in working on Open Source projects at W3C, check out our GSoC page and our initial list of ideas. It spans several W3C technologies (from HTML to RDF) and includes many languages such as Java, Scala, Python and Node.js. This list is not definitive and we invite students to amend them or propose their own. The prefered way to discuss with the team and the potential mentors is to use IRC (irc://irc.w3.org/#w3c or the web interface). You can also send an email to public-qa-dev@w3.org.

What is Google Summer of Code

Google Summer of Code offers student developers stipends to write open source software code over a three month period. Paired with a mentor or mentors in our staff or the W3C community, accepted student applicants will do work related to their academic pursuits, gain exposure to real-world software development, and best of all, create and release open source code for the benefit of all. The program which kicked off in 2005 has brought together nearly 6,000 successful student participants and over 3000 mentors from over 100 countries worldwide, all for the love of code.

by Alexandre Bertails at April 12, 2013 03:11 PM

April 04, 2013

W3C Blog

Test the Web Forward Seattle - April 12-13, 2013

We're very excited that Test the Web Forward is coming to the Pacific Northwest! The event will be held at the Microsoft office in downtown Seattle, graciously hosted by the Internet Explorer Developer Relations team. We'll kick things off Friday evening, April 12, with a series of short talks to get people up to speed for writing tests the next day. There will be time after the talks to mingle with experts from Mozilla, Adobe, and Microsoft, get set up, and come up with a plan for Saturday hacking. We'll return on Saturday morning and the test writing will begin. Food & drinks will be served throughout the event and some excellent raffle prizes given away at the end. When it's over, the Open Web community will be stronger and we'll have moved the web forward just a little more...

Register here.

If you'd like to stay informed of future TestTWF events, subscribe to public-testtwf@w3.org.

We hope to see you there!

by Rebecca Hauck at April 04, 2013 10:48 PM

March 30, 2013

koalie’s contemplations in markup

koaliemoon

I follow the International Committee of the Red Cross on Twitter and they twitted this earlier today:

@ICRC: Our role as a “neutral intermediary” is at the heart of #humanitarian action. Our director of operations explains: [link]

Original Message:

The main part of their micro-post, “neutral intermediary” is at the heart of #humanitarian action, particularly resonated with me for several reasons, that I want to attempt to articulate in this post of what I did at one point as a hobby and how, in a way, some choices, people and events led me back to it.

My years with the French Red Cross

In my late teenage years I enrolled at the French Red Cross and during several years –until I started university– I participated in social, medical, training, fund-raising and first aid actions. It occupied my weekends, almost all my holiday time and several week evenings. I was very committed. I came to the Red Cross spurred by my twin brother who had recently became involved. It sounded useful and fun.

It was indeed useful and fun. Even sorting clothes was fun. It was daunting; several piles of garments and shoes, tall as dunes, dumped in the vast depot next to the offices, that we had to plough through during hours. But at the end of the day (that is, late at night) we felt we had accomplished a useful action. Clothes and shoes, categorised and packed, were ready to be picked and handed off somewhere else. My friends and I would find a bar open till late fir coffee and drinks, sometimes a game of cards, but mostly bonding.

I met all kinds of people, from all walks of life, most of them interesting, some of them inspiring –students like me, nurses, police officers, business people, house wives, etc. I learned to give first aid, to man the radio, to drive the ambulance (in particular to park it), to lead a team of first-aid workers, to cook for a crowd, to identify priorities, and to put things into perspective. I saw, heard, and experienced things that made me fully aware how lucky I was, and what a fine life mine was.

I don’t know if I was particularly gifted or actually good at it (I felt I was good), but my satisfaction was such that I wanted to make this my job. There even was a school I thought I might attend, Bioforce, which “specialises in ‘support functions’ (logistics, project coordination, administration and finance, human resources…) and in the field of water supply and sanitation.”

I didn’t go. I went to a local university instead, embarking on a different path. A few years later I looked for a job. I was a temp for a while. I worked as a clerk in a British law office, although I tried very hard to wiggle out of this, as soon as I saw the place and realised the work conditions were going to be terrible. I passed the one interview I wanted to fail. Thankfully it was a short mission.

Discovering the world of a Research Lab

I got my next job by luck. A friend of mine, whom I had met while studying in Edinburgh, let me know she knew someone whose mother worked with someone who needed a temp for a semester. Two actually. And my friend was on the market too so it was perfect. We both interviewed on the same day. We had been pre-assigned a position but after interviewing they changed their mind and swapped. She joined the administrative and legal department at INRIA Sophia Antipolis, I joined a research project as administrative aid.

My years of volunteering and charity work were far behind me. The researchers I met were committed and inspiring people. Most wore shoes but many didn’t. Most people appeared to not see the people around them, absorbed as they were. All had pens in the breast pocket of their shirt, when they wore them, or the pocket of their shorts. Most carried laptops. There were whiteboards everywhere and I had no idea what the colourful scribblings and equations meant.

In that INRIA research project, I learned to type on a qwerty keyboard, to use e-mail on exmh, to print from a unix terminal, to get geek humour. I also learned LateX just for fun. When the end of my mission was near I wrote a fictitious humorous report, in LateX, featuring some of the people that crowded our floor. A thirty or so page report that I gave to the two project managers and a researcher I was particularly fond of, nice and kind as he was. In exchange (not really), I was congratulated by the Director of the institute, and the project managers each gave me the bestest recommendation letters ever. I was on the dole for five months afterwards. My great letters, for all the power that I thought they wielded, didn’t get me my next job.

Joining the W3C

Lucky again, someone who knew me was asked to tell me that the World Wide Web Consortium needed an administrative aid and that I should apply. The W3C was hosted at INRIA Sophia Antipolis and oddly enough people there seemed to remember me and speak highly of me! I interviewed and was hired. That was 14 years ago.

What we do at W3C is basically convening the people who make the Web and the people who consume the Web, around a neutral table. The staff (there are between 60 and 70 of us, mostly technical, located throughout the world) is involved to help the Web stakeholders converge. From that collaboration, web standards are born, refined, and perfected.

At W3C, I met the most incredible colleagues and co-workers, the most inspiring people, the most dedicated folks, bright, clever, helpful, friendly, reliable and supportive. Working with them, doing our job, doing *this* job, is fulfilling and gratifying.

It’s been a while so I have learned so much that it is difficult to grasp and synthesise. The one easy thing that comes to mind is NOT that I learned HTML or CSS (however, some of that I did learn), it is that I learnt to pack lightly, pragmatically and efficiently for trips abroad. We used to travel a lot. We still travel but not as much. I visited a big city for the first time during a W3C trip to a WWW conference. It was in Toronto. Then Boston, Tokyo, Hong Kong, Hawaii, Western Europe, Montreal etc. I now pack in twenty minutes and travel with my purse, one carry-on and a laptop bag. For short trips, the carry-on is a small backpack.

I can say that I have learned various jobs within our organisation. I started as administrative aid, I organised meetings, I ordered stationary, managed hirings and interns, I wrote internal policies,
then managed the local office. I joined the Communications team and wear several hats. From secretary of the Board, translation community monitor, blog master, to Community Manager. I gather the press clippings, I send transition announcements to our Members when a technology progresses from one state to the other, ultimately reaching that of Standard. I write to our Web site, which I occasionally break so I sweat a bit and eventually fix it. I do other internal comm things too.

A couple years ago I had a skills assessment. I was at a point in time I wanted to focus on what I was good at, and what it was that I was skilled for. The exercise was interesting and useful. I was told my area of interest revolves around humanitarian activities and care giving. And that I have more than one string to my bow. No surprise, really, but it was reinforcement that I was in my field.

My job is a passion. It may not be the humanitarian field action I dreamt of as a young woman, but many in our trade liken our job to humanitarian work. And indeed, we are a “neutral intermediary” at the heart of making free and open Web standards.


by koalie at March 30, 2013 07:34 PM

March 26, 2013

W3C Blog

Open Web Platform Weekly Summary - 2013-03-18 - 2013-03-24

This is our weekly Openweb Platform Summary from March 18, 2013 to March 24, 2013. You can read again the last week blog post. Your comments are helpful.

[CSS] Smooth Scrolling

Sometimes Web designers wish to be able to create a smooth scrolling effect when adjusting the scroll position of a page. Tab Atkins (and someone else at Google) is proposing to modify scrollTo and scrollBy functions in CSSOM View to take a third parameter: an optional "smooth" string. If omitted, the scroll is instant. Boris Bzarsky (Mozilla) is explaining the current behavior in Mozilla. Simon Pieters (Opera) is wondering if there should be way to control the time dependency of the scrolling.It could become also a good opportunity for users to have more control on it and deactivate it through user stylesheets. Read the full thread.

[CSS] :first-child without parent

CSS world is sometimes harsh. A :first-child can never match a root element because it has no parent element and so is not the child of any elements. Read the full thread. The issue comes with DocumentFragment what should happen in this case. Boris Bzarsky and Tab Atkins outlined some possibilities.

[CSS] Orientation of input type="range"

When using <input type="range">, it might be useful to have it vertical or horizontal. Jonathan Watt was working on its support inside Mozilla and asking if there should be a property inside CSS for it. It seems that a specific attribute orientation is an intermediate solution in the meantime.

[CSS] min-width and max-width as pseudo-classes

Do we need :min-width/:max-width pseudo-classes for CSS layouts? A blog post is explaining the issues related to Responsive Web design per elements and layout resizing when in a different context than the main document. This started a gigantic thread on CSS list with very interesting concrete cases.

[WebApps] Appcache, some use cases

Charles McCathieNeville (Yandex) has posted use cases related to appcache.

[HTML] video playlist

How would you implement the playlist in HTML?

[HTML] longdesc is back

If you have been living under a rock, you might not know, but longdesc attribute is in the process of being back in HTML5. Not yet done. There are still a few issues to solve before.

by Karl Dubost at March 26, 2013 08:20 PM

March 25, 2013

W3C Blog

Open Web Platform Weekly Summary - 2013-03-11 - 2013-03-17

This is our weekly Openweb Platform Summary from March 11, 2013 to March 17, 2013. You can read again the last week blog post. Your comments are helpful.

[DOM] Making Shadow DOM Subtrees Traversable

When discussing about Shadow DOM, security questions having been raised such as keeping the integrity of a Shadow DOM. Boris Zbarsky explained what are the current ways to have access to it.

[CSS] Selectors Logical Combinators / Sets

Brian Kardell proposed to have additional CSS constructs to combine selectors and/or create sets of selectors. He outlined his ideas in a blog post too. François Remy explained the ideas of Brian on the list and outlining that not already exists, or can be emulated with commas and there is a missing and operator. He also noted that a full syntax for :and/:or/:not would be useful.

[HTML] Fetching Algorithm

Anne van Kesteren (who is now working for Mozilla) is in the process of revising the fetching of data. He is tackling the issues one by one for adding consistency to the Open Web Plaftorm. The Origin header is specified in different ways depending on the interface. He also tested data urls and network errors, HTTP Authentication, crossorigin, .

[Canvas] ImageData allowing preexisting data

Kenneth Russel is proposing to get an ImageData constructor with preexisting data. Read the thread.

by Karl Dubost at March 25, 2013 07:14 PM

March 24, 2013

koalie’s contemplations in markup

koaliemoon

My friend Alexandre pointed me to an article by Uncle Bob, There are ladies present, in which I had a language-related epiphany:

[...] there was an f-bomb in every sentence. It was effing this and effing that and what the ef here and there and everywhere. [...]

Until that time, it had never occurred to me that the adjective ‘effing’ took its origin from the f-word, ‘fucking’. But now that I do, it makes sense completely.

I may even use it, now that I understand –and own it, in a way. That will add an extra middle-strength layer to how I convey a feeling or state of mind, still keeping the f-word as last resort.

By the way, Uncle Bob’s article is one that I recommend; he shares how women in tech have thus far lived in perpetual inconsequence, mostly having no status, no respect, and no voice in their world.


by koalie at March 24, 2013 09:24 AM