W3C TAG Lines tag:www.w3.org,2009:/QA//1 2009-11-20T14:06:32Z Movable Type 4.261 Default Prefix Declaration tag:www.w3.org,2009:/QA//1.8659 2009-11-18T14:23:07Z 2009-11-20T14:06:32Z In this posting, my intention is to provide a concise statement of an idea which is neither particularly new nor particularly mine, but which needs a place that can be referenced in the context of the current debate about distributed extensibility and HTML5. It's a very simple proposal to provide an out-of-band, defaultable, document-scoped means to declare namespace prefix bindings. Henry S. Thompson Default Prefix Declaration

Default Prefix Declaration

Henry S. Thompson
18 Nov 2009

Table of Contents

1. Disclaimer

The ideas behind the proposal presented here are neither particularly new nor particularly mine. I've made the effort to write this down so anyone wishing to refer to ideas in this space can say "Something along the lines of [this posting]" rather than "Something, you know, like, uhm, what we talked about, prefix binding, media-type-based defaulting, that stuff".

2. Introduction

Criticism of XML namespaces as an appropriate mechanism for enabling distributed extensibility for the Web typically targets two issues:

  1. Syntactic complexity
  2. API complexity

Of these, the first is arguably the more significant, because the number of authors exceeds the number of developers by a large margin. Accordingly, this proposal attempts to address the first problem, by providing a defaulting mechanism for namespace prefix bindings which covers the 99% case.

3. The proposal

Binding
Define a trivial XML language which provides a means to associate prefixes with namespace names (URIs);
Invoking from HTML
Define a link relation dpd for use in the (X)HTML header;
Invoking from XML
Define a processing instruction xml-dpd and/or an attribute xml:dpd for use at the top of XML documents;
Defaulting by Media Type
Implement a registry which maps from media types to a published dpd file;
Semantics
Define a precedence, which operates on a per-prefix basis, namely xmlns: >> explicit invocation >> application built-in default >> media-type-based default, and a semantics in terms of namespace information items or appropriate data-model equivalent on the document element.

4. Why prefixes?

XML namespaces provide two essentially distinct mechanisms for 'owning' names, that is, preventing what would otherwise be a name collision by associating names in some way with some additional distinguishing characteristic:

  1. By prefixing the name, and binding the prefix to a particular URI;
  2. By declaring that within a particular subtree, unprefixed names are associated with a particular URI.

In XML namespaces as they stand today, the association with a URI is done via a namespace declaration which takes the form of an attribute, and whose impact is scoped to the subtree rooted at the owner element of that attribute.

Liam Quin has proposed an additional, out-of-band and defaultable, approach to the association for unprefixed names, using patterns to identify the subtrees where particular URIs apply. I've borrowed some of his ideas about how to connect documents to prefix binding definitions.

The approach presented here is similar-but-different, in that its primary goal is to enable out-of-band and defaultable associations of namespaces to names with prefixes, with whole-document scope. The advantages of focussing on prefixed names in this way are:

  • Ad-hoc extensibility mechanisms typically use prefixes. The HTML5 specification already has at least two of these: aria- and data-;
  • Prefixed names are more robust in the face of arbitrary cut-and-paste operations;
  • Authors are used to them: For example XSLT stylesheets and W3C XML Schema documents almost always use explicit prefixes extensively;
  • Prefix binding information can be very simple: just a set of pairs of prefix and URI.

Provision is also made for optionally specifying a binding for the default namespace at the document element, primarily for the media type registry case, where it makes sense to associate a primary namespace with a media type.

5. Example

If this proposal were adopted, and a dpd document for use in HTML 4.01 or XHTML1:

<dpd ns="http://www.w3.org/1999/xhtml">
 <pd p="xf" ns="http://www.w3.org/2002/xforms"/>
 <pd p="svg" ns="http://www.w3.org/2000/svg"/>
 <pd p="ml" ns="http://www.w3.org/1998/Math/MathML"/>
</dpd>

was registered against the text/html media type, the following would result in a DOM with html and body elements in the XHTML namespace and an input element in the XForms namespace: 

<html>
 <body>
  <xf:input ref="xyzzy">...</xf:input>
 </body>
</html>
]]> TAG Status Report: July, 2009 tag:www.w3.org,2009:/QA//1.6455 2009-07-31T14:55:13Z 2009-07-31T14:57:55Z The latest status report to the W3C membership from the TAG is available at http://www.w3.org/2001/tag/2009/sum07. Noah... Noah Mendelsohn TAG is available at http://www.w3.org/2001/tag/2009/sum07. Noah]]> Orthogonality of Specifications tag:www.w3.org,2009:/QA//1.6371 2009-06-24T13:03:36Z 2009-06-24T13:01:35Z HTTP,HTML,URI The general principle of platform design is that platforms consist of a set of standard interfaces. Standard interfaces allow substitution of components across the interface boundary, while independence of interfaces allow evolution of the interfaces themselves. In a PC,... Larry Masinter http://larry.masinter.net

,,

The general principle of platform design is that platforms consist of a set of standard interfaces. Standard interfaces allow substitution of components across the interface boundary, while independence of interfaces allow evolution of the interfaces themselves. In a PC, for example, the disk bus interface allows many different disk vendors to offer disk products independent of the model of display or keyboard, but the orthogonality of interfaces allow evolution of the interfaces themselves. If the display interface were linked to the disk interface too tightly, it wouldn't be possible to evolve ISA to SATA without updating VGA.

In the web platform, the three important interfaces are transport, format and reference, and the current definitions of those interfaces are HTTP, HTML and URI. The interfaces are standard, allowing many different implementations: HTTP standard lets you use HTTP servers from many vendors, the HTML standard lets you use many different HTML authoring tools or template systems, and the URI specification allows identification of many different components.

While HTTP is the current "common denominator"  protocol that all web agents are expected to speak, the web should continue to work if web content is delivered by other protocols -- FTP, shared file systems, email, instant messaging, and so forth.  HTTP as it has evolved has severe difficulties, and designing a Web that only works with HTTP as it is currently implemented and deployed would unfortunate. We should work harder to reduce the dependencies and isolate them.

HTML is the 'lingua franca', the common language that all agents are currently expected to be able to produce, process, read and interpret (or at least a well-defined subset of it). Having a common language is important for interoperability, but  the web should also work for other formats -- extensions to HTML  including scripting, DOM APIs, but also other formats and application environments such as XHTML, Java, PDF, Flash, Silverlight, XForms, 3D objects, SVG, other XML languages and so forth. Certainly HTML has it has evolved is overly complex for the purposes to which it is designed.

The URI is the fundamental element of reference, but the URI itself is evolving to deal with internationalization, reference to session state, IRIs, LEIRIs, HREFs and so forth. Many applications use URIs and IRIs, not just the formats described above but other protocols and locations, including databases, directories, messaging, archiving, peer-to-peer sharing and so forth.

The is just one of many communication applications on the global Internet; for web browsing to integrate will with the rest of the distributed networking, web components should be independent of the application, and work well with messaging, instant messaging,  news feeds, etc etc.

A sign of a breakdown of this architectural principle would be for a specification of a format (say HTML) to attempt to redefine, for its purposes, the protocol (say HTTP) or the method of reference (URI).  The specifications should be independent, or at least, dependencies isolated, minimized, reduced. If those other elements of the web architecture are incorrect, need to evolve to meet current practice or have flaws in their definitions, they need to evolve independently, so that orthogonality of the specifications and reusability of the components are the promoted.

There may well be reasons to link some features of HTML to the fact that it is delivered over an interactive protocol, but linking HTML directly to HTTP in a way that features would work only for HTTP and not for any other protocol with similar features – that would be unfortunate. It might not matter in the short-term (that’s all we have right now) but it is harmful to the long-term evolution of the web.

