If you similarly start from a belief that it must be possible to enable recipients to be charged for the ‘content’ they receive, and HTML5 can provide a standard means of doing so, then you have started from an unsound proposition (one informed by copyright – an unnatural and unachievable constraint on the reproduction of intellectual work).

Just as there was plenty of well paid work in the development of umpteen DRM technologies, so there could be well paid work in the development of content charging/licensing technologies.

However, not all software engineers are mercenaries happy to be well paid to waste their time attempting what they know to be impossible. Making a computer intelligent is possible. Making information impossible to copy is not.

There remains plenty of scope however, for standard ways of expressing monetary exchange agreements. And that’s exchanges of work for money rather than liberty for money.

I’d check out http://www.replicounts.org for one avenue to explore – as something that indicates what kind of payment system might one day be appropriate to incorporate into HTML.

Payment doesn’t imply DRM, except to libertarian software engineers who have been conditioned to equate the two. Software engineers ( I am one too) always claim to not be persuaded by ideological arguments. Usually this just means that they’re failing to acknowledge the unstated ideological arguments by which they’ve been persuaded.

There’s a difference between adding value and subtracting value.

Using geolocation data to prevent the display of content unlicensed for the viewer’s location, is quite different to making the presentation of information more appropriate and useful in the context of the viewer’s location.

On a related tack one could argue that DRM’s only detractors are politically or ideologically driven. I think that is to misunderstand a far more fundamental reason why DRM cannot work.

As a software engineer I’m not persuaded by ideological arguments as to what is feasible or not. 18th century privileges that require information to remain uncopyable such that its distribution can be commercially licensed are not only ideologically unsound, they are also unsound from a software engineering perspective.

I’m all for facilities that help people exchange money with each other, but I’m always wary of ideological premises based on payment for ‘content’. It’s like proposals for perpetual motion machines. They’re attractive, but there’s a good, non-ideological reason to discount them.

Even so, don’t let me discourage you from explaining more about the payments you suspect HTML5 could facilitate and how it could do so.

Look, I don’t necessarily believe that HTML5 should have a payment API, though I do think that the open web should support getting paid in a way that bind people to a single company. My argument is that declarations like “a payment API is fundamentally inappropriate to HTML” reflect an ideology, a belief about the way the web should work, rather than an essential truth about the way the web can work. At one time a lot of people would have argued that “a geolocation API is fundamentally inappropriate to HTML” based on a belief that cyberspace should transcend physical location. Clearly that belief is no longer very popular in the face of the money to be made with location-based advertising.

Note that I’m not trying to cast aspersions on ideology. I don’t think a non-ideological, “purely technical” stance on the web is possible. You can’t design the web without some set of beliefs about how the web should work. But we should try to avoid claiming that those beliefs are determined by the technology and thus not up for debate.

How is payment in support of presentaton?

I can see that details of the author/producer for any presented object and even their preferred payment service may be appropriately described in HTML5.

However, payment is about exchange. What do you have in mind that is to be exchanged and by whom?

Then perhaps we can consider how HTML5 can be used to help express and execute such an exchange (or enable the browser to).

I had assumed you had in mind some way that HTML5 could be used to attach micro-paywalls to presented objects or something like that, e.g. “This content or full functionality can be downloaded/unlocked for $5″.

This is similar to Playdar, in that it’s a standard API to any number of music providers.

Lucas, I have no idea what a payment API would really look like. I’m imagining something like this: I configure my browser so that Citibank is my preferred payment handler (or more likely a wizard script on the Citibank site does this for me). The payment API just exposes a function for passing a payee ID, amount, and callback to my preferred payment handler. How Citibank chooses to structure the interaction after that is up to them, but once the transaction is cleared the callback is called with some sort of token and my MP3 starts playing, or my ebook loads, or whatever.