W3C Team blogs' Galaxy

Proposed W3C Test Suite Licenses; Feedback Welcome [W3C Team]

2008-07-25T06:51:02+00:00

Several W3C Working Group participants have requested that W3C change its software license to make it easier for developers to re-use test cases in software development, bugtracking, and other scenarios. We have created a proposal for new licenses: a 3-clause BSD License and a W3C Test Suite License. We welcome public feedback; see the proposal for details.

Here is an excerpt from the introduction.

Licenses for distribution of W3C Test Suites should satisfy two goals:

Enable developers to use test cases easily, and promote software development and bugtracking.

Enable a W3C Working Group to create a branded, "Authoritative W3C Test Suite" to reflect the group consensus process, and to promote interoperability and stability of performance claims.

To achieve these goals, W3C makes available Test Suites under two distinct licenses for two mutually exclusive uses:

a 3-clause BSD License for software development, bugtracking, and other applications that do not require assertions of performance to the public or implied claims of conformance to a W3C Specification.

a W3C Test Suite License for an Authoritative W3C Test Suite or when claims of performance with respect to a specification are required.

The choice of license is up to the licensee for every single use of tests from a W3C Test Suite. It will typically depend on application requirements: the first one allows changes, the second does not.

Read the full proposal. Please send comments by 15 August.

Why … [C. M. Sperberg-McQueen]

2008-07-24T16:41:08+00:00

Why do so many proponents of new technologies spend so much time misrepresenting existing technologies and spreading misinformation about them?

Do they misrepresent the existing technologies in order to make the new technology they are selling look better?

Or did they get involved in the new technology only because they failed to understand the existing technology and how to use it well?

Pleasure of Reading Tech Blog Posts [W3C Team]

2008-07-24T07:09:56+00:00

Some technical blogs are usually interesting, but there are some which really push the limit and helps you to analyze and understand. Reading these blogs, it just feels good. A sample of interesting blog posts I have read lately:

Robert O'Callahan on SVG

John Resig on HTML, CSS and Javascript

Michael Sperberg-McQueen on XML and RDF analysis

RDF, Topic Maps, predicate calculus, and the Queen of Romania [C. M. Sperberg-McQueen]

2008-07-23T19:54:38+00:00

[22 July 2008; minor revisions 23 July]

Some colleagues and I spent time not long ago discussing the proposition that RDF has intrinsic semantics in a way that XML does not. My view, influenced by some long-ago thoughts about RDF, was that there is no serious difference between RDF and XML here: from interesting semantics we learn things about the real world, and neither the RDF spec nor the XML spec provides any particular set of semantic primitives for talking about the world. The maker of the vocabulary can (I oversimplify slightly, complexification below) make terms mean pretty much anything they want: this is critical both to XML and to RDF. The only way, looking at an RDF graph or the markup in an XML document, to know whether it is talking about the gross national product or the correct way to make adobe, is to look at the documentation. This analysis, of course, is based on interpreting the propositition we were discussing in a particular way, as claiming that in some way you know more about what an RDF graph is saying than you know about what an SGML or XML document is saying, without the need for human intervention. Such a claim does not seem plausible to me, but it is certainly what I have understood some of my RDF-enthusiast friends to have been saying over the years.

(I should point out that if one understands the vocabulary used to define classes and subclasses in the RDF graph, of course, the chances of hitting upon useful documentation are somewhat increased. If you don’t know what vug means, but know that it is a subclass of cavity, which in turn is (let’s say) a subclass of the class of geological formations, then even if vug is otherwise inadequately documented you may have a chance of understanding, sort of, kind of, what’s going on in the part of the RDF graph that mentions vugs. I was about to say that this means one’s chances of finding useful documentation may be better with RDF than with naked XML, but my evil twin Enrique points out that the same point applies if you understand the notation used to define superclass/subclass relations [or, as they are more usually called, supertype/subtype relations] in XSD [the XML Schema Definition Language]. He’s right, so the ability to find documentation for sub- and superclasses doesn’t seem to distinguish RDF from XML.)

This particular group of colleagues, however, had (for the most part) a different reason for saying that RDF has more semantics than XML.

Thomas Roessler has recently posted a concise but still rather complex statement of the contract that producers of RDF enter into with the consumers of RDF, and the way in which it can be said to justify the proposition that RDF has more semantics built-in than XML.

My bumper-sticker summary, though, is simpler. When looking at an XML document, you know that the meaning of the document is given by an interaction of (1) the rules for interpreting the document shaped by the designer of the vocabulary and by the usage of the document creator with (2) the actual content of the document. The rules given by the vocabulary designer and document author, in turn, are limited only by human ingenuity. If someone wants to specify a vocabulary in which the correct interpretation of an element requires that you perform gematriya on the element’s generic identifier (element type name, as the XML spec calls it) and then feed the resulting number into a specific random number generator as a seed, then we can say that that’s probably not good design, but we can’t stop them. (Actually, I’m not sure that RDF can stop that particular case, either. Hmm. I keep trying to identify differences and finding similarities instead.)

(Enrique interrupted me here. “Gematriya?” “A hermeneutic tool beloved of some Jewish mystics. Each letter of the alphabet has a numeric value, and the numerical value for a concept may be derived from the numbers of the letters which spell the word for the concept. Arithmetic relations among the gematriya for different words signal conceptual relations among the ideas they denote.” “Where do you get this stuff? Reading Chaim Potok or something?” “Well, yeah, and Knuth for the random-number generator, but there are analogous numerological practices in other traditions, too. Should I add a note saying that the output of the random number generator is used to perform the sortes Vergilianae?” “No,” he said, “just shut up, would you?”)

In RDF, on the other hand, you do know some things.

You know the “meaning” of the RDF graph can be paraphrased as the conjunction of a set of declarative sentences.
You know that each of those declarative sentences is atomic and semantically independent of all others. (That is, RDF allows no compound structures other than conjunction; it differs in this way from programming languages and from predicate logic — indeed, from virtually all formally defined notations which require context-free grammars — which allow recursive structures whose meaning must be determined top-down, and whose meaning is not the same as the conjunction of their parts. The sentences P and Q are both part of the sentence “if P then Q”, but the meaning of that sentence is not the same as the conjunction of the parts P and Q.)

When my colleagues succeeded in making me understand that on the basis of these two facts one could plausibly claim that RDF has, intrinsically, more semantics than XML, I was at first incredulous. It seems a very thin claim. Knowing that the graph in front of me can be paraphrased as a set of short declarative sentences doesn’t seem to tell me what it means, any more than suspecting that the radio traffic between spies and spymasters consists of reports going one direction and instructions going the other tells us how to crack the code being used. But as Thomas points out, these two facts are fairly important as principles that allow RDF graphs to be merged without violence to their meaning, which is an important task in data integration. Similar principles (or perhaps at this level of abstraction they are the same principles) are important in allowing topic maps to be merged safely.

Of course, there is a flip side. If a notation restricts itself to a monotonic semantics of this kind (in which no well formed formula ever appears in an expression without licensing us to throw away the rest of the expression and assume that the formula we found in it has been asserted), then some important conveniences seem to be lost. I am told that for a given statement P, it’s not impossible to express the proposition “not P” in RDF, but I gather than it does not involve any construct that resembles the expression for P itself. And similarly, constructions familiar from sentential logic like “P or Q”, “P only if Q”, and “P if and only if Q” must all be translated into constructions which do not contain, as subexpressions, the expressions for P or Q themselves.

At the very least, this seems likely to be inconvenient and opaque.

Several questions come thronging to the fore whenever I get this far in my ruminations on this topic.

Do Topic Maps have a similarly restrictive monotonic semantics?
Could we get a less baroque representation of complex conditionals with something like Lars-Marius Garshol’s quads, in which the minimal atomic form of utterance has subject, verb, object, and who-said-so components, so that having a quad in your store does not commit you to belief in the proposition captured in its triple the way that having a triple in your triple-store does? Or do quads just lead to other problems?
If we accept as true my claim that XML can in theory express imperative, interrogative, exclamatory, or other non-declarative semantics (fans of Roman Jakobson’s 1960 essay on Linguistics and Poetics may now chant, in unison, “expressive, conative, meta-lingual, phatic, poetic”, thank you very much, no, don’t add “referential”, that’s the point, the ability to do referential semantics is not a distinguishing feature here), does that fact do anyone any good? The fundamental idea of descriptive markup has sometimes been analysed as consisting of (a) declarative (not imperative!) semantics and (b) logical rather than appearance-oriented markup of the document; if that analysis is sound (and I had always thought so), then presumably the use of XML for non-declarative semantics should be regarded as eccentric and probably not good practice, but unavoidable. In order to achieve declarative semantics, it was necessary to invent SGML (or something like it), but neither SGML nor XML enforce, or attempt to enforce, a declarative semantics. So is the ability to define XML vocabularies with non-declarative semantics anything other than an artifact of the system design? (I’m tempted to say “a spandrel”, but let’s not go into evolutionary biology.)
Is there a short, clear story about the relation between the kinds of things you can and cannot express in RDF, or Topic Maps, and the kinds of things expressible and inexpressible in other notations like first-order predicate calculus, sentential calculus, the relational model, and natural language? (Or even a long opaque story?) What i have in mind here is chapter 10 in Clocksin and Mellish’s Programming in Prolog, “The Relation of Prolog to Logic”, in which they clarify the relative expressive powers of first-order predicate calculus and Prolog by showing how to translate sentences from the first to the second, observing along the way exactly when and how expressive power or nuance gets lost. Can I translate arbitrary first-order predicate calculus expressions into RDF? How? Into Topic Maps? How? What gets lost on the way?