(Should go without saying, but just in case: this is a personal post, not reviewed by the TAG)

]]> Language semantics and operational meaning tag:www.w3.org,2009:/QA//1.6366 2009-05-19T18:45:18Z 2009-05-19T18:45:39Z W3C and other standards organizations are in the business of defining languages -- conventions that organizations can choose to follow -- and not in mandating operational behavior -- telling organizations and participants in the network how they are supposed... Larry Masinter http://larry.masinter.net W3C and other standards organizations are in the business of defining languages -- conventions that organizations can choose to follow -- and not in mandating operational behavior -- telling organizations and participants in the network how they are supposed to behave. Organizations (implementors, operators, administrators, software developers) are free to choose which standards they adopt, and what their operational behavior will be.

In some posts on the www-tag mailing list, I was trying to point out the risks in defining languages such that the "meaning" of the language depends on operational behavior. In some ways, of course, this is a fallacy: in general, what an utterance "means" in some operational way depends on what the speaker intends and how the listener will interpret the utterance.

However, as an organization, W3C can, and should, define languages in which the meaning is defined in the document, in terms of abstractions rather than in terms of operational behavior. The result is more robust standards, those that have wider applicability, that can be used for more purposes, and that create a more vibrant and extensible web.

]]> Search Engines take on Structured Data tag:www.w3.org,2009:/QA//1.6362 2009-05-13T16:18:42Z 2009-05-14T07:17:04Z Structured data on the web got a boost this week, with Google's announcement of Rich Snippets and Rich Snippets in Custom Search. Structured data at such a large scale raises at least three issues:SyntaxVocabularyPolicyGoogle's documentation shows support for both microformats... Dan Connolly http://www.w3.org/People/Connolly/ Structured data on the web got a boost this week, with Google's announcement of Rich Snippets and Rich Snippets in Custom Search. Structured data at such a large scale raises at least three issues:

  1. Syntax
  2. Vocabulary
  3. Policy

Google's documentation shows support for both microformats and RDFa. It follows the hReview microformat syntax with small vocabulary changes (name vs fn). Support for RDFa syntax, in theory, means support for vocabularies that anyone makes; but in practice, Google is starting with a clean slate: data-vocabulary.org. That's a place to start, though it doesn't provide synergy with anyone who has uses FOAF or Dublin Core or the like to share their data.

The policy questions are perhaps the most difficult. Structured data is a pointy instrument; if anyone can say anything about anything, surely the system will be gamed and defrauded. Google's rollout is one step at a time, starting with some trusted sites and an application process to get your site added. The O'Reilly interview with Guha and Hansson is an interesting look at where they hope to go after this first step; if you're curious about how this fits in to HTML standards, see Sam Ruby's microdata.

While issues remain--there are syntactic i's to dot and t's to cross and even larger policy issues to work out--between Google's rollout and Yahoo's searchmonkey and the UK Central Office of Information rollout, it seems that the industry is ready to take on the challenges of using structured data in search engines.

]]> Data interchange problems come in all sizes tag:www.w3.org,2009:/QA//1.6360 2009-05-08T21:10:44Z 2009-05-08T23:20:52Z I had a pretty small data interchange problem the other day: I just wanted to archive some play lists that I had compiled using various music player daemon (mpd) clients. The mpd server stores playlists as simple m3u files,... Dan Connolly http://www.w3.org/People/Connolly/ I had a pretty small data interchange problem the other day: I just wanted to archive some play lists that I had compiled using various music player daemon (mpd) clients. The mpd server stores playlists as simple m3u files, i.e. line-oriented files with a path to the media file on each line. But that's too fragile for archive and interchange purposes. I had a similar problem a while back with iTunes playlists. In that episode, I chose hAudio, an HTML dialect in progress in the microformats community, as my target.

Unfortunately, hAudio changed out from under me between when I started and when I finished. So this time, a simple search found the music ontology and I tried it with RDFa, which lets you use any RDF vocabulary in HTML*. I'm mostly pleased with the results:

  1. from A Song's Best Friend_ The Very Best Of John Denver [Disc 1]
    by John Denver
    Poems, Prayers And Promises
  2. from WOW Worship (orange)
    by Compilations
    Did you Feel the Mountains Tremble
  3. from Family Music Party
    by Trout Fishing In America
    Back When I Could Fly

The album names come before the track names because I didn't read enough of the the RDFa primer when I was coding; RDFa includes @rev as well as @rel for reversing subject/object order. See an advogato episode on m3uin.py for details about the code.

The Music Ontology was developed by a handful of people who staked out a claim in URI space (http://musicontology.org/...) and happily took comments from as big a review community as they could manage, but they had no obligation to get a really global consensus. The microformats process is intended to reach a global consensus so that staking out a claim in URI space is superfluous; it works well given certain initial conditions about how common the problem is and availability of pre-web designs to draw from. Perhaps playlists (and media syndication, as hAudio seems to be expanding in scope to hMedia) will eventually reach these conditions, but the music ontology already meets my needs, since I'm the sort who doesn't mind declaring my data vocabulary with URIs.

My view of Web architecture is shaped by episodes such as this one. While giga-scale deployment is always impressive and definitely something we should design for, small scale deployment is just as important. The Web spread, initially, not because of global phenomena such as Wikipedia and Facebook but because you didn't need your manager's permission to try it out; you didn't even need a domain name; you could just run it on your LAN or even on just one machine with no server at all.

In an Oct 2008 tech plenary session on web architecture, Henri Sivonen said:

I see the Web as the public Web that people can access. The resources you can navigate publicly. I define Web as the information space accessible to the public via a browser.
If a mobile operator operates behind walls, this is not part of the Web.

I can't say that I agree with that perspective. I'm no great fan of walled gardens either, but freedom means freedom to do things we don't like as well as freedom to do things we do like. And architecture and policy should have a sort of church-and-state separation between them.

Plus, data interchange happens not just at planetary scale, but also within mobile devices, across devices, and across communities and enterprises of all shapes and sizes.

I've gone a little outside the scope of current standards; RDFa has only been specified for use in modular XHTML, with the application/xhtml+xml media type, so far.

See also:

]]> Once more into Versioning -- this time with HTML tag:www.w3.org,2009:/QA//1.6359 2009-05-04T17:39:46Z 2009-05-04T18:57:24Z The W3C TAG has worked on the general issue of "versioning" for many years, and many TAG members may be worn out on the issue. However, undeterred by past history, I'm taking another run at it, this time trying to... Larry Masinter http://larry.masinter.net The W3C TAG has worked on the general issue of "versioning" for many years, and many TAG members may be worn out on the issue. However, undeterred by past history, I'm taking another run at it, this time trying to look specifically at the issues around versioning of HTML, CSS, JavaScript and other parts of the standard web browser landscape. Part of what's new (I think) is looking at the cost/benefits around deployment. See the www-tag mailing list archive for the HTML and versioning threads. Palm webOS approach to HTML extensibility: x-mojo-* tag:www.w3.org,2009:/QA//1.6307 2009-02-16T17:04:52Z 2009-02-26T17:34:22Z I got pretty excited about the iPhone, and even more about the openness of Android and the G1, and then I learn that the Palm Pre developer platform is basically just the open web platform: HTML, CSS, and JavaScript.... Dan Connolly http://www.w3.org/People/Connolly/ I got pretty excited about the iPhone, and even more about the openness of Android and the G1, and then I learn that the Palm Pre developer platform is basically just the open web platform: HTML, CSS, and JavaScript.

Just after the mobile buzz at Web Directions North and the TAG declared victory on how to build The Self-Describing Web with URI-based Extensibility , I get some details on how Palm is building on the open web platform:

A widget is declared within your HTML as an empty div with an x-mojo-element attribute.

