Learning the World » XML

Amazon Plugin Authorization

Martin Kliehm — Fri, 31 Jul 2009 21:00:04 +0000

Oh, it’s confusing how often Amazon changes it’s product names and API. In my plugin the Help response group is used for key validation, alas recently it’s been deprecated. I need more time to look for an alternative. In the meantime you can hack it by adding a file amtap-aws-key-verification.txt in the wp-content/cache folder where the content is true.

Starting August 15th, the AWS Product Advertising API, as the former E-Commerce Service is now called, will only accept signed requests. The plugin will stop working if you don’t update. Thus I needed to re-engineer a few functions of my WordPress Amazon Machine Tags Plugin.

What you need to do is:

Update to version 3.0 of the plugin.
If you didn’t adapt any files just overwrite them. If you customized the CSS or XSL files, take care that you don’t overwrite yours. Also the XSL namespace must reflect the API version used in the plugin (2009-07-01), i.e. xmlns:aws= "http://webservices.amazon.com/ AWSECommerceService/ 2009-07-01"
Get your Secret Access Key in addition to your existing Access Key ID. Your future requests will be signed using the secret key.
Go to the plugin’s admin interface and enter the secret key.
Some people experienced a few minutes where the items didn’t show up, instead they got the untransformed XML code. After a few minutes the problem resolved itself. My guess is that Amazon cached the XSL files, the versions mismatched, therefore the XML wasn’t transformed. That’s why I renamed the XSL files so that the new ones will be used. If you want to be sure, also delete the cached files amtap-aws-items-for-post-*.html in your wp-content/cache directory.

If you encounter any problems with the update, re-install the old version and let me know what went wrong so that we can fix it together until August 15th.

You can also support the plugin by translating it. There’s an empty PO file in the package. With a tool such as Poedit it’s fairly easy to translate everything. Thanks.

Farewell, XML declaration

Martin Kliehm — Wed, 04 Jun 2008 16:00:04 +0000

For years I have been using an XML declaration prior to my DOCTYPE declaration:

TR/xhtml1/DTD/ xhtml1-strict.dtd">

It was obvious for me that such a declaration would be a good thing to have since XHTML is XML after all. Only later I learned that it triggers a bug in IE6 to render pages in quirks mode with a broken box model. But I was used to build workarounds for Internet Explorer bugs since IE 3.0 and never knew anything but the broken box model in IE, so I continued to use the declaration.

Until recently my colleague Thomas Junghans took the trouble to research, and found this phrase in the XHTML specification:

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

The declaration is not required as long as you encode in UTF-8 or UTF-16, you are only strongly encouraged to use it. Gasp!

Richard Ishida lists some advantages of using the declaration when serving the pages with an XML MIME type or viewing them offline, however I’m convinced the disadvantages prevail.

So as long we are stuck with IE6 — and people say that could be as long as 2014 when support for Windows XP ends (reminder to self: throw a party on 8 April, 2014) — I will refrain from using the XML declaration. Amen.

Extend the Searchbar with OpenSearch

Martin Kliehm — Sat, 19 Apr 2008 20:00:14 +0000

OpenSearch is known as an open source format to syndicate and aggregate search results. It was developed by Amazon / A9 and quickly gained support from the big search engines. Their involvement is somewhat intimidating — your site’s not Google, so who wants to syndicate your search results anyway?

But if your blog or a client has a loyal readership, it would be convenient if they could just use their browser’s searchbar as a shortcut. For example currently we work on a website relaunch for a big German city, and it’s easily conceivable that citizens want to search this site more often.

Here comes a side effect of OpenSearch: the OpenSearch descriptions are machine readable XML files. Firefox and Internet Explorer 7 are two of those “machines” if you let them know the file exists:

rel="search" type="application/ opensearchdescription+xml" title="Your website’s title" href="/opensearch.xml" />

Of course that belongs in the head. Now all you need are a few more lines of code in the opensearch.xml file:

opensearch/1.1/">
Your website’s title
A short description of the search
UTF-8
http://yourdomain.com/favicon.ico
search/ ?q={searchTerms}"/>