It will not surprise me to learn that these are old well understood questions, and that all I really need to do is RTFM. (Actually, that would be good news: it would indicate that it’s a well understood and well solved problem. In another sense, of course, it would be less good news to be told to RTFM. I’ve tried several times to read Resource Description Framework (RDF) Model and Syntax Specification but never managed to get my head around it. But knowing that there is an FM to read would be comforting in its way, even if I never managed to read it. RDF isn’t really my day job, after all.)

How comfortable can we be in our formalization of the world, when for the sake of tractability our formalizations are weaker than predicate calculus, given that even predicate calculus is so poor at capturing even simple natural-language discourse? Don’t tell me we are expending all this effort to build a Semantic Web in which we won’t even be able to utter counterfactual conditionals?! What good is a formal notation for information which does not allow us to capture a sentence like the one with which Lou Burnard once dismissed a claim I had made:

“If that is the case, then I am the Queen of Romania.”

Daniel Boone meets the consistent Web [C. M. Sperberg-McQueen]

2008-07-23T00:33:46+00:00

[22 July 2008]

My colleague Thomas Roessler writes:

[The monotonic semantics of RDF] guarantee that you won’t run into a world of inconsistency when you discover additional information, and they also guarantee that you can learn things about the world piece by piece.

My evil twin Enrique responds: So let us start with the information that “The individual denoted by http://www.w3.org/People/cmsmcq/2008/ns1#joe is identical to the individual named http://www.w3.org/People/cmsmcq/2008/ns2#Josephus”, which I assume I can express using some predicate like the OWL sameAs.

And now let us discover additional information in another triple store, which contains the information that “The individual denoted by http://www.w3.org/People/cmsmcq/2008/ns1#joe is distinct from the individual named http://www.w3.org/People/cmsmcq/2008/ns2#Josephus”, which it expresses using some predicate like the OWL differentFrom.

I’m having trouble understanding (concludes Enrique) how we can do this without either running into a world of inconsistency (a small world, perhaps, bounded in a nutshell, but still a world big enough for joe and Josephus to be both the same and different), or else running into a world in which we find that “inconsistency” has been defined to have a highly technical meaning under which the two triples just described are not actually inconsistent in the technical sense (why do I expect someone to start lecturing me about Herbrand models any moment now?), even though any application relying on the usual notions of identity and difference may find itself at a loss as to what to make of seeing them both in the same graph.

I reminded Enrique of the American pioneer Daniel Boone, who proudly claimed that he had never been lost in his life. Never? Never. [Pause.] “But I was a mite bewildered once for three days.” [Rimshot.]

Descriptive markup and data integration [C. M. Sperberg-McQueen]

2008-07-23T00:09:10+00:00

In his enlightening essay Si tacuisses, Enrique …, my colleague Thomas Roessler outlines some specific ways in which RDF’s provision of a strictly monotonic semantics makes some things possible for applications of RDF, and makes other things impossible. He concludes by saying

RDF semantics, therefore, is exposed to criticism from two angles: On the small scale, it imposes restrictions on those who model data … that can indeed bite badly. On the large scale, real life isn’t monotonic …, and RDF’s modeling can’t deal with that….

XML is “dumb” enough to not be subject to either of these criticisms. It is, however, not even trying to address the issues that large-scale data integration and aggregation will bring.

I think TR may both underestimate the degree to which XML (like SGML before it) contributes to making large-scale data integration possible, and overestimate the contribution that can be made to this task by monotonic semantics. To make large-scale data integration and aggregation possible, what must be done? I think that in a lot of situations, the first task is not “ensure that the application semantics are monotonic” but “try to record the data in an application-independent, reusable form”. If you cannot say what the data mean without reference to a single authoritative application, then you cannot reuse the data. If you have not defined an application-independent semantics for the data, then you will experience huge difficulties with any reuse of the data. Bear in mind that data integration and aggregation (whether large-scale or small-) are intrinsically, necessarily, kinds of data reuse. No data reuse, no data integration.

For that reason, I think TR’s final sentence shows an underdeveloped appreciation for the relevant technologies. Like the development of centralized databases designed to control redundancy and store common information in application-independent ways, the development of descriptive markup in SGML helped lay an essential foundation for any form of secondary data integration. Or is there a way to integrate data usefully without knowing anything at all about what it means? Having achieved the hard-won ability to own and control our own information, instead of having it be owned by software vendors, we can now turn to ways in which we can organize its semantics to minimize downstream complications. But there is no need to begin the effort by saying “well, the effort to wrest control of information from proprietary formats is all well and good, but it really isn’t trying to solve the problems of large-scale data integration that we are interested in.”

(Enrique whistled when he read that sentence. “You really want to dive down that rathole? Look, some people worked hard to achieve something; some other people didn’t think highly enough of the work the first people did, or didn’t talk about it with enough superlatives. Do you want to spend this post addressing your deep-seated feelings of inadequacy and your sense of being under-appreciated? Or do you want to talk about data integration? Sheesh. Dry up, wouldja?“)

Conversely, I think TR may overestimate the importance of the contribution RDF, or any similar technology, can make to useful data integration. Any data store that can be thought of as a conjunction of sentences can be merged through the simple process of set union; RDF’s restriction to atomic triples contributes nothing (as far as I can currently see) to that mergeability. (Are there ways in which RDF triple stores are mergeable that Topic Map graphs are not mergeable? Or relational data stores?)

And it’s not clear to me that simple mechanical mergeability in itself contributes all that much to our ability to integrate data from different sources. Data integration, as I understand the term, involves putting together information from different source to achieve some purpose or accomplish some task. But using information to achieve a purpose always involves understanding the information and seeing how it can be brought to bear on the problem. In my experience, finding or making a human brain with the required understanding is the hard part; once that’s available, the kinds of simple automatic mergers made possible by RDF or Topic Maps have seemed (in my experience, which may be woefully inadequate in this regard) a useful convenience, but not always an essential one. It might well be that the data from source A cannot be merged mechanically with that from source B, but an integrator who understands how to use the data from A and B to solve a problem will often experience no particular difficulty working around that impossibility.

I don’t mean to underestimate the utility of simple mechanical processing steps. They can reduce costs and increase reliability. (That’s why I’m interested in validation.) But by themselves they will never actually solve any very interesting problems, and the contribution of mechanical tools seems to me smaller than the contribution of the human understanding needed to deploy them usefully.

And finally, I think Thomas’s post raises an important and delicate question about the boundaries RDF sets to application semantics. An important prerequisite for useful data integration is, it would seem, that there be some useful data worth retaining and integrating. How thoroughly can we convince ourselves that in requiring monotonic semantics RDF has not excluded from its purview important classes of information most conveniently represented in other ways?

The OOXML debates (non-combatant’s perspective) [C. M. Sperberg-McQueen]

2008-07-22T19:22:25+00:00

[21-22 July 2008]

So far, I have managed to avoid participating in the debates over standardizing OOXML, and I don’t plan for that to change. But my evil twin Enrique and I spent some wickedly enjoyable time this afternoon reading a lot of postings in that debate, from a variety of sources, when I should have been working on other things. (“Log it as ‘Professional - continuing education’,” suggested Enrique. I may do that.)

It’s interesting to be able to observe a hard-fought technical battle in which (other people’s) feelings run high but in which one does not have a large personal stake. So many rhetorical maneuvers are familiar, the deterioration of the quality of the argument brings back so many memories of other technical arguments in which (distracted by caring about the outcome) the observer may not have been able to appreciate the rhetorical ingenuity of some of the contributions.

What strikes both Enrique and me is how distinct the styles of argumentation on the various sides of the debate are. We counted three, not two, in this battle, but we could be undercounting.

On one side, there is a class of contributions carefully kept as thoroughly emotionless as possible, focusing exclusively on technical (or at least substantive) issues — even when the contribution was intended to persuade others of a course of action. This seems, at first, an unusual rhetorical choice: I think most advertisers tend to prefer enthusiasm to a studied lack of emotion in trying to sell things. Still, this class includes some of the people whose judgement I have the most reason to respect, and in an over-heated environment a strict objectivity can be immensely attractive.

There is a second class of contributions, which provide a complex mix of a more emotional, excitable, even passionate, style of argumentation, which is however almost always tethered to concrete, verifiable (or falsifiable) propositions about technical properties of OOXML (and ODF), about process issues, and so on. The contributions of this class are by no means always well reasoned or insightful, but they are all recognizably arguments which can be refuted.

And there is a third class, which contains some of the most inventive ad hominem attacks, imaginative name-calling, and insidious smears I have ever seen outside of recent U.S. national electoral politics.

What is striking and puzzling to me is how cleanly the three different rhetorical styles seem to me to map to different positions (let me call them left and right, without mapping left/right into pro/con) on OOXML. If you see a statement that could in principle be verified or falsified by an impartial third party, there is a much better than even chance that it’s from a contribution arguing, let us call it, the left-hand position. And if you see an infuriatingly smug piece which avoids addressing actual technical issues and confines itself to name-calling, slander, and innuendo, there is a very strong chance that it’s taking a right-hand position. (I’m speaking here mostly of bloggers and essayists, not of those who have commented on various blog posts — the blog comments are uniformly smug and infuriating regardless of handedness.)