<div x-mojo-element="ToggleButton" id="my-toggle"></div>

Oh great; x- tokens... aren't those passe by now?

The suggestion in the HTML 5 draft is data-* attributes. The ARIA draft suggests @role. The Palm design looks like new information for issue-41, Decentralized-extensibility, in the HTML WG.

Anybody know how frozen the Palm design is? Or if they looked at ARIA, data-* or URI-based namespaces?

]]> JavaScript required for basic textual info? TRY AGAIN tag:www.w3.org,2009:/QA//1.6297 2009-01-27T22:01:19Z 2009-01-27T22:18:27Z Sam says he's Online and Airborne. "Needless to say, this is seriously cool." I'll say! But when I follow the link to details from the service provider, I get:Sorry. You must have JavaScript enabled to view this page. Click the... Dan Connolly http://www.w3.org/People/Connolly/ Online and Airborne. "Needless to say, this is seriously cool." I'll say! But when I follow the link to details from the service provider, I get:
Sorry. You must have JavaScript enabled to view this page. Click the BACK button below or enable JavaScript in your browser preferences and click TRY AGAIN.
Let's turn that around, shall we? Sorry, if you're a network provider and you want my business, read up on unobtrusive javascript (aka the rule of least power), go BACK to work on your web site design and TRY AGAIN.
]]> How to evaluate Web Applications security designs? tag:www.w3.org,2008:/QA//1.595 2008-12-03T17:00:00Z 2008-12-04T08:43:15Z I could use some help getting my head around security for Web Applications and mashups. The first time someone told me W3C should be working on specs help the browser prevent sensitive data from leaking out of enterprises, I... Dan Connolly http://www.w3.org/People/Connolly/ I could use some help getting my head around security for Web Applications and mashups.

The first time someone told me W3C should be working on specs help the browser prevent sensitive data from leaking out of enterprises, I didn't get it. "Use the browser as part of the trusted computing base? Are you kidding?" was my response. I didn't see the bigger picture. Crockford explains in an April 2008 item:

... there are multiple interests involved in a web application. We have here the interests of the user, of the site, and of the advertiser. If we have a mashup, there can be many more interests.

Most of my study of security protocols concentrated on whether a request from party A should be granted by party B. You know, Alice and Bob. Using BAN logic to analyze the Kerberos protocols was very interesting.

I also enjoyed studying capability security and the E system, which is a fascinating model of secure multi-party communication (not to mention lockless concurrency), though it seems an impossibly high bar to reach, given the worse-is-better tendency in software deployment, and it seemed to me that capabilities are a poor match for the way linking and access control work in the Web:

The Web provides several mechanisms to control access to resources; these mechanisms do not rely on hiding or suppressing URIs for those resources.

On the other hand, after wrestling with the patchwork of javascript security policies in browsers in the past few weeks, the capability approach in adsafe looks simple and elegant by comparison. Is there any chance we can move the state-of-the-art that far? And what do we do in the mean time? Crockford's Jan 2008 post is quite critical of W3C's current work:

This same sort of wrong-end-of-the-network thinking can be seen today in the HTML 5 working group's crazy XHR access control language.

Access Control for Cross-Site Requests is a mouthful, and "Access Control" is too generic, which leads to "W3C Access Control". Didn't we already go through this with "W3C XML Schema"? Generic names are awkward. I think I'll call it WACL... yeah... rhymes with spackle... let's see if it sticks. Anyway...

Crockford's comment cites his proposal and argues...

JSONRequest does not allow the server to abdicate its responsibility of deciding if the data should be delivered to the browser. Therefore, no policy language is needed. JSONRequest requires explicit authorization. Cookies and other tokens of ambient authority are neither sent nor delivered.

I'm not sure I understand that. I'm glad to learn there's more to the difference between XMLHttpRequest and JSONRequest than just <pointy-brackets> vs {curly-braces}, but I'd like to understand better how "ambient authority" relates to the interests of users, sites, advertisers, and the like.

In response, the FAQ in the WACL spec says:

JSONRequest has been considered by the Web Applications Working Group and the group has concluded that it does not meet the documented requirements. E.g., requests originating from the JSONRequest API cannot include credentials and JSONRequest is format specific.

Including credentials seems more like a solution than a requirement; can someone help me understand how it relates to the multiple interests involved in a web application?

]]> Caching XML data at install time tag:www.w3.org,2008:/QA//1.226 2008-09-04T21:29:28Z 2008-09-05T23:52:09Z The W3C web server is spending most of its time serving DTDs to various bits of XML processing software. While XSLT processors such as xsltproc and Xalan have no technical dependency on the XHTML DTDs, I suspect they're used with XHTML enough that shipping copies of the DTDs along with the XSLT processing software is a win all around. Dan Connolly http://www.w3.org/People/Connolly/ The W3C web server is spending most of its time serving DTDs to various bits of XML processing software. In a follow-up comment on an item on DTD traffic, Gerald says:

To try to help put these numbers into perspective, this blog post is currently #1 on slashdot, #7 on reddit, the top page of del.icio.us/popular , etc; yet www.w3.org is still serving more than 650 times as many DTDs as this blog post, according to a 10-min sample of the logs I just checked.

Evidently there's software out there that makes a lot of use of the DTDs at W3C and they fetch a new copy over the Web for each use. As far as this software is concerned, these DTDs are just data files, much like the timezone database your operating system uses to convert between UTC and local times. The tz database is updated with respect to changes by various jurisdictions from time to time and the latest version is published on the Web, but your operating system doesn't go fetch it over the Web for each use. It uses a cached copy. A copy was included when your operating system was installed and your machine checks for updates once a week or so when it contacts the operating system vendor for security updates and such. So why doesn't XML software do likewise?

It's pretty easy to put together an application out of components in such a way that you don't even realize that it's fetching DTDs all the time. For example, if you use xsltproc like this...

$ xsltproc agendaData.xsl weekly-agenda.html >,out.xml

... you might not even notice that it's fetching the DTD and several related files. But with a tiny HTTP proxy, we can see the traffic. In one window, start the proxy:

$ python TinyHTTPProxy.py 
Any clients will be served...
Serving HTTP on 0.0.0.0 port 8000 ...

And in another, run the same XSLT transformation with a proxy:

$ http_proxy=http://127.0.0.1:8000 xsltproc agendaData.xsl weekly-agenda.html

Now we can see what's going on:

	connect to www.w3.org:80
localhost - - [05/Sep/2008 15:35:00] "GET http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd HTTP/1.0" - -
	connect to www.w3.org:80
localhost - - [05/Sep/2008 15:35:01] "GET http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent HTTP/1.0" - -
	bye
	bye
	connect to www.w3.org:80
localhost - - [05/Sep/2008 15:35:01] "GET http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent HTTP/1.0" - -
	bye
	connect to www.w3.org:80
localhost - - [05/Sep/2008 15:35:01] "GET http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent HTTP/1.0" - -
	bye

This is the default behaviour of xsltproc, but it's not the only choice:

  • You can use xsltproc --novalid tells it to skip DTDs altogether.
  • You can set up an XML catalog as a form of local cache.

To set up this sort of cache, first grab copies of what you need:

$ mkdir xhtml1
$ cd xhtml1/
$ wget http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
--15:29:04--  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
           => `xhtml1-transitional.dtd'
Resolving www.w3.org... 128.30.52.53, 128.30.52.52, 128.30.52.51, ...
Connecting to www.w3.org|128.30.52.53|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 32,111 (31K) [application/xml-dtd]

100%[====================================>] 32,111       170.79K/s             

15:29:04 (170.65 KB/s) - `xhtml1-transitional.dtd' saved [32111/32111]
$ wget http://www.w3.org/TR/xhtml1/DTD/xhtml-lat1.ent
...
$ wget http://www.w3.org/TR/xhtml1/DTD/xhtml-symbol.ent
...
$ wget http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent
...
$ ls
xhtml1-transitional.dtd  xhtml-lat1.ent  xhtml-special.ent  xhtml-symbol.ent