Just change the shortname property, the favorite icon path, the search URI and parameters. Don’t change {searchTerms}. And that’s all, it’s a five minute no-brainer…

Crowdsourcing YouTube Video Captioning

Martin Kliehm — Mon, 31 Mar 2008 20:34:45 +0000

Oh, I just love Christian Heilmann’s blog! He’s one of the most skilled JavaScript developers I know, so I can still learn tricks from him and his colleagues at Yahoo! But he also does everything with JavaScript, and every time when this happens, it inspires me to mull over how it could be done without! You know, because restrictive company proxies filter JavaScript, or just to provide a graceful alternative, or because I’m so old-fashioned.

So when Chris mentions JavaScript badges for del.icio.us, I think of Ed Eliot’s PhpDelicious or how to get similar results in WordPress. Naturally when he had the splendid idea to add captioning to YouTube videos with Google’s JavaScript API, I asked myself if there wasn’t a better way. There is, but to my surprise neither YouTube nor Yahoo! Video take advantage of that capability:

It’s common practice to implement text content in Flash via XML.
DFXP is a W3C XML standard for captioning videos.
There are free tools like MAGpie for creating captions, and they all support DFXP.
If YouTube or Yahoo! Video would allow users to upload and attach a DFXP file to a video, it would become dead easy for anybody to caption it. Not only for the filmmaker, captioning could be crowdsourced!

Just anticipating Joe Clark’s inevitable (and justifiable) objection: of course captioning is not an easy thing that anybody can do, to do it right it requires people with special training. But considering the number of videos on those platforms the only affordable and practical solution to provide any captioning at all is crowdsourcing. That can also be applied to the control of quality, accuracy, or reporting abuse.

Of course this would enhance primarily accessibility, but the XML files would further help search engines to index video content. And their marketing people would love such a feature for the positive PR!

Well, I submitted the suggestion both to Google and Yahoo!, you can vote on the Yahoo! Developer Network for it (Google is more closed-lipped). I’m curious who will be the first to offer that feature …

Oh, won’t somebody please think of the children!

Martin Kliehm — Fri, 28 Mar 2008 21:30:00 +0000

Please note that the PICS standard has been superseded by POWDER in 2009. The old RDF code can be included in a POWDER document, though.

A little known W3C standard is the Platform of Internet Content Selection (PICS). You can tell from the poor layout that it’s a very old standard — in fact all of its parts are from 1996 and 1997. OMG, that’s ancient! That’s even older than HTML 4, CSS, or the Web Content Accessibility Guidelines!

PICS is a system for self-labeling. That raised some concerns about censorship in 1998, but governments who really want to censor their population’s internet access have found more effective ways to block content (I, for one, can recommend Tor as a countermeasure, also available as a Firefox extension, though I cannot guarantee your government approves it). So what remains is a meta element with information about your website, accompanied by a machine readable RDF/XML file.

pics-label.rdf" type="application/rdf+xml" title="ICRA PICS label" />
http-equiv="pics-label" content='(pics-1.1 "http://www.icra.org/pics/vocabularyv03/" l gen true for "http://learningtheworld.eu" r (n 0 s 0 v 0 l 1 oa 0 ob 0 oc 0 od 0 oe 0 of 0 og 0 oh 0 c 1))' />

Since in the nineties internet progress was driven by porn, PICS is mostly about child protection, although it can be used to describe a machine readable privacy statement and other things as well. Think of an early predecessor of the Semantic Web. Or in microformats it would be hPorn. Well, I assume very few of you run xxx sites, so why am I wasting your time with this post?

Because the PICS standard is most convenient when your website is not pornographic. The standard provides a way to label your website and distinguish between pictures of naked people as Greek ancient sculptures, in an educational or journalistic context, or as mere porn. But despite the name it’s not only suitable for rating pictures, it’s for text content or user-generated content as well, among other criteria. Plus the PICS label is recognized by Google, so it’s not about rushing ahead and self-censoring to please our overlords, it’s a measure to maximize the target audience and avoid mislead traffic. I believe a few of your clients may appreciate that. For example although this post uses quite a few trigger words, PICS provides a way to tell search engines and cybersitting software about the true nature of this article. I love that ability!