I have tried not to say explicitly which position each of these styles is associated with, because if Enrique and I are right then all you have to do is (re)read some of the rhetorical barrages of the last year or two to see which is which. (Those of my readers who care about the outcome, or about the health and reputation of the institutions involved, may find this too painful to contemplate. I’m sorry; you don’t have to if you don’t want to.) And if we’re wrong (and we may be — we only had stomach for an afternoon’s worth of the stuff, not more), then there’s no fairness in pointing the finger of blame at just one side for the incivility that can be seen in the discussion of OOXML.

And in any case, as Enrique points out with a certain malicious glee, “Most people who don’t look into it will assume that the merits of the technical arguments must be with the first or second groups, because they don’t descend (or more correctly they descend less often) to slander and name-calling. But there is no rule that says that just because those on one side of an argument argue unfairly or irrelevantly, or act with infuriating disregard of basic rules of courteous technical discussion, then it’s safe to conclude that they have the wrong end of the technical stick, any more than it’s safe to conclude that an invalid argument has reached a false conclusion. Unfairness and low behavior don’t mean people aren’t right in the end.”

Enrique may be right. But watching the OOXML debates serves as a salutary reminder that when some in a technical discussion descend to name-calling and slander (and what better to spice up a blog with?), the animosities created during the process will hover over the result of the decision for a long time.

Memo to self: in future, try to be calmer and more fair in discussions.

(“Yeah,” I hear Enrique mutter. “Leave the dirty work to me.”)

Treating our information with the care it deserves [C. M. Sperberg-McQueen]

2008-07-22T16:45:03+00:00

[21-22 July 2008]

I don’t make a habit of recording here all of the interesting, useful, or amusing things I read. But I am quite taken with Steve Pepper’s account of the situation in which many large organizations find themselves in. In a blog post devoted to a different topic (the history of Norway’s vote on OOXML), he describes (his understanding of) one organization’s point of view and motivations:

They are a big MS Office user, they participated in TC45 (the Ecma committee responsible for OOXML) and they clearly feel that OOXML is important to them.

I can understand why. An enormous amount of their intellectual capital is tied up in proprietary formats – in particular Excel – that have been owned and controlled by a vendor for the last 20 or so years. StatoilHydro has literally had no way of getting at its own information, short of paying license fees to Microsoft. Recently the company has started to realize the enormity of the mistake it has made in not treating its information with the care and respect it deserves.

As he points out, they are of course not alone in having made this mistake, particularly if one includes other proprietary formats beyond Office, and other vendors than Microsoft.

Several points occur to me:

It’s easy for me to feel superior and to lack interest in the problems of converting legacy data: I stopped using proprietary formats about twenty years ago, not very long after I had acquired a personal computer and gained the opportunity to start using them in the first place, and so with very few exceptions pretty much every piece of information I have created over my career is still readable. (A prospective collaboration did collapse once when at the end of a full-day meeting, as we were deciding who would draft what piece of the grant proposal, I asked what DTD we would be using, and my soon-to-be-former prospective collaborators said they had planned to be working in a proprietary word processor.) But feeling superior is not really a useful analysis of the situation.

Enrique: Are you saying that there are no proprietary data formats on mainframes? Whom are you trying to kid?

Me: No, but all my mainframe usage was on university mainframes; we don’t seem to have been able to afford any seriously proprietary software, at least any that was interesting to me. I was mostly doing document preparation, and later on database work. And for a while I maintained the terminal translation tables.

Enrique: The what?

Me: Never mind. There used to be things called terminals, and … Sorry I brought it up.

Enrique: And your databases didn’t use proprietary formats?

Me: Internally, sure. But they could all dump the data in a reusable text file format. I think I translated the Spires dump of my bibliographic data to XML once. Or maybe that was just something that went on the Someday pile.

Enrique: You’re right. Feelings of superiority are not really an adequate analysis of a complex situation. Even if the feelings were justified, which in this case, Bucko, does not seem to be the case.

The right solution for these organizations is, perhaps, to move away from such closed systems once for all, and use semantically richer markup. Certainly that’s where my immediate sympathies lie. It’s not impossible: lots of organizations use surprisingly rich markup for data they care about.
But how are they to get there, starting from where they are now? Even if the long-term benefits are substantial (which is close to self-evident for me, but is likely to sound very unproven to any serious organizational IT person), you have to get through the short term in order to reach the long term. So the ideal migration path starts paying off very quickly, even before you’ve gone very far. (Paoli’s Law: if people put five cents of effort in, they want to see a nickel in return, and quickly.) Can there be such a migration path? Or is going cold turkey the only way to go?
The desire to get as much benefit for as little work as possible seems to make everyone with a legacy-data problem easy prey for snake-oil salesmen. I don’t see any prospect of this changing, though, ever.

Enrique: Nah. Snake oil, now there’s a growth stock.

Interview: Roberto Scano on IWA/HWG and Promoting Web Standards [W3C Team]

2008-07-22T15:07:48+00:00

As part of a series of interviews with W3C Members to learn more about their support for standards and participation in W3C, I asked Roberto Scano (IWA/HWG Advisory Committee Representative at W3C) some questions.

Q. Would you mind introducing IWA-HWG in a few words?

A. IWA-HWG is a non-profit professional association for the education and certification of Web professionals. IWA's initiatives now support more than 100 official chapters representing over 160,000 individual members in 106 countries. IWA's accomplishments include the creation of guidelines for ethical and professional standards, Web certification and education programs, specialized employment resources, and technical assistance to individuals and businesses.

In 2001, the IWA (International Webmasters Association) and HWG (The HTML Writers Guild) merged and joined W3C to help represent Web professionals in the standards process and to give IWA members the opportunity to participate directly in that process. We are also endorsed by CEN as an association that create standards for certification of Web professionals and we are working with a UNESCO Institute for ICT to define standards for educational courses. We are involved in some W3C Working Groups (including in the area of Web Accessibility). We are also working on helping companies that do education and outreach understand profiles of Web professionals, i.e., what standard skill sets to expect.

Q. What are your roles in the organization?

A. I am the Project Manager for the international headquarters, EMEA (Europe, Middle East and Africa) coordinator, and the AC Representative inside W3C. I also coordinate the Italian chapter of IWA, where I live. So my roles are to coordinate the activities of IWA/HWG members inside W3C Working Groups, and also those activities occurring in Italy.

Q. Does IWA-HWG express opinions as an organization, or does it collect findings? If so, how are they established? Do you succeed in passing on those opinions/findings to W3C's Working Groups?

A. IWA-HWG members who participate in W3C Working Groups represent the spirit of the Association to promote "design for all." It is on this basis that we engage in Working Groups, and this suggests a sort of "default" shared opinion that we can use as a starting point: the Web of the future is founded on modern standards with accessibility, semantics, and modularization. We use a mailing list to share and elaborate personal viewpoints, especially before a "public" proposal and/or opinion inside the WGs.

Q. If you could get browser vendors to agree on three topics that would make life much easier for designers, what would those three topics be?

A. First of all, support standards. In particular: CSS, XHTML, and correct mime types for them. A second request would be to improve DOM scripting performance. A third would be to offer native supportfor semantic and multimedia languages (such as RDFa and SMIL).

Q. Do you observe that there is a big market (internationally) for standards-based design?

A. Yes, there is a lot of momentum right now because standards support is the fastest way towards support for the development of complex Web Apps, easy reuse and maintenance, even in an enterprise environment. From my prospective, using standards and following a few design principles (for instance, that accessibility is a core part of Web development, not to be handled as an "add-on") should be the minimum requirement for recognizing a Web developer as a real Web professional. In jurisdictions with laws related to accessibility (like in Italy, with the Stanca Act - but also in USA with Section 508), there is also an increase in Web standards support. In order to meet user needs in a global market, we need to ensure that Web developers are aware of how to make products standards-complaint and accessible. The main problem for us, then, is education and outreach in this area. Though there is a big market for standards, we have more work to go to help Web developers understand the opportunities afforded by standards-based design.

Q. What are the most important obstacles to people following standards-based design?

A. Perhaps disinformation. Standards are wrongly perceived only as a "serious" thing, temporarily out of Web fashion. We need to publicize all the coolest ways to build a true, rich and accessible Internet experience. If we go back in the history of the Web, we can find that a lot of current Web developers started with visual tools, without knowledge of markup. During my training sessions, I see a lot of Web designers that still prioritize visual results over semantic markup. Some problems result from what authoring tools (especially CMS) genera, if they do not produce valid code that follows standards. The association promotes standards as a first principle because standards enable more flexibility and more support by browsers and assistive technologies.

Q. Are there areas of work that you (or your members) would like to see W3C prioritize?

A. We think that W3C should prioritize activities like the Ubiquitous Web Applications Activity. The time for Web Apps has come, and W3C should do what it can to promote the development of standards-complaint Web Apps that are accessible and universally usable with computer, PDA, and so on. We are also strongly interested in support for serious markup languages for Web Apps, such as XHTML 2.

Q. Why is Flash so alluring to web site designers? What can W3C provide as an open technology that meets their needs (i.e., what features need to be easily available)?

A. Flash is used especially by graphic designers who want to give more "action" to Web pages (including those intended to sell products). Flash has grown up and now is a modern tool to build Web Apps with its own language. But if we think about a "Flash without Flash" we will have the same results, for example with the fundamental help of javascript, XML, SMIL and SVG.