And then in a file such as xhtml-cache.xml, put a little catalog:

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <rewriteURI
      uriStartString="http://www.w3.org/TR/xhtml1/DTD/"
      rewritePrefix="./" />
</catalog>

Then point xsltproc to the catalog file and try it again:

$ export XML_CATALOG_FILES=~/xhtml1/xhtml-cache.xml
$ http_proxy=http://127.0.0.1:8000 xsltproc agendaData.xsl weekly-agenda.html

This time, the proxy won't show any traffic. The data was all accessed from local copies.

While XSLT processors such as xsltproc and Xalan have no technical dependency on the XHTML DTDs, I suspect they're used with XHTML enough that shipping copies of the DTDs along with the XSLT processing software is a win all around. Or perhaps the traffic comes from the use of XSLT processors embedded in applications, and the DTDs should be shipped with those applications. Or perhaps shipping the DTDs with underlying operating systems makes more sense. I'd have to study the traffic patterns more to be sure.

p.s. I'd rather not deal with DTDs at all; newer schema technologies make them obsolete as far as I'm concerned. But

  • some systems were designed before better schema technology came along, and W3C's commitment to persistence applies to those systems as well, and
  • the point I'm making here isn't specific to DTDs; catalogs work for all sorts of XML data, and the general principle of caching at install time goes beyond XML altogether.
]]> The details of data in documents: GRDDL, profiles, and HTML5 tag:www.w3.org,2008:/QA//1.220 2008-08-22T19:45:48Z 2008-08-22T19:58:16Z GRDDL, a mechanism for putting RDF data in XML/XHTML documents, is specified mostly at the XPath data model level. Some GRDDL software goes beyond XML and supports HTML as she are spoke, aka tag soup. HTML 5 is intended to... Dan Connolly http://www.w3.org/People/Connolly/ HTML as she are spoke, aka tag soup. HTML 5 is intended to standardize the connection between tag soup and XPath. The tidy use case for GRDDL anticipates that using HTML 5 concrete syntax rather than XHTML 1.x concrete syntax involves no changes at the XPath level.

But in GRDDL and HTML5, Ian Hickson, editor of HTML 5, advocates dropping the profile attribute of the HTML head element in favor of rel="profile" or some such. I dropped by the #microformats channel to think out loud about this stuff, and Tantek said similarly, "we may solve this with rel="profile" anyway." The rel-profile topic in the microformats wiki shows the idea goes pretty far back.

Possibilities I see include:
  • GRDDL implementations add support for rel="profile" along with HTML 5 concrete syntax.
  • GRDDL implementors don't change their code, so people who want to use GRDDL with HTML 5 features such as <video> stick to XML-wf-happy HTML 5 syntax and they use the head/@profile attribute anyway, despite what the HTML 5 spec says.
  • People who want to use GRDDL stick to XHTML 1.x.
  • People who want to put data in their HTML documents use RDFa.

I don't particularly care for the rel="profile" design, but one should choose ones battles and I'm not inclined to choose this one. I'm content for the market to choose.

]]> life without MIME type sniffing? tag:www.w3.org,2008:/QA//1.205 2008-07-07T17:19:21Z 2008-07-07T19:22:02Z In a recent item on IE8 Security, Eric Lawrence, Security Program Manager for Internet Explorer, introduced a work-around to the security risks associated with content-type sniffing: an authoritative=true parameter on the Content-Type header in HTTP. This re-started discussion of... Dan Connolly http://www.w3.org/People/Connolly/ In a recent item on IE8 Security, Eric Lawrence, Security Program Manager for Internet Explorer, introduced a work-around to the security risks associated with content-type sniffing: an authoritative=true parameter on the Content-Type header in HTTP. This re-started discussion of the content-type sniffing rules and the Support Existing Content design principle of HTML 5. In response to a challenge asking for evidence that supporting existing content requires sniffing, Adam made a suggestion that I'd like to pass along:

I encourage you to build a copy of Firefox without content sniffing and try surfing the web. I tried this for a while, and I remember there being a lot of broken sites ...

That reminded me of an idea I heard in TAG discussions of MIME types and error recovery: a browser mode for "This is my content, show me problems rather than fixing them for me silently."

Though Adam offered a patch, building firefox is not something I have mastered yet, so I'm interested to learn about run-time configuration options in IE (notes Julian) and Opera (notes Michael). Eric Lawrence's reply points out:

Please do keep in mind, however, that most folks (even the ultra-web engaged on these lists) see but a small fraction of the web, especially considering private address space/intranets, etc.

A report from one developer suggests there's light at the end of the tunnel, at least for sniffing associated with feeds:

I did, partly as an experiment, stop sniffing text/plain in the latest release of SimplePie (which, inevitably, isn't the nicest of things to do, seeming there are tens of thousands of users). Next to nothing broke. I know for a fact this couldn't have been done a year or two ago: things have certainly moved on in terms of the MIME types feeds are served with ...

If you get a chance to try life without MIME type sniffing, please let us know how it goes.

]]> Syntax for ARIA: Cost-benefit analysis tag:www.w3.org,2008:/QA//1.177 2008-05-07T16:15:25Z 2008-05-12T10:55:57Z The ARIA spec. defines roles, states and properties to manage the interface between rich web documents and assistive technologies. The primary expression of roles, states and properties in markup languages is via attributes. ARIA has to specify how its vocabulary of attributes and values can be integrated into both existing and future languages. This analysis assesses alternative approaches to ARIA syntax. Henry S. Thompson

Syntax for ARIA: Cost-benefit analysis

Henry S. Thompson
7 May 2008

Table of Contents

1. Introduction

This analysis is intended to be neutral with respect to ideology, history and constituency. For a useful overview of how we got here, see WAI-ARIA Implementation Concerns (member-only link) by Michael Cooper.

The W3C's WAI PF Working Group recently published the first public working draft of the Accessible Rich Internet Applications (WAI-ARIA) specification, which "describes mappings of user interface controls and navigation to accessibility APIs".

The ARIA spec. defines roles, states and properties to manage the interface between rich web documents and assistive technologies. The primary expression of roles, states and properties in markup languages is via attributes. Since ARIA is meant to augment web applications across a range of languages and user agents, ARIA has to specify how its vocabulary of attributes and values can be integrated into both existing and future languages.

In preparing this analysis, I have reviewed the available concrete evidence bearing on the matter, and have carried out a considerable amount of work to replicate and, in some cases, correct or extend, testing which has been done in the past. The details are available in a report entitled Some test results concerning ARIA attribute syntax.

2. The core issue: How should the ARIA attributes be spelled?

ARIA is useful only if it is widely supported. It therefore needs to integrate cleanly into existing and future languages as easily as possible. Before looking at possible answers to the spelling question, we need to consider exactly what supporting ARIA means.

We can distinguish two levels of support for ARIA on the part of user agents, which I'll call 'passive' and 'active' support. By passive support, I mean that documents with ARIA-conformant markup are not rejected by the agent, and the markup is available in the same way any other markup is, e.g. via a DOM API or for matching by CSS selectors. By 'active' support I mean the user agents actually implement their part of ARIA semantics, that is, reflecting changes to ARIA-defined states and properties via accessibility APIs.

Although already deployed implementations cannot offer active support, an optimal answer to the spelling question would maximise passive support from existing languages, as well as encouraging active support from subsequent implementations.

3. Possible approaches: land-grab, colon or dash

