Archives for: May 2009
2009-05-27
Executive Summary of W3C workshop on the role of Mobile technologies in Development published
Today W3C publishes the report from the April 2009 Workshop on the Role of Mobile Technologies in Fostering Social Development.
The Workshop was jointly organized by the W3C Mobile Web Initiative and the Ministry of Science and Technology of the Government of Mozambique, with the generous support of Gold Sponsors UNDP, the Web Foundation, Nokia, and Bharti Telesoft; and Silver Sponsors Opera Software, UNESCO, Microsoft Research, and MIT Legatum Center for Development and Entrepreneurship. This work is part of the Digital World Forum project (European Union's FP7).
2009-05-26
Relationship Between Mobile Web and Web Accessibility Working Draft Published
The Mobile Web Best Practices Working Group and the WAI Education and Outreach Working Group have published an updated Working Draft of Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG).
This draft is complete and is provided as a last opportunity for public review and comment before publication as a W3C Working Group Note. See the announcement email.
For an introduction to the overlap between design goals and guidelines covering accessibility for people with disabilities, and design goals and best practices for mobile devices, see Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices.
eGovernment Interest Group Charter Extension and Discussions
2009-05-21
New translation: Проблеми с визуализацията на UTF-8 BOM
Thanks to Ivan Baldwin the FAQ-based article "Display problems caused by the UTF-8 BOM" has now been translated into Bulgarian. [search key: qa-utf8-bom]
2009-05-19
SPARQL working group holds 1st face-to-face, decides upcoming features
The SPARQL working group recently held its first two-day face-to-face (F2F) meeting, co-located in Cambridge, MA, USA and in Bristol, UK.
The F2F marked the culmination of the first phase of the group's work, in which members worked to identify potential features to work on in the coming months. On the first day of the F2F, the group resolved to work on a set of six required features and five time-permitting features over the next 15 months or so. These features include long-sought SPARQL capabilities such as aggregates, subqueries, and update, as well as a better approach to negation and a standard way for SPARQL endpoints to describe the capabilities of their service ("service description").
Time-permitting, the group intends to also pursue standardization of the semantics for using SPARQL to query richer entailment regimes such as OWL or RDFS, as well as to consider basic federated query and property paths.
The Working Group also decided that while the whole landscape of language and protocol will continue to be referred to as SPARQL, particular SPARQL languages will also be identified with names such as SPARQL/Query and SPARQL/Update. Others are possible as the group pursues its work.
On the second day of the meeting, group members launched into discussions of potential designs for three features: aggregates, subqueries, and update. The group noted nearly 30 open issues that must be resolved, and gathered nearly 20 actions to help advance towards consensus on these issues. You can follow along as the group continues its work via the SPARQL Working Group's issues & actions tracker.
The SPARQL Working Group will be publishing a document within the next two months that outlines the features and rationale behind the features that the group will be working on. As always, we welcome input on this document and on any other work the Working Group pursues via our public comments list, public-rdf-dawg-comments@w3.org.
WTF tour
Whilst the W3C Widget Packaging and Configuration specification goes through the W3C process, the Mobile Web Test Suites Working Group have been investing some time and effort into a Widget Testing Framework (WTF).
There is currently a debug instance running at http://wtf.webvm.net. Though soon the project will be properly setup with sources for you to poke at and an opensource license to go with it.
So how does it work? Imagine you have a "Widget runtime" (UA), some software that allows you to run W3C widgets on your computer. You aim the UA to a test, for example: http://wtf.webvm.net/view//basic/true
Step 1
Clicking install should serve you a widget with the correct mimetype application/widget.
Step 2
This is the security prompt phase. You are likely to see this if your widget is not signed.
Step 3
The widget runs and if everything goes well you should see:
Behind the scenes, an AJAX request should be fired off that reports this particular test passed to a REPORTURI which collects this data.
Step 4
In Opera, you'll be asked whether you want to keep the widget after an initial run.
Remove the widget once testing it.
Want to know more?
A more detailed WTF wiki page might help you.
Tracking requests
W3C is a fifteen-years old organization, where plenty of people come to collaborate, with a high variation among them in terms of operating systems, computer proficiency, corporate set up, etc. A number of our users manage to be even more geek than we are in the Systems Team, while for many others, a computer is just a tool that really ought to "just work" (which they still often don't).
The result of that interesting mix is that we have set up over time a fairly large number of tools to facilitate collaboration: several hundreds of mailing lists, an IRC server with a few handy bots, a fine-grained access control system, a questionnaire system, a flexible editing system combined with a robust mirroring scheme, wikis, blogs, various bug and issues tracking system, etc.
And as all these tools are entirely bug-free and work seamlessly together and for all our users (NOT!), we have always had a need to track requests from our users to create and manage various accounts, set up new instances of these tools, correct or work around bugs, etc.
Over the years, the way we have tracked and managed all these requests has evolved, toward somewhat more formalism as the number of our users and tools grew.
When I joined the Systems Team in 2000, our tracking was entirely based on manual scanning of mails threads sent to one of our internal mailing lists: basically, each of us watched for what looked like a request, checked if anybody had responded to it, and if nobody had and the request was something you could manage, and you had some time on your hands, you would take on it.
Given how informal it was, it actually worked quite well, although over time we added some more purely conventional practices: requiring the use of a specific mailing list of a specific type of requests, adding a [closed] flag to the topic of a thread to signal that the request had been dealt with (so that others could simply delete the thread without bothering reading it).
But as the number of tools and users continued to grow, we started to get complaints that some requests had not been dealt with at all, and it became clear that we lacked overall visibility on what needed to be responded.
Back in 2002, I wrote a quick XSLT style sheet that would help us get more visibility on the state of our requests: it took the threaded view of the archive of our request mailing list, and would look for any thread that didn't contain a message starting with our now conventional [closed] flag, and would present a report showing all the requests that hadn't been closed, as well as those that hadn't had an answer at all.
And again, that fairly simple system served us well for quite a few years; some others W3C groups even started re-using it for tracking their issues, and a similar version of the tool based on more Semantic Web technologies was used by a couple of groups to track their specifications' Last Call comments.
But no matter how well that solution worked, we decided last year that we would finally move to a proper tickets tracking system, the well-known open-source RT, to get the following advantages over our existing hack:
- get a clear view of who was working on what ticket,
- be able to assign a given ticket to someone, even if that person hadn't picked it up yet
- easily find tickets that were stalled due to lack of responses from the requester (vs. because we didn't act on it)
The first few months with RT weren't quite so rosy, actually, as we had to find ways to integrate it as smoothly as possible in our current procedures and infrastructures, and with our mailing list habits.
Some of the changes we've brought to it include:
- make it track messages sent as part of a given thread (as identified by the
In-Reply-Toheader) as belonging to the same ticket (even without the id number included) - with an an existing patch to that end; - change the way it modified subject messages (with the Branded Queues extension);
- fix partially the way it sends messages and notices through the configuration UI;
- make it understand our
[closed]convention so that we could continue using mail as our primary way to close a ticket, using a simple "Scrip" inspired from another RT user's contribution.
There are still some rough edges - RT seems to be particularly reluctant to send messages in CC when using the Web interface for some reasons, we need to integrate it better with our existing accounts system so that our users can better follow progress on their requests -, and some user interface and HTTP behaviors problems that make me cringe.
But overall, I think the tool has certainly helped us regain control over our growing number of requests, and is also hopefully steadily allowing us to offer a better experience to our community.
Minutes of May 11 teleconference published
The MW4D IG held its 16th teleconference on May 11th 2009.
The approved minutes are available at http://www.w3.org/2009/05/11-mw4d-minutes.html
Previous meeting minutes are available from the teleconference archives
2009-05-18
Successful HCLS Face to Face Meeting
2009-05-15
W3C Online Training Course: Registration open!
Online Training Course: An Introduction to W3C's Mobile Web Best Practices 1 June – 31 July 2009
W3C is running an extended and improved version of its online course to introduce Web developers and designers to its Mobile Web Best Practices.
In this course you will:
- learn about the specific promises and challenges of the mobile platform;
- learn how to use W3C's Mobile Web Best Practices to design mobile-friendly Web content and to adapt existing content for mobile;
- discover the relevant W3C resources for mobile Web design.
As a participant, you will have access to lectures and assignments that provide hands-on practical experience of using W3C's mobile Web Best Practices. You will have direct access to W3C experts on this topic who are the instructors for this course, and you'll be able to discuss and share experiences with your peers who are faced with the challenges of mobile Web design.
For more information including details of the course material, more about who will benefit most from the course, the registration fee and access to a free sample of the course itself, please visit http://www.w3.org/2009/04/MobiWeb102/.
Making Web technologies robust on any device
The missions of the Mobile Web Test Suites Working Group is to help ensuring that Web technologies work reliably on mobile devices, and we do that by creating tests (such as the Web Compatibility Test for Mobile Browsers) that help detect bugs and inconsistencies in mobile browsers, and provide an incentive for browsers vendors to compete on fixing these problems..
But another approach we have taken since the beginning of our work has been to ensure that tests that are developed by others can also be used to that same effect. Many W3C groups develop test suites as part of the development of their specifications, and more generally, individuals from the Web community at large also create tests to illustrate a specific problem they have, a solution they're proposing, or to explore new usage of a given technology.
Unfortunately, very often these tests end up to be problematic to use on mobile devices - the browsers performances tests we reviewed back in October illustrates the type of difficulties we have encountered again and again when trying to re-use tests on mobile devices.
Over time, we have collected the most frequent problems we have found in these tests, and the results of that collection has been published as a Working Group Note this Tuesday as the Guidelines for Writing Device Independent Tests.
It's a fairly simple and short document - so if you are developing tests for Web technologies, and want to participate in making the mobile web more robust, take a look at the guidelines and try to apply them to your tests!
Should you have any feedback on the guidelines, please let us on our public mailing list public-mwts@w3.org.
2009-05-14
New translation: Кодировка на символите
Thanks to Ivan Baldwin the article "Character encodings" has now been translated into Bulgarian. [search key: article-o-charset]
2009-05-12
Looking for feedback on the Mobile Web Application Best Practices!
In the past few months, the Mobile Web Best Practices Working Group has been pursuing its work on best practices to ease the development of Mobile Web Applications. A third working draft of the Mobile Web Application Best Practices document was published a few days ago.
The set of best practices is not meant to be definitive. That said, the working group believes the document to be fairly stable and does not anticipate major changes based on internal discussions. That is precisely why the working group is eagerly looking for your feedback on the document. Are you a Web Application author with some background in mobile technologies? Are you aware of techniques that should be mentioned in the document? Do you think that one of the best practices look harmful in some case? The group would be glad to hear your comments and update the document consequently!
To provide feedback, simply send an email to the public public-bpwg-comments@w3.org mailing-list (archives) or get in touch with me.
The best practices statements are organized around six axes:
- Application data on using and managing a Web application's data
- Security and Privacy on using and protecting all personally identifiable information
- User Awareness and Control on communicating the hidden behavior of a Web application to end users and allowing them to control it
- Conservative Use of Resources on making sure that the impact of a Web application is as low as possible in a world of constraints
- User Experience on keeping differentiation in mind while developing for mobile devices
- Handling Device Capability Variation on detecting devices capability to provide as good a user experience as possible on a broad range of devices
Improving Access to Government through Better Use of the Web Note Published
Updated canvas test
We've made another small update to the Web Compatibility Test for Mobile Browsers (WCTMB). The canvas test has been made a bit more difficult, testing alpha transparency too:
function canvas() {
var c = document.getElementById("canvas");
var ctx = c.getContext("2d");
ctx.fillStyle = "rgb(0,128,0)";
ctx.fillRect(0, 0, 20, 20);
ctx.globalAlpha = 0; // any future drawing operations will be invisible
ctx.drawImage(document.getElementById('red.png'), 0, 0); // draw invisible red square over the green square
}2009-05-11
Minutes of Apr. 6 teleconference published
The MW4D IG held its 15th teleconference on April 6th 2009.
The approved minutes are available at http://www.w3.org/2009/04/06-mw4d-minutes.html
Previous meeting minutes are available from the teleconference archives
2009-05-07
XHTML Basic 1.1 Proposed Edited Recommendation
The XHTML2 Working Group has just released a Proposed Edited Recommendation of XHTML Basic 1.1, which proposes to add the lang attribute to XHTML Basic 1.1, making it easier to integrate it with existing browsers assistive technologies tools.
It would also have the specific impact on making the compatibility between mobileOK and XHTML 1.0 much easier to achieve, since one of the most frequent problem in making an XHTML 1.0 site mobileOK is the usage of the lang attribute.
Third draft of Mobile Web Application Best Practices published
The Mobile Web Best Practices Working Group published an updated Working Draft of Mobile Web Application Best Practices. This document specifies Best Practices for the development and delivery of Web applications on mobile devices. The recommendations expand upon statements made in the Mobile Web Best Practices 1.0, especially concerning statements that relate to the exploitation of device capabilities and awareness of the delivery context.
The Working Group invites the mobile developer community to review the draft and send feedback on the best practices, and/or suggest additional techniques on the public-bpwg-comments@w3.org mailing-list (archive).
2009-05-01
13:48:42, by Richard Ishida 
, 142 words, 26703 views 
Categories: Miscellaneous, Highlight, w3cWebArchitecture, w3cXMLCore
ITS support in the Okapi framework
The Okapi Framework Team has announced the first milestone of its Java-based products. The framework provides cross-platform and open-source components and applications for localization tasks.
One of the components in this release is an XML filter based on an implementation of the W3C Internationalization Tag Set (ITS) Recommendation.
The filter allows access to the translatable content of an XML document, based on any external or internal global rules, as well as local rules. The ITS processor provided supports the following data categories: Translate, Localization Note, Element Within Text, Terminology, Directionality, and Language Information.
Rainbow, an Okapi application, uses the filter to extract and merge translatable content to and from XLIFF. Many other utilities provided in the framework take advantage of the ITS-based filter as well, for example to perform pseudo-translation.
You can download the Okapi components and get their source code.
Last Call closed – preparing for Proposed Recommendation
The third Last Call period ended at the start of this week and lead to what amounts to errors being corrected in the IRI canonicalisation sections of the Grouping of Resources document (which was the focus of the call, see implementation experience). A small number of extra tests was added to the test suite to cover this important aspect of matching IRIs against POWDER documents. No changes were made to the Description Resources document or Primer.
The Formal Semantics document was reviewed by the OWL WG and the informative section on expressing POWDER in OWL 2 was subsequently updated. At the time of writing, we're dealing with a substantive comment from Michael Schneider. This is likely to lead to a rephrasing of Section 4.3 but no substantive change that would impact on implementations.
So, once that issue is resolved, the next step is Proposed Recommendation. As flagged previously, we're skipping Candidate Rec stage as we already have plenty of implementation experience to hand.
So is the work on POWDER really over 'bar the shouting' as the phrase goes? i.e. have we done what we set out to do? Let's see.
The charter says: The POWDER Working Group is chartered to specify an RDF vocabulary for specifying authorship of and authentication of Description Resources, a specification for associating a Description Resource with a class of Web resources, predicates for declaring classes of resources based on string functions of the resource URIs, and a protocol for accessing Description Resources. This seems well covered!
The charter gives specific examples of statements that must be expressible in POWDER:
- All resources on the
travel.example.comdomain are suitable for display on mobile devices. - All resources on
broadcast.example.com/clipsare video clips that are suitable for all ages. - All resources on
example.comare accessible for all users and meet WAI AA guidelines except those onvisual.example.comwhich are not suitable for users with impaired vision. - Web crawlers are welcome to explore all resources on
example.comexcept those with a path beginning with 'private'.
The first two are exemplified in the documents published by the group (see mobileOK and ICRA examples). The other two could easily be encoded in similar fashion using suitable vocabularies.
The charter sets out specific deliverables:
- A W3C Recommendation providing a normative encoding of description resources (we refer to it internally as 'the DR doc').
- A W3C Recommendation describing methods of defining groups of resources (referred to internally as 'the grouping doc).
- A W3C Recommendation providing an HTTP-based mechanism for locating and accessing description resources associated with a particular Web resource (see Section 4 of the DR doc).
- Subject to available resources, the group will develop a description resource validation tool. Done! (along with several other tools).
The charter also calls on the group to resolve the open questions raised by the Web Content Label Incubator Group: a previous blog entry covers that, which just leaves the requirements derived from the use cases. An exhaustive re-listing of the requirements and how they're covered would make a very dull and largely pointless blog entry but I'll pull out a few for special mention.
- 3.1.8 Reference
It must be possible for a DR to refer to other DRs or other sources of data that support the claims and assertions made. This is possible through the
certifiedandsupportedbyterms discussed in Sections 5.2 and 5.3 of the DR doc. This also covers 3.2.4 Link to Test Results where the requirement is to be able to link to test results (perhaps encoded in EARL).- 3.1.9 Standard Vocabularies
There must be standard vocabularies for assertions about DRs. Actually we kept the vocabulary to a minimum (i.e. reused existing ones as far as possible). However, terms such as
issuedby,issued,validfromandvaliduntilwere introduced.issuedbycaused particular debate as it is so close to terms in both the FOAF and DC vocabularies – but which one to support? Can we not support both? Which is the 'stable standard?'. Cue a lot of e-mails and discussion!- 3.1.10 Identity
DRs, their components and individual assertions should have unique and unambiguous identifiers. Actually we haven't done this as such. POWDER documents have URIs and you can give individual
descriptorsetsidentifiers but, largely due to RDF's lack of (formal) support for named graphs, each component of a DR does not have an identifier. Furthermore, we deliberately made sure that classes in POWDER-S documents typically had node IDs that can't be referenced externally so as to avoid assertions being added to those classes from external sources.- 3.2 Fitting in with Commercial or Other Large Scale Workflows
This requirement — actually a heading for a whole set of requirements — is at the heart of the operational/semantic split. POWDER has to be as easy to use in a commercial, practical environment as possible. Hence the XML encoding and, in particular, the ordered lists of DRs through which we meet requirement 3.2.3 Default Description.
Unless something goes wrong, we should be ready to begin the transition to Proposed Recommendation process next week (or the week after as a worst case).
We really are nearly there.
First Draft of Use cases and requirements for Media Fragments
Search
Categories
Mobile Web Test Suites Working Group blog
- Announcements (11)
- Opinions (1)
- Testing tools (2)
- Web Compatibility Test (7)
- Widgets testing (3)
Archives
- September 2011 (7)
- August 2011 (23)
- July 2011 (17)
- June 2011 (13)
- May 2011 (18)
- April 2011 (14)
- March 2011 (24)
- February 2011 (15)
- January 2011 (11)
- December 2010 (12)
- November 2010 (19)
- October 2010 (18)
- More...
Misc
XML Feeds
What is RSS?
Who's Online?
- Guest Users: 13