Q. What is the most problematic misconception about Web technologies that Web developers face with clients, and how do they clear it up?

A. The Web is still a sort of a mystery for many clients, especially in the "classic" ICT world often found in public administrations. Also, some clients continue to think of the Web as primarily a passive medium (or just a big videogame). So we work to explain new ways to participate, and how data-driven applications can create a rich Web experience for sharing information with more and more people.

Q. What would you recommend to a web technology enthusiast who wants to get involved in W3C or Web Standards?

A. To be strongly curious and ready to learn and conduct research independently. And maybe to join our association and connect with other Web professional. Let me add that getting involved also means having fun, because standards are sexy just like the Web! :)

Q. Similarly, what would you recommend that W3C do to lower barriers to participation? The HTML Working Group is an ongoing experiment on open participation in a Working Group. Do you have additional suggestions?

A. Yes: Do not forget that democracy without rules is only a mess, so the birth of a new language or specification needs to be a balanced mix between creativity and ratiocination: this can be done with a reliable and collaborative community of experts.

Q. Would you recommend to a Web design company to become a W3C Member? What aspects of W3C membership would benefit them most?

A. I personally appreciate hearing about TimBL's ongoing vision of the Web (starting with an early talk). I think active participation in W3C groups gives engineers an advantage in the market when a specification matures to standard. We suggest to large companies (especially here in Italy) to join inside W3C and share knowledge inside Working Groups, but there are some organizations that may not have sufficient human resources to dedicate to the development of the standards, or related research and development activities.

Q. We are currently redesigning portions of the W3C Web site and are talking with people in the community about changes they would like to see. How could W3C improve its Web site to make it more useful to Web designers and developers?

A. Apply some of the innovative languages proposed in the Recommendations. Make it standards-compliant and attractive. Make it useful for more people!

Many thanks to Roberto for his answers.

Si tacuisses, Enrique, ... [Thomas Roessler]

2008-07-20T14:48:46+00:00

Among the great privileges of working at W3C is the occasional geeking with people like Michael Sperberg-McQueen's evil twin Enrique. Enrique's latest is on what RDF gets us. In that blog item, RDF is characterized as an extremely thin semantic layer -- interestingly, ignoring the RDF Semantics recommendation. The point of that recommendation is that RDF is -- even when you ignore RDF schema, OWL and friends -- more than just nodes, arrows, and URIs. The critical piece that's added is a bit of logic that effectively tells you the following rules (which are really flip-sides of each other):

You can always add more stuff, and that won't invalidate anything you've learned so far.
You can always remove stuff, but you won't learn anything new if you do.