There are in principle three possible approachs to the spelling question:

  • land-grab  Just use 'role' and the names of the properties (e.g. 'checked', 'hidden') as attribute names.
  • colon  Use 'aria:' as a distinguishing prefix, giving e.g. 'aria:role', 'aria:checked' as attribute names.
  • dash  Use 'aria' plus some other punctuation character, e.g. dash, as a distinguishing prefix, giving e.g. 'aria-role', 'aria-checked' as attribute names.

The land-grab approach is pretty clearly unacceptable, because of clashes with existing vocabularies and the likelihood of clashes with future ones, and will not be considered further.

The current ARIA WD specifies a combination of the colon and dash approachs, with the colon being specified for use with XML-based languages, with the necessary additional requirement that 'aria' is bound to the ARIA namespace in the usual way, i.e. xmlns:aria="http://www.w3.org/2005/07/aaa", and the dash approach being specified for use with non-XML languages. We'll call this the mixed approach hereafter.

My understanding is that as of the date of this note, the WAI PF working group have indicated that their intention is that the next draft of the ARIA specs will move to the dash appropach.

4. The status quo: languages and implementations

Choosing an approach is made complicated by the landscape of language and infrastructure standards it has to fit in to, and by the fact that these are moving targets. We therefor have to distinguish between what is currently in place, what we have reason to expect in the near future, and what we can foresee in the longer term. Furthermore, for existing languages we have two categories: XML-based languages, with more or less explict provision for extensibility in general, typically namespace-based, and non-XML languages, which for the purposes of this analysis we will take to be HTML 4.01 and nothing else.

As noted above, the best we can expect from deployed user agents is passive support. The table below sets out the extent of passive support which is available for the colon and dash approaches for each of three host languages, which exemplify the major relevant categories: HTML 4.01 (for the non-XML languages), XHTML (an XML language, but not always treated as such, so we actually get two columns for it below) and SVG (only an XML language).

Passive
support		 HTML 4.01 XHTML
(as if HTML)0		 XHTML
(as XML)		 SVG
Allowed
at all		 colon: Yes, by 'should ignore' advice
dash: Yes, by 'should ignore' advice 		colon: Yes, by 'should ignore' advice
dash: Yes, by 'should ignore' advice 		colon: Yes, by 'must ignore' rule
dash: Yes, by 'must ignore' rule		 colon: Yes, by 'must ignore' rule
dash: In principle,no
in practice1, yes
Available
via DOM		 colon: Yes, via GetAttribute
dash: Yes, via GetAttribute		 colon: Yes, via GetAttribute
dash: Yes, via GetAttribute		 colon: Yes2, via GetAttributeNS and GetAttribute
dash: Yes2, via GetAttribute		 colon: Yes3, via GetAttributeNS and GetAttribute
dash: Yes3, via GetAttribute
Matches
CSS selector		 colon: Yes4, using [aria\:attr]
dash: Yes5		 colon: Yes4, using [aria\:attr]
dash: Yes5		 colon: Yes, using [aria|attr]
dash: Yes5		 colon: No
dash: No

Notes:

  • 0  This column applies to the IE family, and to other browsers whenever treating XHTML as HTML
  • 1  Firefox 2.0.0.14, IE7 + Adobe 3.03 SVG plugin
  • 2  All browsers which treat XHTML as XML
  • 3  Firefox 2.0.0.14 (unable to test IE+plugin so far)
  • 4  Except IE family
  • 5  If attribute selectors supported at all, i.e. not IE5, IE6

It should be noted that some of the entries above disagree with assertions made in the past about browser behaviour. At least some of those assertions were based on flawed test materials---see the discussion of experiments 1 and 2 in my testing report for details on the information summarised above.

5. The near future

A number of browser implementors have responded positively to the ARIA initiative and have included experimental active support for ARIA in pre-release versions of their products. Most of the test materials and implementation information I can find suggests that only the dash approach, and only HTML or XHTML, are currently being implemented.

With regard to improving passive support, it seems very possible that IE8 will support attribute selectors of the form [aaa\:checked], which would remove the qualification recorded in the table above by footnote 4.

5.1. HTML5

The situation with respect to HTML5 is complicated. As it currently stands, the HTML5 draft specification supports namespaces internally, and all HTML elements are parsed into the DOM nodes in the HTML namespace, regardless of whether they are parsed "as HTML" or "as XML". But when parsing documents "as HTML", no other namespaces are recognised. Unless this changes before HTML5 is completed, the HTML/"XHTML (as if HTML)" columns above will apply to HTML5-conformant user agents in at least some cases.

6. Cost-benefit analysis

On the basis of the above survey, there follows below an attempt at a cost-benefit analysis with respect to the colon and dash approaches, as well as the mixed approach as currently specced in the ARIA working draft and a fourth approach, as proposed by me in a message to www-tag, which I'll call the xcolon approach. The xcolon approach attempts to address some of the problems revealed in the passive support table by defining a pair of getter/setter Javascript functions for access to ARIA information in the DOM, and giving a design pattern for duplicated CSS selectors (one using [aria\:xxx] and the other [aria|xxx]).

Benefits Costs
colon Consistency for page authors; Uniform DOM access (using Get/SetAttribute); Orthogonal in XML languages; consistent with namespace-based extensibility for XML (and for HTML5?1) Uniform DOM access ignores namespace2; no uniform CSS selector; no CSS selector at all for IE legacy3; modest re-implementation cost4
dash Consistency for page authors; uniform DOM access; uniform CSS selector Inconsistent with XML namespace-based extensibility5; new paradigm for 'namespace'6; scope creep7
mixed Orthogonal in XML languages; consistent with namespace-based extensibility for XML (and for HTML5?1) Confusing for authors; no uniform DOM access; no uniform CSS selector; uncertainty wrt XHTML; new paradigm for 'namespace'6; scope creep7
xcolon Consistency for page authors; orthogonal for XML languages; consistent with namespace-based extensibility for XML (and for HTML5?1); uniform DOM access; uniform CSS selector Requires indirection through accessor functions for DOM access; requires duplicate CSS selectors; no uniform DOM representation; no CSS selector at all for IE legacy3; modest re-implementation cost4
  • 1  HTML5's provision for extensibility, whether compatible with XML namespaces or not, is an open area of discussion at the moment.
  • 2  That is, it requires the use of a fixed aria prefix and may not (i.e. in some browsers) correctly set the namespaceURI property even when targetting an XML DOM.
  • 3  That is, in the IE family, only (putatively) IE8 and successors will recognize [aria\:...] selectors
  • 4  See discussion of re-implementation cost below
  • 5  See discussion of XML extensibility below
  • 6  That is, adds the concept of a fixed, dash-delimited, prefix as a way of managing distinct symbol spaces to the existing non-fixed, colon-delimited prefix for the same purpose.
  • 7  That is, requires all embedding languages to explicitly allow and manage an inventory of fixed prefixes and, possibly, their vocabularies.

6.1. Implementation cost

For wholly commendable reasons, development of the ARIA spec. and pilot implementation work have proceeded in parallel. Most if not all existing implementations support only the dash approach. What is the likely cost for those implementations of any decision to adopt any other approach? My conclusion, having examined one implementation in some detail, is that the cost is likely to be very modest.

Michael Cooper, WAI PF staff contact, captured the reason for this very well, albeit unintentionally:

"The ARIA roles and properties are conceptually simple enough, but they are designed to provide a bridge between HTML and desktop accessibility APIs, a bridge which is exploited by the operating system, user agent, and assistive technology all working together. There's a complex set of interdependencies there and the feasibility and details of many of the ARIA features could only be worked out by testing in deployed systems, and therefore doing early implementation."

The complexity referred to above is fundamentally one of architecture, both static and dynamic. Not surprisingly, therefore, syntactic concerns account for a tiny fraction of the code needed to implement ARIA as it stands. Furthermore, and again not surprisingly, as it's what sound software engineering practice requires, the details of the concrete syntax are isolated, and the vast bulk of the code I looked at refers to it only indirectly. The consequence of all this is that the changes necessary to manage any change away from the dash approach will be very straightforward. For more details, see the discussion of experiment 3 in my testing report.

6.2. XML extensibility and SVG

Many existing XML languages make explicit, generic, provision for extensibility by including in their formal schemas and/or spec. prose allowance for any namespace-qualified elements and attributes from namespaces other than those which make up the language itself. Tools such as NVDL and, to a lesser extent, W3C XML Schema and RelaxNG, make it possible to combine the schemas for multiple XML languages to give a complete characterisation of mixed-language documents.

One particularly important example of this approach is SVG. ARIA integration into SVG is clean and straightforward under the colon or mixed approaches, but will require amending the spec. under the dash approach.

6.3. Short- vs. long-range considerations

In trying to weigh the tradeoffs which must of necessity be considered when confronted by the information given above, the matter of timescale is particular hard to address. Any assertion about how things will look five, or even two, years hence can always be countered with a contrary assertion. None-the-less, the centrality of the HTML languages for the Web, and the fundamental importance of accessibility for all of us, suggest that we must take the long-term impact of this decision seriously, and be prepared to discount some short-term discomfort in return for long-term stability and simplicity.

]]> Proposed Activity for Video on the Web tag:www.w3.org,2008:/QA//1.167 2008-04-15T15:29:20Z 2008-05-09T01:01:16Z W3C organized a workshop on Video on the Web in December 2007 in order to share current experiences and examine the technologies (see report) and is now following up with a proposal for a Video on the Web activity. Philippe Le Hégaret http://www.w3.org/People/LeHegaret/ W3C organized a workshop on Video on the Web in December 2007 in order to share current experiences and examine the technologies (see report). Online video content and demand is increasing rapidly, becoming omnipresent on the Web and the trend will continue for at least a few years. These rapid changes are posing challenges to the underlying technologies and standards that support the platform-independent creation, authoring, encoding/decoding, and description of video. To ensure the success of video as a "first class citizen" of the Web, the community needs to build a solid architectural foundation that enables people to create, navigate, search, and distribute video, and to manage digital rights.

The general scope of the proposed Video on the Web activity is to provide cohesion in the video related activities of W3C, as well helping other W3C Groups in their effort to provide video functionalities. In addition, this activity will focus at implementing the next steps from the W3C workshop on Video on the Web. The proposal is to create 3 new Working Groups around Video on the Web. Please, have a look at the following documents:

  1. Activity proposal
  2. Media Fragments Working Group Charter
  3. Media Best Practices and Guidelines Working Group Charter
  4. Media Annotations Working Group Charter

We welcome general feedback, general expressions of interest (or lack of!) and comments on the discussion list public-video-comments@w3.org.

If you should have questions or need further information, please feel free to contact me as well. I will be presenting the activity proposal during the Web Conference next week, on Thursday afternoon.

]]> Simple things make firm foundations tag:www.w3.org,2008:/QA//1.139 2008-01-18T15:39:46Z 2008-01-18T15:53:34Z You can look at the development of web technology in many ways, but one way is as a major software project. In software projects, the independence of specs, has always been really important, I have felt. A classic example is... Tim Berners-Lee http://www.w3.org/People/Berners-Lee/ You can look at the development of web technology in many ways, but one way is as a major software project. In software projects, the independence of specs, has always been really important, I have felt. A classic example is the independence of the HTTP and HTML specifications: you can introduce many forms of new markup language to the web through the MIME Content-Type system, without changing HTTP at all.

The modularity of HTML itself has been discussed recently, for example by Ian Hickson, co-Editor of HTML5:

Note that it really isn't that easy. For example, the HTML parsing rules are deeply integrated with the handling of <script> elements, due to document.write(), and also are deeply integrated with the definition of innerHTML. Scripting, in turn, is deeply related to the concept of scripting contexts, which depends directly on the definition of the Window object and browsing contexts, which, in turn, are deeply linked with session history and the History object (which depends on the Location object) and with arbitrary browsing context navigation (which is related to hyperlinks and image maps) and its related algorithms (namely content sniffing and encoding detection, which, to complete the circle, is part of the HTML parsing algorithm). - Brainstorming test cases, issues and goals, etc., Ian Hickson

and in reply by Laurens Holst:

I don't know the spec well enough to answer that question, but I'd say modularization (if I may call it so) would make it both easier to grasp as individual chunks, for both the reviewing process and the implementing process. brainstorming: test cases, issues, goals, etc.. - Laurens Holst

The <canvas> element introduces a complex 2D drawing API different in nature from the other interfaces, which concentrate on setting and retrieving values in the markup itself; the client-side database storage section of the specification is another such interface. While the <canvas> element has a place in the specification, the drawing API should be defined in a separate document. Hixie expressed a similar sentiment (and see the group's issues about scope):

The actual 2D graphics context APIs probably should be split out on the long term, like many other parts of the spec. On the short term, if anyone actually is willing to edit this as a separate spec, there are much higher priority items that need splitting out and editing...

It would also be nice if the <canvas> element and the SVG elements which embed in HTML did so in just the same way, in terms of the context (style, etc.) which is passed (or not passed) across the interface, in terms of the things an implementer has to learn about, and things which users have to learn about. So that <canvas> and SVG can be perhaps extended to include say 3D virtual reality later, and so that all of these can be plugged into other languages just as they are plugged into HTML.

There are lots of reasons for modularity. The basic one is that one module can evolve or be replaced without affecting the others. If the interfaces are clean, and there are no side effects, then a developer can redesign a module without having to deeply understand the neighboring modules.

It is the independence of the technology which is important. This doesn't, of course, have to directly align with the boundaries of documents, but equally obviously it makes sense to have the different technologies in different documents so that they can be reviewed, edited, and implemented by different people.

The web architecture should not be seen as a finished product, not as the final application. We must design for new applications to be built on top of it. There will be more modules to come, which we cannot imagine now. The Internet transport layer folks might regard the Web as an application of the Net, as it is, but always the Web design should be to make a continuing series of platforms each based on the last. This works well when each layer provides a simple interface to the next. The IP is simple, and so TCP can be powerfully built on top of it. The TCP layer has a simple byte stream interface, and so powerful; protocols like HTTP can be built on top of it. The HTTP layer provides, basically, a simple mapping of URIs to representations: data and the metadata you need to interpret it. That mapping, which is the core of Web architecture, provides a simple interface on top of which a variety of systems -- hypertext, data, scripting and so on -- can be built.

So we should always be looking to make a clean system with an interface ready to be used by a system which hasn't yet been invented. We should expect there to be many developers to come who will want to use the platform without looking under the hood. Clean interfaces give you invariants, which developers use as foundations of the next layer. Messy interfaces introduce complexity which we may later regret.

Let us try, as we make new technology, or plan a path for old technology, always to keep things as clean as we can.

]]> Version Identifiers Reconsidered tag:www.w3.org,2007:/QA//1.127 2007-12-18T18:10:15Z 2008-01-09T13:08:37Z The Architecture of the World Wide Web includes a section on extensibility and versioning of languages and data formats. The TAG is having second thoughts about the suggestion that all data formats SHOULD provide for version identification. Sometimes it is a good thing to do, but sometimes not. Noah Mendelsohn The Architecture of the World Wide Web includes a section on extensibility and versioning of languages and data formats. Quoting from the architecture document:

Good practice: Version information

A data format specification SHOULD provide for version information.

So, it's always a good idea when you design a language or data format to provide a way for instance documents to include something like a version attribute, probably near the beginning of the document, to indicate what version of the language is being used.

Or is it always a good idea?

What does a version identifier convey?