If you think of RDF as a framework to do web-scale data aggregation, then these are very useful principles: They guarantee that you won't run into a world of inconsistency when you discover additional information, and they also guarantee that you can learn things about the world piece by piece. These principles permit relatively stupid and generic software to draw useful conclusions without knowing anything about the "real" meaning of data. They are also why comparing XML and RDF is comparing apples and oranges: There's nothing in XML that permits software to make similar assumptions; XML's semantic layer is indeed thinner than RDF's. All the interesting logic needs to be dealt with on the application layer. Now, one important piece of Enrique's thinking is that precisely the thinness of RDF's semantic layer (similar to the thinness of XML's) is what makes it appealing. So, what does the semantic layer that the RDF Semantics add mean for that argument? The gain is clear, in that tools can make stronger assumptions about the data they deal with, and some aspects of application logic are pushed deeper in the stack. The price, though, is that those who model data on top of RDF need to understand what constraints are imposed on them by the format's properties -- in an RDF world, there isn't much of a "no"; "si tacuisset, philosophus mansisset" is a conclusion that won't work, since once you're a philosopher, you remain so till the end of your days. RDF semantics, therefore, is exposed to criticism from two angles: On the small scale, it imposes restrictions on those who model data -- restrictions that are harder to understand than those imposed by just using XML trees, and that can indeed bite badly. On the large scale, real life isn't monotonic (we invalidate prior knowledge all the time), and RDF's modeling can't deal with that. The first of these criticisms is ultimately about the ability of people to use the model. The second is about the problem space to which the model can be applied. XML is "dumb" enough to not be subject to either of these criticisms. It is, however, not even trying to address the issues that large-scale data integration and aggregation will bring.

Six-month retrospective and evaluation [C. M. Sperberg-McQueen]

2008-07-17T00:34:55+00:00

[16 July 2008]

This klog started about six months ago, as an experiment. In an early post, I wrote:

So I’m going to start a six-month experiment in keeping a work log. Think of it, dear reader, as my lab notebook. (I was going to do it starting a year ago, but, well, I didn’t. So I’m going to start now.)

My original plan was to make it accessible only to the W3C Team, so that I could talk about things that probably shouldn’t be discussed in public or in member space. Norm Walsh has blown a hole in that idea by pointing to this log [Hi, Norm!]. So public it is. (Ideally, I’d have a blog in which each item could be marked with an ACL, like resources in W3C date space: Team-only, Member-only, World-readable. Maybe later.)

Next year about June, if I remember, I will evaluate the experiment and decide whether it’s been useful for me or not.

So, as one of my teachers used to say at the beginning of a group evaluation of some student work: what works, what doesn’t work?

Things that don’t work as well as I would like:

As might have been predicted, the fact that Messages in a Bottle is public, not private, has encouraged me to be circumspect in ways that fight with the lab-notebook goal. I don’t want to be carelessly rude about colleagues or others in public, the way one can be in private conversations and to their faces. Across a dinner table, one can greet a claim made by a colleague with a straightforward cry of “But that’s bullcrap!” without impeding a useful discussion. (This depends in part on the conversational style cultivated by individuals and groups, of course. But as some readers of this post will know, this is not a speculation but a report.) It doesn’t feel quite right, however, to say in public of something proposed by someone acting in good faith that it’s just bullcrap. You have to spend some time thinking of another way to put it. Enrique comes in handy here, since he will say anything. It has not been proven, however, that Enrique will never piss anyone off.
For the same reason, I have not yet found a good way of recording issues and concerns I don’t have good answers for. In a lab notebook, or a private conversation, one can talk more forthrightly about things that are going wrong, or things that have gone wrong, and how to right them. But in public, members of a Working Group, and editors of a specification, do better to accept a sort of cabinet responsibility for the work product. You do the best you can to lead the group to what you believe is the right decision, and then you accept the decision and defend it in public. I have not yet found a way to combine the acceptance of that joint responsibility, and the concomitant need to avoid bad-mouthing decisions one is responsible for defending, on the one hand, with forthright analysis of errors on the other. Sometimes careful phrasing can do the job, but any need for care in phrasing constitutes a tax on the writing of posts about tricky subject matter.
So try as I might to keep pushing these posts toward being a work log, the genre keeps pushing back and trying to make them into something like a first-person newspaper column. That’s a fine and worthy thing, and I can’t say I don’t enjoy that genre, but it’s not quite what I was aiming for when I started. As a result, one cannot read back through the archives and get the kind of record one wants in a lab notebook, and I’m not sure Messages in a Bottle is working optimally as a means for me to communicate with myself, or with those I work with most closely.

And on the other side, some things do seem to work.

At one level of abstraction, the primary goal of this worklog is to improve communication between me and those I work with. There is some evidence, both in the comments here and in other channels, that some of those I work with do read these postings and find them useful, or at least diverting. I have never bothered to try to check the server logs for hit or visitor counts — my guess, based on my Spam Karma 2 reports, is that humans are strongly outnumbered by spambots among my readers, and I’d just as soon not have that demonstrated in quantitative detail — but it’s clear that more people read these posts at least sporadically than I would ever dream of pestering by sending them email meditations on these topics. If they read these posts and derive any insight from the reading, then this klog would appear to have improved communication at least somewhat.
It’s probably not actually a bad thing that I think of this as a public space. It makes me a bit more likely to try to write coherently, to supply relevant context, and to do the other things that help ensure that a communication can be read with understanding by readers distant in time, space, sentiment, or context from the author. If I occasionally indulge in a private joke or two, I hope you will bear with me.
It’s easier for me to find records of points of view and analyses that have gone into posts here than to find records kept only in files on my hard disk or on paper shoved into the shelves behind me.
So far, no one has complained even about the really boring technical discussions about regular grammars, even though it’s clear some of my readers would rather be reading about Enrique.

In sum, I think I believe the experiment can be adjudged modestly successful, and I will continue it for another six months.

Dear W3C… [W3C Team]

2008-07-16T20:08:33+00:00

A week or so ago, while browsing the getsatisfaction site for a solution to a software problem, I stumbled upon a “customer support” forum for W3C. I didn't know W3C had a customer support forum there… Actually, nobody in the W3C staff had heard about it, either. And indeed, : someone had thought this was as good a place as any to start a forum for discussion and troubleshooting of W3C technologies, and had started the forum.

Maybe I should not have been so surprised: years spent reading and participating to W3C-centered discussions on weblogs, lists, IRC, chat, twitter and so many other venues is more than one needs to know that a lot of interesting discussions happen in diverse fora outside W3C.

W3C is already offering a rather dizzying variety of media for feedback, discussions, ideas and issues. With many archived mailing-lists completed, for some groups, by a wiki collaborative space, blog, issue tracker or IRC channel, there are already plenty of places for W3C participants to look for feedback and for anyone to initiate discussions.

Choosing what to monitor has been a serious dilemma for a number of W3C working groups to solve: participation in discussions take a lot of time, and groups want to use their time as effectively as they can to get specs done. In that regard, the W3C mailing-list are valuable because of their archives' policies and commitment to privacy and persistence, in an effort to make the discussion safe and worthwhile: user data will never be sold, and W3C is more likely than any other site to keep its discussion archived, searchable and available to all forever, ensuring that the archived answer to a frequent or important question will stay cool forever.

On the other hand, there is no denying the value of engaging communities without waiting for them to “speak to the W3C”. Every day I hear stories of successful hacking projects, excellent new ideas, fixed misconceptions, happening in venues sometimes very remote from the usual w3c fora.

W3C can do a lot more to make it obvious, simple and absolutely worthwhile to find out what is happening inside a group and find out the best way to join the conversation. The current effort on re-designing and improving the user experience on the W3C site should be a step in that direction. And maybe the other key to this dilemma recognizing the time and effort it takes to find the right people to talk to and learn how to speak to one another? That takes time, but can lead to a big return… whether it is in w3c groups or other fora.

RSS 1.0 and RDFa [W3C Team]

2008-07-15T02:46:46+00:00

How do you express a feed using RDFa in a plain XHTML page? Microformats has a proposal for Atom called hAtom. Michael Hausenblas didn't want to write yet another specification or give abstract examples, so he took the way of running code. He proposed a simple RSS2RDFa Transcoder. Starting from real RSS 1.0 feeds in the wild and trying to express them in XHTML+RDFa will help to figure out what is needed.

He tested on Identi.ca which offers RSS 1.0 feed, the result is an XHTML+RDFa page.

Eleemosynary RDF [C. M. Sperberg-McQueen]

2008-07-15T01:57:16+00:00

[14 July 2008]

I spent last week in meetings with (among others) a number of enthusiastic proponents of RDF. The meetings were for the most part quite useful and constructive: we spent a lot of time trying to come to grips with the fact that W3C is investing a lot of time and effort in what look like parallel and competing stacks for RDF and XML, and trying to find our way to a simple story about how the two relate. And as one colleague said: no one was trying to “win”, everyone was just trying to understand and solve the problem.

My evil twin Enrique elbowed me in the ribs when he heard this, and suggested that this charitable generalization had some exceptions. You have to make some allowances for Enrique: re-encountering the rhetoric of RDF advocates at close range had put him in a bad mood at what he regards as the tone-deaf style of some arguments for using RDF. A full catalogue would take a long time (and would only lead to bad feeling), but during a lull in the meeting, Enrique whispered to me “Listen! If you listen carefully to the rhetoric, what you hear is that none of these RDF peeople believe in their hearts that using RDF is useful for the person or institution who actually creates and maintains the data! It’s all about making things easy for other people, about you eating the vegetables so I can eat dessert, about taking one for the team. I bet the records of Nurmengard were kept in RDF!” “Hush!” I said. “People will hear you.” But I have to admit, he had a point.

You should use RDF, the argument frequently goes, because if you do, then we can reuse your data much more conveniently.

When one of the meetings was considering a possible list of speaking points, I suggested (to keep Enrique quiet) that the point about using RDF so that other people could reuse the data more easily might perhaps be recast to suggest that using RDF could help the creators of the data better achieve their own goals. Sometimes the primary goal of data collection to make the data available for others to use. But often, in the real world, those who collect data do so primarily for their own purposes, and asking them to incur a cost in order that others may benefit seems to require a higher level of altruism than commercial, educational, or governmental institutions always exhibit.

No, a colleague replied emphatically, the point of the semantic web is that you incur costs now so that others can benefit later.

After several days, I’m still uncertain whether he was indulging in sarcasm, irony, or persiflage by parodying my paraphrase of the draft speaking point, or whether he was stone cold serious. At the break, Enrique went out and painted “For the greater good” over the entrance to the building where the meeting was being held, and wrote “Welcome to Nurmengard” on the whiteboard, but thankfully someone erased it before the meeting resumed.

I was reminded of something I once heard Jean Paoli say about persuading people to try a new technology. Using an unfamiliar technology requires an investment of effort, and the user you are trying to persuade needs to see that investment paid back very quickly. If someone puts five cents of effort in, Jean said, they want to see a nickel paid back in return, and preferably right away.

Note: Enrique reminds me that not everyone who reads English can keep the colloquial terms for American coins straight. A “nickel” is a coin worth five cents. (So Jean Paoli was saying people want to break even right away on their effort, not that they want to show a profit.) Oh, and Nurmengard is the prison built by the dark wizard Grindelwald to house his opponents; it had “For the greater good” carved over its entrance. (Enrique says that that is overkill: there isn’t any adult left who hasn’t read the Harry Potter books, so that gloss is unnecessary.)

One of the reasons I found Tom Passin’s talk about his use of RDF persuasive and interesting, last August in Montreal, was that he suggested plausibly that in the situation he described, using RDF might have short-term benefits, not just pie in the sky by and by. I think I’m as interested in long-term benefits as the next person. But a technology seems likely to achieve better uptake if using it brings some benefit to those who use it, independent of the network effect. Why do so many proponents of RDF behave as though they can’t actually think of any benefit of RDF, except the network effect?

Enrique on what RDF gets us [C. M. Sperberg-McQueen]

2008-07-15T01:56:38+00:00

[14 July 2009]

As reported in my previous post, I’ve been thinking about RDF a bit lately. So I’ve decided to dust off some meditations on the subject that originated several years ago.

I was feeding the dogs one evening when Enrique dropped by and complained bitterly about the shortcoming of various colleagues’ attempts to persuade people (including me) of the value of RDF: the overstatement, the misrepresentations of other technologies (both XML and relational databases), the overselling of RDF’s virtues. “True, they would make anyone with any marketing sense tear their hair out,” I said. “But it’s not rational to infer that there are no arguments for RDF, just because its advocates make such a poor show of arguing for it. If you want to understand what RDF does, without overstatement and without mischaracterization of other technologies, why don’t you try constructing a dispassionate account of what RDF does and doesn’t get us?”

Enrique’s response was something like what follows.

It should be noted that Enrique focuses here on RDF itself, not RDF + OWL. OWL was still very new at the time, and Enrique was reacting to years of rhetoric about how RDF, by itself, was semantically richer than XML. I have also corrected a slip or two in Enrique’s original effort; he couldn’t remember the term phatic, for example.

I wonder (Enrique said) if RDF can be summarized in three points:

It proposes a way to think about information: there are things, they have properties.
It proposes that we use a single universe of names for all individuals: URIs.
It provides a single model of property attribution, namely the binary predicate, and thus gives us three well known roles (subject, verb, object, or relation-name, first-argument, second-argument) for participants in relations.

These may be worth some commentary.

It proposes a way to think about information: there are things, they have properties.

There’s no proof that all information, or all knowledge, or all propositions, can be thought of as being about things with properties. In fact, there are many very bright philosophers who deny it outright. But those who deny it don’t provide anything of similar convenience for machine processing.

Formal logic as usually taught today similarly tells us how to talk about things with properties. It’s quite plausible that there are things we can’t express conveniently or at all in formal logic — just look at the mess formal logicians are in trying to justify the truth table for material implication — but just as formal logic can be useful even if there are things it cannot do, so also for any way of talking about things and properties.

Things and properties, as usually considered, don’t capture very well the expressive, conative, metalingual, or phatic aspects of language, as Jakobson calls them (let alone the poetic), just the representational. Again, like logic.

It proposes that we use a single universe of names for all individuals: URIs.

URIs are interesting in part because they are simultaneously a unified set of names and a distributed system. Using them, we can eliminate ambiguity (if URIs are correctly used), though not synonymy.

Contrast naming disciplines in SQL, DTDs, programming languages, first-order predicate calculus, or natural language, with uncoordinated naming.

Contrast also naming disciplines involving central authority (’use-mine-or-nothing’). If I remember correctly, there are central authorities who control Linnaean nomenclature, and names for specific geological formations, and the names of compounds given in official pharmacopeias.

It provides a single model of property attribution, namely the binary predicate, and thus gives us three well known roles (subject, verb, object, or relation-name, first-argument, second-argument) for participants in relations.

This simplicity, together with the lack of ambiguity in URIs when properly used, means that merger of arbitrary sets of triples is safe and easy. When predicates of arbitrary arity are allowed, merger can be more complex, or less effective, because when two sets of normalized relations are merged in a straightforward way, the result is not necessarily normalized. When things are resolved to triples, they are always in normal form. So the primary reasons for sub-optimal results after merging sets of triples are failures to merge owing to undetected synonymy, entailment relations other than synonymy (variation in specificity), variation in methods of currying n-ary predicates, and orbis-tertius variation.

“Orbis-tertius variation? What on earth are you talking about?” “Nothing on earth! It’s my short-hand way of talking about the radically underdetermined nature of our ad hoc ontologies. It’s a reference to Borges’s story Tlön, Uqbar, Orbis Tertius, my favorite treatise on ontology. Think of it as …” “… kind of an hommage. Right,” I said.

Ontological variation, by contrast, which shows up in variable-arity systems as difference of opinion about just what domains should be regarded as involved in an n-ary relation, does not cause problems for triples.

After he left, I realized I have no idea what Enrique meant by this.

Like the element/attribute distinction and child/parent, sibling/next-sib relations in SGML, this is a very thin standardization layer; it means almost nothing (which is why there can be so many sources of semantic variation). And again like the element/attribute model of SGML, that little turns out to be quite a lot, merely because that thin layer of standardization provides hooks that allow software to provide meaningful and useful operations defined in terms of those three roles. These operations can be performed without the software having the least idea of the meaning of the data (which is one reason it is so bizarre that Semantic Web enthusiasts insist so fervently on the implausible claim that the semantics of RDF data are overt in ways the semantics of other formats are not — I suspect the problem is that those particular enthusiasts think the distinction between circles and arrows counts as ’semantics’.)

The semantic advantage of both SGML and RDF over some of their more obvious alternatives is this: precisely because they don’t define a prescribed semantics, the user can model whatever the user is interested in, using the primitive objects and relations built into the system to model whatever they wish to take as the primitive objects and relations of the system they are interested in representing. When this works well, operations on the primitive objects and relations can be used to model operations in the application domain, and the user has the feeling of being able to work ‘directly’ with the concepts of the application domain, with reduced need to pay attention to details of the representation. The ‘universality’ achieved by such a semantically thin layer of primitive notions is exactly parallel to the universality of s-expressions and relations and it is not surprising that the advantages we feel to accrue from XML and/or RDF are very similar to the advantages claimed for s-expressions by Lisp enthusiasts and for the relational model by Codd, Date, and the relational warriors of the 1970s and 1980s.

Because the primitive notions of RDF (things and properties) are explicitly tied to ideas of modeling, they feel (at least to believers) more nearly ’semantic’ than the notions of other systems (e.g. XML or s-expressions). The thinness of the triple layer can be an advantage, not only in simplifying the universe of possible primitive operations, but also in reducing threshold anxiety. (More elaborate modeling systems invariably require something like a leap of faith; RDF’s tenets are thin enough and bland enough to make its required leap of faith somewhat smaller and less frightening.) And thin as it is, the subject/verb/object model does allow an infrastructure that knows nothing of the semantics of the information to do a lot of useful things, just as the semantics of the relational model allow RDBMS which understand nothing of application semantics to do a lot of useful things.

Some things it does not do (although prominent exponents of the Semantic Web sometimes speak as if it did):

provide ’self-describing data’ (if such a thing exists at all)
ensure that ‘the semantics’ of data are always explicit or always understood
guarantee that data from different sources are usefully mergeable
tell us how to understand, model, formalize our data
tell us how to validate our data
tell us how to express complex relations clearly (this problem is not only not addressed by RDF; RDF does as much as any notation or model can to render it insoluble)
This may have been true when Enrique first wrote this, but the situation has perhaps changed with the publication of the Note Defining N-ary Relations on the Semantic Web, published in 2006, which recommends that tuples be reified with a gay abandon that might cause even avowed Platonists to pause and wonder whether all of those things really should be treated as individuals by our logic. Determined nominalists may be horrified by the recommendation, but it’s no longer true to say that the RDF community doesn’t say how to handle the problem.

Some fans of RDF will perhaps feel that Enrique has shortchanged RDF here, but I have to say that Enrique’s arguments have gone a long way toward making me think RDF could be useful, even if I am still not a committed as I suspect some of my friends in the W3C’s Semantic Web Activity would like.

If this message in a bottle is ever read by anyone, I will be interested to hear back from you on whether you find Enrique’s analysis persuasive.

Interview: Charles McCathieNevile on Opera 9.5 and W3C Standards [W3C Team]

2008-07-14T21:31:09+00:00

In June 2008, Opera Software released version 9.5 of its browser. As part of a series of interviews with W3C Members to learn more about their support for standards and participation in W3C, I asked Charles McCathieNevile (Opera's Advisory Committee Representative at W3C) some questions.

Note: Upcoming interview: Roberto Scano of the International Webmasters Association / HTML Writers Guild on standards-based authoring.

Q. What are your favorite new features of Opera 9.5? Can you pick one or two favorites for each of these W3C-related topics?

On Support for HTML 5

A. Naturally, we have a complete implementation of the final version of HTML 5...

Seriously, it's still a draft of course. Improvements to its parsing algorithm, reflected in improvements to ours, and continuing convergence in the way browsers build an HTML DOM, are really important to the Web, but somewhat incremental steps, so it is hard for me to pick a particular highlight in this area from 9.5.

Some of my favourite stuff that seems destined for HTML 5 is still not in the spec: Webforms 2 brings things like <input type="date"> for a date picker or the ability to make an input+dropdown list in declarative markup, instead of massive amounts of javascript. But that was already released in older versions of Opera. And there is canvas, which we have had in previous releases, but which is now clearly happening in W3C.

So for me the best HTML5 that is new in Opera 9.5 is Accessible Rich Internet Applications (WAI-ARIA). We're talking about an experimental implementation of an unfinished spec being incorporated into another unfinished spec, so there is plenty of good stuff to come in this area. But I think it is a really nice piece to have working, and the first implementation we have released is in 9.5.

I also have a disappointment. It wold be nice to have video there, but until we get a royalty-free way of enabling everyone to do that it is hard to make it high priority. So we didn't end up releasing that in 9.5, although I encourage W3C to keep following this up and find a useful solution because video is important on today's Web and should be interoperable and open enough for people to build products.

On Support for CSS

Personally, the most exciting stuff in CSS is that we made a significant level of MathML support possible through the MathML for CSS profile, and that we can use SVG in CSS backgrounds, list buttons, etc.

This probably shows how boring I am. I am not a designer, and I realise that any true designer would give very different answers about what rocks for them. Chris Mills wrote about a bunch of new CSS stuff in 9.5 that is pretty cool, like the effects you can get with multiple text shadows. Håkon [Wium Lie, Opera Chief Technology Officer] is excited by our CSS3 selectors work, which is great stuff.

But for me the MathML and SVG stuff running on my OLPC is one of the things about 9.5 that really rocked my boat.

On Support for XSLT 2, XForms

We have had effectively zero demand for these features. It is possible to use Xforms through javascript libraries in Opera, but I have not done it for a while. We did fix up a few bugs that were troubling people in our XSLT 1 implementation, which was important to the Web.

On Support for Accessibility

This question is easy for me - rebuilding screen reader support, which is a major ongoing effort under the hood, shows its nose in the public release build with Opera 9.5 on Mac and Windows. Given that it is difficult to work with Windows-based screen readers, I would suggest you try this feature out on a Mac (besides, you don't have to buy VoiceOver separately as it is part of the OS).

As a close second I would name ARIA. Again, our support for this is experimental - the spec was having some crucial parts nailed down as I was writing these answers - but we are proud of our contribution, which includes solving a problem with namespaces so it is possible to use ARIA interoperably in HTML, SVG, XHTML or XHTML2, and allows it to be incorporated into other XML/namespace-based languages like DAISY or MathML as well.

On Support for Security

We continue to work hard making sure we are the most secure browser. 9.5 brings support for the so-called EV ("Extended Validation") certificate, where a user knows not only that someone bought a certificate to encrypt their data, but that the the people who sold that certificate can actually find the person who bought the certificate, and if something goes wrong you therefore have some real means of redress.

We also worked pretty hard on our anti-fraud and anti-malware protection, covering both sites you visit and things you might download. Overall we have worked on making security user friendly, and at the same time powerful enough to protect users who want to use the web and what it has.

Users need simple guidance they can understand, as well as the power to do complicated things like decide whether to accept a certificate from an unknown authority (something that only makes sense to a few power users).

On a Mobile Experience

Opera Mobile 9.5. Opera Mini.

The HTC Touch Diamond is a high-end piece of hardware with a manufacturer who wanted a great Web browser, and chose Opera Mobile 9.5 - I think they were the first to announce it in a product, with the Samsung i900 also having it. Because these are windows mobile browsers built on our cross-platform core, we can provide similar levels of experience on other pieces of hardware for other suppliers, and I am looking forward to the public beta being available soon for anyone with a windows mobile phone.

Opera Mini is not running Opera 9.5 in the current 4.1 release. But it has been a game changer in the world of mobile web over the last 18 months. Mobile browsing has started really taking off, and Mini has been one of the major contributors to this. Lifting the level of what is available on a mobile phone, not just to the relatively tiny 'smartphone' market (the top few percent, who already have access everywhere) but to the much larger featurephone market which includes many people globally who have no other form of internet access, strikes me as a pretty big benefit in a world where increasingly web access is as fundamental as literacy to equal participation in society.

Beyond both those things, there's lots of stuff we have done in Opera that is relevant to mobile browsing. We reverse-engineered the "make it work for the iPhone" HTML hack and figured how to integrate that with the CSS standards-based approach we were already using, we further improved Opera's zoom, we put our leading SVG implementation into our native mobile browser (we had used the already good Ikivo plugin for SVG) as part of the upgrade to Core 2, added widget support, among zillions of other fixes and improvements.

But I think some of the most exciting stuff in mobile is not especially standards-oriented yet - Opera Link allows you to synchronise various kinds of information between mobile and desktop browsers, and this seems something that others want too, with Mozilla's "weave" heading the same way.

Q. Are there some noteworthy changes that will make cross-browser authoring easier?

A. Yes. These fall into two categories.

We have further improved our standards support in a variety of areas. As mentioned above, we improved our XSLT engine. But in some cases this is more a case of waiting for other browsers to catch up in order to allow people to use things reliably. As far as I know we are still the only browser shipping with a decent @media implementation, for example - a ten-year-old piece of CSS that makes for simple slideshow creation, or allows basic sites (the "long tail") to adapt to mobile rendering pretty painlessly.

There are also non-standard things we have to make compatibility for. Matching the strange bit of code Apple gets people to use so their sites look alright on iPhones, bringing undocumented or unspecified APIs closer in line with what other browsers do, and so on. But we have also made a point of trying to get the undocumented hacks, as well as the pure innovations, into the standards track so it is easier for everyone to improve interoperability, and for developers to know what really happens out there on the Web.

The second important change is the major upgrade of our developer tools, called Dragonfly. Still in beta, these are now designed to provide the power that developers have relied on Firebug to give them - but with some added bonuses. Because we have a very cross-platform browser, our tools are designed so you can debug remotely - see your code running on a different machine, or in a different browser instance (perhaps take a random weekly build from the Opera Desktop Team and debug it with your stable working release) or, importantly, on a different device. Since this is built into Core 2.1, as soon as mobile browsers are shipped based on Core 2.1 you will be able to debug what is happening in your real mobile (not an emulation on a desktop architecture), live from the comfort of your desktop.

Q. Can say a word about Opera's priorities in CSS support for the next year or so (and how they align with those of the CSS Working Group)?

A. There are some shiny features being shown off in the CSS Working Group, like using basic SVG features through CSS to apply them to HTML documents. We would like to see this work cleaned up, and the interactions with SVG in particular (which it replicates) carefully considered, but we think there are still lots of useful things that could be one with CSS (as well as some things that are better off done in markup).

We would also like to see CSS specifications advance in maturity. There are lots of things that can be done easily with CSS (our MathML implementation is based on having decent stylesheet support, being able to do seriously good HTML/SVG/etc slideshows or simple adaptations of a site to different devices is based on the ten-year-old @media rule) but there needs to be a lot of basic work done to give the design community a stable target. Webfonts is something that Håkon has recently been focussing on, because it is, as he says, well past time that we moved beyond a handful of proprietary fonts that were generously donated, and unleash people's ability to design real fonts for real text not just in SVG but for the entire Web.

I think this is broadly in line with the CSS working group, and we are basically happy with the priorities of that group if they can get specs moving along the process and completed.

Q. Does Opera 9.5 ship with XForms in the default configuration? If not, is there a reason we should be aware of?

A. Nope. We haven't seen any demand, nor any content on the Web that is causing major compatibility problems by requiring it. As I mentioned already, there are javascript-based implementations that can be used in a intranet setting, and so far that has been sufficient so we have focused our development efforts on other things. (I might add that although we actually support a relatively large amount of XHTML 2, it is more or less by accident, and it is for essentially the same reasons that we don't focus on implementing it completely).

Q. Can you comment on the state of SVG implementation in Opera 9.5?

A. It is pretty good. (That's Australian understatement we inherited from the British. It means "We Rock").

Alternatively could let the SVG community comment - we are listed on codedread (the site of the new SVG Interest Group chair Jeff Schiller) as the best native implementation going around, with the quote

"In roughly a year, the Opera browser went from being one of the least usable SVG implementations (no scripting/DOM support) to the best native implementation"

(which is slightly more presentable than his most enthusiastic comment about Opera, about kicking, and parts of the body).

We are working on further improving but I think our SVG work, in implementation, in contribution to the specification, and in contribution to the community, is something to be proud of, and the SVG and Graphics guys have done a great job.

Q. W3C has a goal of designing technology that works well on different types of devices with minimal or no additional effort for authors and readers. Opera creates Web software for many different devices (e.g., for desktop environment, mobile phones, and game consoles). From your perspective as browser developer, what challenges do you face when developing for different environments? What would you suggest that W3C do (e.g., improve existing technology, develop new technology, provide tools, promote education) to make it easier to develop for different environments?

A. Challenges come in 4 ways. The first is hardware - we have squeezed recent Opera builds onto platforms that were below our minimum specification for Opera 1, and we now have CSS, ECMAscript and DOM, and other features of the modern Web. In this sense it is important to ensure that specifications focus on what people really need, since anything else is at risk of being dumped in order to maximise the efficiency of the platform, but also because building what people use everyday into native code, rather than needing some javascript extension library, is important for performance.

Of particular concern in this context is battery life. People rely on phones in particular not just for Web access, but as a crucial tool in their everyday life (and in some circumstances as a vital part of their personal security). Running down the battery through poor design of standards is really quite unhelpful.

The second is input - as you move from a keyboard to a voice interface, or waving a wand (or game controller), or a small touch screen, a joystick or a limited keypad, you need standards that consider this range of input. At the same time we are seeing a growth of applications, whose designers want to build so the user thinks s/he is interacting with a normal application. We need much more thoughtful design of input mechanisms to cope with the huge variety of devices around. Some of this work is pretty old - WAI and the early device-independence groups at W3C have been dealing with this kind of problem for a decade and more. But the knowledge and attention to this problem are still very unevenly distributed through W3C.

The third is output - different devices also have different ways of presenting information - and we are constantly inventing new ways of using them. Zoom was once something Opera did with a simple scaling effect, with the variety being text zoom where you could change the font-size. Then came fit-to-width, ensuring that the layout reflowed even when the designers forgot, and small screen mode, and over the last 3 years zoom has become much more powerful and intelligent, with what we call "Opera zoom" intelligently and dynamically reflowing the zoomed section of what is basically a large-screen view to provide for ease of use and user efficiency - this is something that you can now see in various browsers on different devices. And here I have only mentioned screens - there are also voice, various kinds of tactile feedback, the use of "soundscapes", and so on to consider. Again, there has been work in this area for years, but spreading the knowledge and ensuring the review of new work by people who have been working in this area is important.

The other potential concern is security. W3C began with virtually no attention paid to security aspects of its technology, I think because it was initially a group of high-minded and like-thinking people who simply didn't consider the "dark side" as something that could be interesting, and who were working with essentially public data. The Web now reaches into your phone, a device whose capability to run up bills and provide personal information matches a credit card - and security and trust models need to mature to recognise that. An important piece of work is being done by the Web Security Context Working Group, who are looking not just at abstract security models for boffins, but at what ordinary users and ordinary developers know and understand - because those are the people who the security models need to help and protect. Building extremely powerful applications is only a part of the puzzle - for years we have enabled access to special functions on the platform. The other part of the puzzle is identifying the security risks, and describing them in a way that clarifies what implementations should note, without simply having the Web hamstrung by barriers imposed because we didn't bother to find ways to improve security.

And not just for device independence, although it is important in that context; I really think there has to be more focus at W3C on the tools people use to develop content. We can't (and shouldn't) develop those tools in Working Groups, but we really desperately need to make sure that the people who do develop those tools are turning up, involved, and are developing their tools along the lines of the standards as they emerge. One reason why anyone can make a browser, but making a good browser is so very difficult, is that we have to handle the things that tools produce, and that hand-authors who only learn by copy-paste-tweak produce. In the long run, this does not help standardisation, so we need to have the tool producers there are the start of the process.

With the profusion of low-cost devices, chiefly phones and the wave of OLPC-inspired cheap laptops, and with the increasing use of the Web in cars, in industrial machinery, and in other specialist devices, this is more important than ever to get right.

Q. Do you plan to make HTML input-mode available to mobile users, and if so, when?

A. We have the code to enable it in the core, so we can ship it in deliveries if anyone asks for it. But it's a pretty vague specification, so enabling it by default especially in desktop is likely to cause as many problems as it solves.

Q. What do you see as the biggest challenges today in enabling accessible Web browsing on mobile platforms with Opera?

A. If you mean accessible in the W3C sense of "to people with disabilities", the fragmentation in devices, platforms, and assistive technologies. Building a real cross-browser platform means that we need to have our own layer for UI, and then hook that to the platform we ship to. On some platforms this is just a matter of work, but on others it really involves dealing with a mish-mash of half-solutions coming from all over the place.

Effectively, this is going to take time - as I mentioned, our compatibility with accessibility tools is a work in progress - in some areas such as problems faced by people with limited vision we have had plenty of accessibility for ages, but in others, like for people with no vision there is still a lot of work to do.

If on the other hand you just mean the broad English-language sense of the term, then most of the challenge is in distribution, which comes down to the question of price of access and use, compared to the benefits available. Which means we have to build a great application platform, support it with things like our debugging tools and our widget SDK, get an ecosystem of great applications and use cases in place, let users know that it is there, and have users decide that the cost of the service is repaid by the value it gives them - something that I think is happening already (why else would Opera mini be growing at about 10% *per month*?).

Q. There are signs that both browser makers and authors are rediscovering the benefits of embedded data. Does Opera have plans to support microformats (e.g., display hatom and hcalendar with the RSS reader, or hcard with the address book), RDFa, or XMP?

A. Yes. :) (You'll have to stay tuned for more).

Q. Opera has support the application/xhtml+xml media type since version (ages ago). What challenges did you face in implementing it? Did you have a specific strategy for doing so?

A. It's XML...

Seriously, it is not very hard. There are a couple of strange issues that come up because it is not quite compatible with HTML, and people expect it to be so (for example, scripting is not exactly the same, and namespaces in XML are easier to work with than in HTML where they generally cause problems) but nothing that really makes it difficult to do.

Like everything that distinguishes a good standards-compliant browser from a great standards-compliant and also useful browser, we have various strategies for dealing with the Web as it is, as well as the Web as we would like it to be.

Q. Opera 9.5 includes integrated support for torrents, irc, usenet, rss and atom, in addition to HTML, CSS, and other formats. How do you choose which features to include natively and which would best remain independent applications (that evolve independently)?

A. It is important to us that a new release doesn't mean that some critical application breaks. If we decide that something is important enough to be a core feature, rather than an experimental add-on, we feel it is important enough to ensure that it develops alongside the browser.

Q. Scripts can be useful or malicious. Does Opera 9.5 allow users to distinguish between (and control the execution of) scripts from trusted sources (e.g., extensions written in javascript) from those found in pages on the wild Web? Would that be useful?

A. Javascript extensions (userJS - which is basically the same thing as greasemonkey have certain privileges that scripts in the wild don't have. The same goes for scripts in Widgets. The same goes for browser.js - compatibility scripts that Opera produces and periodically ships to the browser in order to solve problems with major websites from time to time - a sort of limited live-update that applies to a few specific sites that have especially unpleasant coding problems in them.

A useful model of trust has to be one that makes clear sense to users. Widgets on widgets.opera.com are code-checked before being posted, because we think it is important for us to be trustworthy. browser.js is shipped totally unobscured so that users can read it for themselves - an easy way to develop trust is how what you're doing, although in practice it only applies to stuff that people can readily get their head around.

So it would be good to have a more powerful, and more comprehensible model of trust on the Web - not just for scripts but for applications in general. It's no good building a layer of the technology stack that is perfectly secure if that just turns out to be a transport layer for all kinds of malware that people accept because they trusted the system. Work such as AC4CSR, or the file I/O proposal and its friends in the Web Apps space, are trying to open specific areas to enhance what can be done on the web. But we really need to think through the whole security and trust architecture better, I think and this is something that takes a fair bit of time.

Q. Based on the Opera 9.5 experience, are there any particular issues that you would like W3C to address as a priority?

A. I think that understanding the security space is important. I would love to see some more direct focus on multimedia and getting some resources behind those who are building patent-free alternatives to what is currently available. I think W3C needs to focus more effort and attention on the tools that are used to create Web content, and ensuring that it is feasible to build authoring tools so people don't need to become experts in SVG and HTML and scripting in order to share their expertise in water-pump installation or Mayan history using proper web standards. Too often I hear this mentioned at the beginning of some work area, and a few years later people are still saying "yes, we really should think about authoring tools, too" without doing anything about them. Although it is important that Web standards can be hand-authored ("view source" is important to tool developers as well as copy-and-hack early adopters), it is critical that people can create content without having to hand-author it.

Ensuring that technology really works on mobiles, and other devices, and the related technology work in accessibility is critical to the future of the Web, and while it isn't something we solve in a week it is something that needs to be front and center so that we don't turn around in a few years and discover we have to spend a few years re-doing our work because we forgot to focus where it matters.

Q. The W3C standards process seeks to balance speed and fairness. Building consensus takes times. Building software also takes time. Any suggestions for how to speed those processes up while promoting participation and maintaining fairness?

A. W3C has been moving towards a more open model, and almost of necessity this slows down the work, as more people need to understand and digest what is happening as it occurs rather than being presented with a fait accompli.

Providing more support for translation of Working Drafts would be helpful - this speeds input and adoption from non-English-speaking communities, which also ensures a better specification. Perhaps the incentives for translating a new Working Draft should be raised compared to translating some short test case or simple tutorial article. (It is pretty apparent that one key consideration for doing this is based on SEO, so increasing the SEO rewards for doing more useful work seems like a simple thing to help).

Promoting implementation across the toolchain - from browsers to authoring tools and tutorials - and promoting the development of interoperable but different systems over the idea of a single implementation are important to improving spec quality and the speed of development.

Q. On a similar note: do you think it would speed up the standards process if, within a given Working Group, participating Members were to prioritize and agree to implement a list of features? Or do the different priorities of the participants (and their customers) make that unlikely?

A. If Members agree to a prioritisation of implementation, and follow through, of course it speeds up work significantly. Element Traversal is an example of a perfectly simple spec, readily implementable and with several interoperable versions shipping on totally distinct codebases, that was held up some months because someone thought that it might be interesting to implement something new instead of what everyone did, and then specifying the new piece. It turns out there is no real problem with shipping the old spec and then making a new one to cover the extended functionality, which we also expect people to implement, so we expect to have the first spec finished with probably four complete implementations very soon, and the extra functionality specified and implemented relatively soon after.

On the other hand, it is possible to waste a huge amount of time trying to get agreement where there simply is none.

Q. What innovations (in particular, related to standards support) should we expect from Opera in the next major release of the browser?

A. Some things are predictable: further improvements to the accessibility support, more HTML 5 and SVG and CSS and MathML and better integration, and so on. And there are various things we have previewed at labs.opera.com that will come to release, like audio and video, Acid 3 compliance, selectors API, improved webfonts, filesystem access, and so on.

But expect the unexpected! We're working on some cool stuff that we will start to launch pretty soon. We're working to build a fantastic cross-platform standards-based application environment, and there are many things that would be good to put into that space. We'll come up with some new toys, and it might pay to watch labs.opera.com for an idea of what we are working on before we make a major release.

Many thanks to Charles for his answers.

What Benevolent Dictator? [W3C Team]

2008-07-11T04:05:44+00:00

From time to time I hear people refer to Tim Berners-Lee as a "benevolent dictator." In most cases they utter the phrase through a smile, but I find the phrase distasteful. It is also inaccurate.

The W3C process has evolved to reduce the central role of the Director. Without this evolution, W3C would not have been able to reach its current work capacity. Steve Bratt (the CEO) has taken on much of the management of the process. For Web architecture issues, the Technical Architecture Group (TAG) was chartered in 2001 to document principles of Web architecture and help resolve issues about Web architecture inside and outside W3C. A full-time staff of around 70 people help support the Director and CEO. The reality is that W3C has intentionally distributed decision-making responsibility to a number of parties in order to grow.

Most importantly, most technical decision-making happens in the groups themselves. W3C operates as a decentralized community of collaborating groups. They function independently, but not in a vacuum. In a presentation to the W3C Advisory Committee in April of this year, Tim wrote: "Each group, whether or not in W3C, has a duty to act as a responsible peer to other groups, recognize it is part of a larger community, and to spawn independent subgroups to do cleanly defined parts of the work when the task is big." By coordinating, groups benefit through reviews of specifications, shared understanding with other communities, and useful architectural consistency.

What role does the Director have regarding group decisions? According to the process document, "[t]he Director is the lead technical architect at W3C and as such, is responsible for assessing consensus within W3C for architectural choices, publication of technical reports, and new Activities." When there is disagreement over a group decision, the Director and CEO assess whether the group has duly considered the minority views and whether the technical reasoning behind the decision is sound. In short: has the group done its job? When presented with a Formal Objection, the Director makes an informed decision, siding at times with the majority, and at other times with the dissenter.

Members not satisfied with a Director decision can appeal it. It only takes 5% of the Membership to overrule Tim, hardly a dictatorship.

Once Upon A Time, Web Standards Curriculum [W3C Team]

2008-07-10T05:04:30+00:00

Once upon a time, we started the Quality Assurance activity at W3C in 2001, one of the objectives was to find a way to improve the materials for communicating with Web developers. In the QA group, Snorre M. Grimsby (Opera) told me that we might find resources for producing educational materials. The discussion became quiet for a while and restarted in June 2006 with David Storey (Opera). As the same time, some people at WASP started a survey for defining requirements for a Web Standards Curriculum.

Finally in March 2008, David introduced me Chris Mills (Opera) and I had the chance to read and send comments on earlier drafts of the Web Standards Curriculum. It has been now released and it's a wonderful piece of work. I will give it a full read and review in the next month and suggest things to Chris Mills.

Now how can you help? Read it, use it in your Web agency, in your classroom, among your Web developers friends. Note what people misunderstood, suggest techniques to Chris Mills to improve his materials. Publish it on your blog, talk about it. Let it grow in the community. It's a cool work which comes from a long story and really it is beautiful story.

Thanks to Chris Mills and Opera. They did it.

Getting closer to a standard for client-side cross-site requests [W3C Team]

2008-07-10T01:01:26+00:00

Good news today from Sunava Dutta of Microsoft's Internet Explorer team in regard to the W3C Access Control for Cross-Site Requests specification: Sunava writes that, as early as IE8 Beta 2,

IE8 will ship the updated section of Access Control that enables public data aggregation (no creds on wildcard) while setting us up on a trajectory to support more in the future (post IE8) using the API flag in an XDR level 2.

That's contingent on getting some understanding that "this area of the spec (public data) will not change significantly unless there are new security concerns."

That means we are now one (big) step closer to ultimately having cross-browser support for Web developers who want to write Web applications for that "public data" use-case of the Access-Control mechanism.

Sunava's announcement is one of several positive outcomes from a three-day face-to-face meeting that the Web Applications Working Group had at the Microsoft offices last week.

So, much thanks to Sunava and to others on the Internet Explorer team for the work they've been doing to help bring us closer to getting this collaboratively developed open standard for client-side cross-site requests out to the widest number of Web developers and end users possible.