In fact, do we even agree on what it means to put something like a language version marker on a document? Let's imagine a simple XML language designed for setting down recipes. In the first version of the language, the markup looks like this:


<recipe name="Tuna Salad" recipeLanguageVersion="1.0">
  <ingredients>
    <ingredient name="Tuna Fish"  amount="1 can"/>
    <ingredient name="Mayonnaise" amount="3 tablespoons"/>
    <ingredient name="Capers" amount="a few"/>
  </ingredients>
  <steps>
    <step>Open can</step>
    <step>Drain liquid from can.  Put fish in bowl.</step>
    <step>Add mayonnaise.  Stir well.</step>
    <step>Add capers.  Stir gently.</step>
  </steps>
</recipe>

The allowed markup in version 1.0 of the recipe is just what's shown above: an outer <recipe> containing <ingredients> and <steps>, etc. Eventually it's decided that it would be useful to provide optional pictures for ingredients or steps. So in version 2 of the language we can do things like:


<recipe name="Tuna Salad" recipeLanguageVersion="2.0">
  <ingredients>
    <ingredient name="Tuna Fish"  amount="1 can"
                picture="./CanPicture.jpg"/>
    <ingredient name="Mayonnaise" amount="3 tablespoons"/>
    <ingredient name="Capers" amount="a few"/>
  </ingredients>
  <steps>
    <step>Open can</step>
    <step picture="./DrainCanPicture.jpg">
           Drain liquid from can.  Put fish in bowl.</step>
    <step>Add mayonnaise.  Stir well.</step>
    <step>Add capers.  Stir gently.</step>
  </steps>
</recipe>

Question: let's imagine that version 2 of the language, the one that supports the optional pictures, has been out for awhile, but I still want to write a simple recipe with no pictures:


<recipe name="ice cubes" recipeLanguageVersion="??">
  <ingredients>
    <ingredient name="water"  amount="1.5 cups"
  </ingredients>
  <steps>
    <step>Put water into ice cube tray.</step>
    <step>Freeze.</step>
  </steps>
</recipe>

What's the best value to put in the version attribute? I know that version 2.0 is the latest version of the recipe language. In fact, that's the only version of the specification I have next to me, so maybe I should use that? There's a problem, though. That version="2.0" marker might not work with software that's written to version 1.0, and in fact, my document would otherwise be a fine 1.0 recipe document.

So, maybe I should label it 1.0? Unfortunately, that's a bit hard for me. I don't want to have to go through the specifications for every version of the recipe language that's ever existed just to find the oldest that works. I really don't want to do that if the language has been revised a lot! Also, these sample recipes are small, but if I were using software to write very long documents, then that software would either have to keep track of the latest features used, or else search the entire document before writing it to a file, in order to get that version identifier at the front.

Indeed, just these complexities have proven troublesome for the deployment of languages like XML 1.1. XML 1.1 is similar to XML 1.0, but it enables the use of some new Unicode characters (just as recipe language V2 allows for use of new image tags.) The XML 1.1 Recommendation suggests that:

XML Programs which generate XML SHOULD generate XML 1.0, unless one of the specific features of XML 1.1 is required.

In fact, it has often proven difficult to write software that generates documents labeled as XML 1.1 only when necessary: it's much easier for XML 1.1-compatible software to label all output as <xml version="1.1">, resulting in documents that are unusable with widely deployed XML 1.0 software. Perhaps for reasons like this, adoption of XML 1.1 has been slow.

Returning to the recipe example, maybe the version attribute should take a list of versions, and I should put in both 1.0 and 2.0? That could be helpful to consuming software, but it still means that I (or my software) must be familiar with all the previous versions of the specification.

So, we need to ask, is the version identifier used to convey:

  • The earliest version of the language with which the document is compatible (1.0 in the recipe example)?
  • The version of the specification I used as a guide when writing the document (2.0)?
  • A list of versions with which the document is compatible?
  • Something else?

The best answer is probably different depending on the language, how often it's revised, whether revisions tend to maintain backwards compatibility, etc.

Is having some sort of version identifier always a good idea?

That Good Practice Note quoted above says "provide a version indicator", but we've just shown that we're not always quite clear on what that would do anyway. Is it still good advice to suggest that surely each language should provide for something in the instance? If so, should its use be required or optional?

As shown above, it's common for the same instance document to be legal in many versions of a language. As long as such documents are likely to have the same or sufficiently compatible meanings per the different versions, then it may be better to omit any indication of version in the instance, and leave it to the receiving software to decide whether the document can be processed. After all, with the second recipe above, the receiver will soon enough discover that it can or can't process picture attributes, and if not, it either will or won't know that they can be safely ignored. Version attributes can be helpful in giving early warning of incompatibilities, or as a crosscheck for catching errors, but they're usually not essential to correct operation.

One important exception is in the case where the language is likely to change in incompatible ways. If the same document means different things in different versions of a language, then it's very important to indicate which version the author had in mind when creating the document. Putting that version indicator into the document itself is one good way to do it. So maybe the right advice is:

Proposal for Future Architecture Document: Version information

If a language or data format will change in incompatible ways, then indicate the language version used for each instance.

Are namespaces a good way to identify language versions?

If version identifiers aren't always a good bet, what about namespaces? Many modern languages allow the creation of globally unique names, identifiers, tags, etc. In XML this is done through use of Namespaces. In RDF, it's done by using URIs as identifiers, etc..

Sometimes it's appropriate to use new identifiers for each version of a language, and mechanisms like namespaces can make that easier:


	<r:step xmlns:r="http://example.org/recipeLanguage1">

vs.


	<r2:step picture="./food.jpg"
                 xmlns:r2="http://example.org/recipeLanguage2">

In this example, the element with expanded name {http://example.org/recipeLanguage2, step} allows a picture attribute, but {http://example.org/recipeLanguage1, step} does not.

A full discussions of the pros and cons of using namespaces this way is beyond the scope of this note. One important advantage of using namespaces is that they can be easily applied not just to the root element for the language as a whole, but to mixtures of compound document markup, in which each sublanguage evolves with its own namespaces. Also, because namespace names are URIs, you can use the Web itself to get information about them.

Namespaces do have drawbacks. Imagine if there were 50 different namespaces for a language just because 50 separate bugs had been fixed in different errata. Would you republish all the markup in 50 namespaces? Would each document have lots of namespaces, with each element named with the last namespace in which it had been revised? Namespaces can be very useful for designating language versions, but there's no one idiom that's right for all languages. We note that most widely deployed tag-based languages for the Web (HTML, XML Schema, XSLT) have chosen either to use the same namespace(s) across multiple versions, or in the case of some flavors of HTML, not to use namespaces at all.

Conclusions

So, the TAG is having second thoughts about the suggestion that all data formats SHOULD provide for version identification. Sometimes it's a good thing to do, but sometimes not. Perhaps the right advice will be what's proposed in the revised Good Practice Note above. In any case, the TAG has been working for several years on a finding that will explore in detail many issues relating to versioning, and version attributes are likely to be among the topics covered. In the meantime, we thought we'd take the opportunity to signal that we're not so sure that the advice in the Architecture Document is as good as we thought.

By the way, TAG member David Orchard has covered some of the same topics as well as many others relating to versioning in his personal blog. Links to a few of his postings follow my signature below. Dave is also the principle author of the TAG's draft finding on versioning. Working drafts covering Terminology, Strategies, and Versioning of XML Languages are available for review. New drafts come out every few months, and we're hoping to have something more or less complete, well, real soon now.

Noah Mendelsohn

Note: unless otherwise indicated, opinions expressed in the TAG's blog are those of the individual authors, and do not necessarily represent consensus of the TAG as a whole.

Links to Dave Orchard's Blog Postings on Versioning

]]> What comes after Web 2.0? TV Raman says: 2^W tag:www.w3.org,2007:/QA//1.107 2007-11-15T12:53:11Z 2007-11-15T12:54:18Z TPAC talk molly's item wish for mathml in HTML... Dan Connolly http://www.w3.org/People/Connolly/ TPAC talk
molly's item
wish for mathml in HTML

]]> A story about namespaces, MIME types, and URIs tag:www.w3.org,2007:/QA//1.106 2007-11-13T02:59:42Z 2007-12-21T10:29:06Z Noone seems to know where the story begins; Ian Jacobs reminded me about magic namespaces as I enjoyed breakfast on Thursday; Steven Pemberton and Bert Bos had told it to him, perhaps prompted by Ian Hickson's question in the URI-based... Dan Connolly http://www.w3.org/People/Connolly/ Noone seems to know where the story begins; Ian Jacobs reminded me about magic namespaces as I enjoyed breakfast on Thursday; Steven Pemberton and Bert Bos had told it to him, perhaps prompted by Ian Hickson's question in the URI-based extensibility panel the day before: how do we make namespaces usable by HTML authors?

On Saturday, I took an action in the HTML Working Group discussion of ARIA to write it up. Little did I know that by the time I got back to the office, Norm would have written up Implicit Namespaces for me.

Thanks, Norm!

]]> The impact of Javascript and XMLHttpRequest on web architecture tag:www.w3.org,2007:/QA//1.87 2007-10-18T11:26:47Z 2007-10-22T18:54:38Z This issue was raised briefly on the TAG telcon of 11 October 2007, but I think we dismissed it too quickly.The basic WebArch story about URIs, resources and representations makes sense to people because they can see the relationship between... Henry S. Thompson This issue was raised briefly on the TAG telcon of 11 October 2007, but I think we dismissed it too quickly.

The basic WebArch story about URIs, resources and representations makes sense to people because they can see the relationship between information resource ('the Oaxaca weather report') and representation (<html><title>Today's weather for Oaxaca</title>. . . ).  When many web pages make extensive use of Javascript to compute the html that determines what you see on the screen, this relationship is weakened.  It's not just human beings doing 'view source' who lose out---search engines do too.

Although it's true that some proportion of Javascript-heavy pages are just badly designed, ignoring the Least Power finding through ignorance or laziness, it's certainly the case that some such pages, for instance those which make innovative use of XMLHttpRequest to synthesise information 'on the fly', could not be done any other way, and so don't violate the Least Power rule.

My conclusion: as we try to tell a more carefully articulated story about URIs and resources and their relationship, we need to pay more attention to the User Agent and the user experience. The thing most closely related to the Oacaxa weather report is the words I see on the screen, not the HTML which gets interpreted to produce them.

]]> When to standardize, especially an RDF API tag:www.w3.org,2007:/QA//1.34 2007-03-02T00:47:09Z 2008-12-03T23:48:52Z The HTML 4.01 specification has an IMG element, but there is no normative dependency on the PNG or GIF or JPEG specifications. "What good is an HTML user agent that doesn't support GIFs?!?" you might ask. And you wouldn't be... Dan Connolly http://www.w3.org/People/Connolly/ The HTML 4.01 specification has an IMG element, but there is no normative dependency on the PNG or GIF or JPEG specifications. "What good is an HTML user agent that doesn't support GIFs?!?" you might ask. And you wouldn't be alone. From the early days of W3C, there have been calls for a standard "web browser profile" component specification that listed which URI schemes (http, ftp, mailto, ...) and which formats (HTML 3.2, GIF, ...) and so on a standard web browser should support. It always seemed to me that the market would sort that out by itself and any standard, W3C could put in place, would be perennially out of date and irrelevant.

According to the Web Architecture document, orthogonal specifications are a good thing. In section 5.1. Orthogonal Specifications:

When two specifications are orthogonal, one may change one without requiring changes to the other, even if one has dependencies on the other. For example, although the HTTP specification depends on the URI specification, the two may evolve independently. This orthogonality increases the flexibility and robustness of the Web.

W3C inherited from the IETF a bias for specifying interfaces rather than components; i.e. data formats and protocols rather than software modules. I gather that in TV/consumer electronics, there are useful component standards for Web User Agents. But note that an in-car voice browser or a screen reader or good old lynx doesn't support PNG nor GIF, and while their marketplaces are perhaps smaller than desktop or mobile screen-oriented browsers, they're pretty much first-class citizens as far as W3C specifications, especially Web Architecture, are concerned.

APIs are more like interfaces than components, but they tend to be tied to platforms. The IETF has a cultural bias for on-the-wire formats over APIs, and for good reasons, I think. With OMG specs, at least the early CORBA specs, lots of products conformed to the spec (or at least claimed to) without actually interoperating with each other. It wasn't until the arrival of IIOP, an on-the-wire CORBA format, that the rubber hit the road and the interoperability issues got addressed.

Meanwhile, the IETF's aversion to APIs is not without exception: witness GSSAPI. And the W3C has been doing Javascript APIs in the form of the DOM since the early days of XML. Some argue that the DOM specs are ugly, and I tend to agree. SAX and JDOM and the libxml2 pull API have a more elegant feel. But with DHTML and AJAX, one has to wonder: did the W3C DOM Recommendations do more harm or good? Sometimes a mediocre standard is better than no standard. It's clear to me that HTML standardization does more good than harm, but I don't pretend that the HTML design is a thing of beauty.

W3C also started out with a bias against standardizing programming languages. The principle of least power is a part of the lore that the TAG has recently adopted in a finding. For those reasons, when the Javascript designers were looking for a standardization forum in 1996 or so, I let it go to ECMA rather than arguing that it should be done at W3C. The fact that XSLT is turing-complete went under the radar a little bit at first; the WG was able to negotiate requirements by noting that its intended scope was formatting XML documents, not transformations in general. And I heard many times that people who don't see themselves writing Java programs are happy to develop XSLT transformations. But I had very strong misgivings about crossing that line. By the time I was reviewing XQuery/XPath 2.0 functions and operators, I disregarded any claims about narrow scope and looked at it as the standard library for the new computing platform that it is.

And now with the Rich Client Activity and the Web API WG, we're fully engaged in standardization of Javascript APIs with no pretense about language independence. It remains to be seen whether we're actually going to tackle enough of the security policy issues to standardize a real platform or whether we need to just leave that to the market for a while. But enough of the right people seem to be involved in the work on XMLHTTPRequest to make me think we're doing more good than harm there. I haven't seen enough test cases for my tastes yet, but I gather they're on the way.

I don't do much of Javascript hacking myself, but I gather it's an unholy mess of incompatibilities. "Where was W3C when XMLHTTPRequest was being designed in the first place?" you might ask. Maybe we were asleep at the wheel and we could and should have prevented the mess. But maybe we were in "mostly harmless" or "first do no harm" mode, letting the market establish what's really needed. I was dead set on tackling multi-namespace integration in the first version of XML Schema, but in hindsight it's pretty clear to me that we should have gone a little slower, i.e. started with a smaller scope.

The question of when and whether to standardize an RDF API has been hanging in the air for a decade or so. My personal experience with python APIs for RDF suggests that, for example, there's a core of cwm and rdflib and redland that is the same except for a few coin-toss issues. And there are several mature Java APIs and the tabulator has an RDF store in Javascript. Meanwhile, SPARQL is maturing; maybe, like SQL, the string format of queries (and other operations) is the main thing we need to standardize. A survey on Standardizing a Semantic Web API for Javascript is open. Please let us know what you think.

There are precious few "W3C should never do XYZ" rules that I think are worth setting in stone. While we will naturally attract work that is like what we have done before, any place we can get a critical mass of the marketplace to get together and do the hard work of testing, internationalization, accessibility in a reasonably timely, fair and accountable way is a place where W3C should be able to do more good than harm.

]]>