In order for a "Working Draft" specification to become a "Candidate Recommendation" here at the W3C, it is likely to need a test suite.

Since the Widget P&C specification is of profound interest to many, we hope you too will be interested in helping realise its potential. A Widget test suite would help ensure compliant and interoperable Widget runtimes.

The W3C MWTS began working on one in it's limited capacity from 2008-09. It was first hosted at a git repository, which was exported to a W3C CVS. Then an assumption that Widget APIs would be tested too, led to work on a Widget Test Framework(WTF). However since P&C doesn't depend on A&E, the WTF is less useful and hence we're going back to basics.

So lets walkthrough how you would go about writing a test. First you want to test an assertion. Preferably one that's absolute like a MUST assertion. So lets rip out all the MUST assertions from the Widget P&C spec with the help of an online XSLT service.

Now we need to choose an assertion for a new test. First we quickly check if there isn't an existing test already. Lets focus on a test that will have a clear outcome, namely Invalid Zip Archive.

To conform to this specification, a Zip archive must contain one or more file entries and must not be an invalid Zip archive.

Easy! I'll make an empty Zip. Hmm, can you with Zip?

Ok, you could make an empty widget by only including directories! Now that would work with Zip. Lets get to work:

git clone git://git.webvm.net/wgtqa # Grab the Widget test sources
cd wgtqa/wgt # Static test directory
mkdir -p 5.1-invalid-zip-onlydirs/only/dirs/is/an/invalid/widget
make
unzip -l 5.1-invalid-zip-onlydirs.wgt

Boom, job done! Running 5.1-invalid-zip-onlydirs.wgt with a widget runtime must trigger an Invalid Zip archive, otherwise it's not compliant.

Ok, lets git add 5.1-invalid-zip-onlydirs and commit and send the patch to the MWTS list. Oh no! You can't hold just directories in git source control.

Now we need to work around this, by creating a build script to generate the widget. Ok, lets go to work:

cd gen

Have a look at the README, config.mk and Makefile. Ok, lets name the test by creating the directory:

mkdir 5.1-invalid-zip-onlydirs-empty
cd 5.1-invalid-zip-onlydirs-empty

Lets write a Makefile to generate the test.

include ../config.mk
all: clean invalid
invalid:
    mkdir -p empty/invalid/widget
    cd empty; zip -r ../$(NAME).wgt .
clean:
    rm -rf *.wgt empty
.PHONY: invalid

Ok, make generates a test widget. Inspect by vim 5.1-invalid-zip-onlydirs-empty.wgt with:

" Treat .wgt files as .zip files
au BufReadCmd *.wgt call zip#Browse(expand("<amatch>"))

In your .vimrc, should confirm the widget just contains folders. Bad widget.

Lets commit the test to the cloned wgtqa git repository and contribute it.

git add 5.1-invalid-zip-onlydirs-empty/Makefile
git status # should show you are staging the new Makefile
git commit # Give a good message by try referencing the relevant part of the P&C specification
git format-patch "HEAD^" # Generate a patch of that last change
git send-email --to=public-mwts@w3.org 0001-Invalid-Zip-case.patch # contribute test to the list

Apologies for those of you who aren't familiar with the Unix working set. Indeed this can be difficult to follow. Especially since such a "simple test" had to be generated. Generated tests are the advanced case.

You could ignore this test framework and just contribute a widget package that tests an assertion to the public-mwts list and we would be very grateful.

If your test is accepted, you should see it eventually show up in the widget test suite.

TODO: LICENSING?

Latest: Leonard Rosenthol has since posted a followup on the discussion.

PDFSAGE wondered what the cons are with PDF/A compared to simple HTML for document archival. The debate generally comes down to what you think a document is. If it's an A4 page for printing, you probably want PDF. If a document is an arbitrary unit of information, I would suggest HTML.

Lets start why the PROS of PDF/A. You'll need Flash to view this PDF preview. Actually to do mostly anything with PDF, you need proprietary tools monopolised by Adobe.

You can't just assume people have a PDF viewer installed. Hence PDFSAGE shared his PDF document assuming I had Flash installed. Another proprietary tool. Great, what a start!

Cons of PDF/A

• The PDF viewer isn't nearly as pervasive as a Web browser. Is there a PDF viewer on your mobile? No, I thought not.
• The PDF viewer is slower than a Web browser.
• A PDF is many times larger than an HTML file. Imagine Wikipedia as a PDF/A file? That would be CRAZY.
• Since the viewer and content are much larger than HTML counterparts, PDF/A demands a faster internet connection. Have a slow connection? You're out of luck!
• PDF isn't part of the Web. It's non-trivial to get PDF content on the Web. People end up converting it into a PNG and that's a terrible loss of information.
• It's non-trivial to index and parse out information from a PDF
• It's non-trivial to edit content in a PDF. Indeed, PDFs are often designed to be static (for Archival). Though if information can't be maintained, one can argue it's dead.
• Only accurate representations of stored content can be produced if you embed the font. Bloat!
• A document is of little use unless it's transcribed into text. Scan a STASI file into a PDF. Great, now what? Storing it as a PNG would be even better as people would at least been able to view it easier.
• PDF has a poor accessibility record
• Non-trivial to diff, track and compare PDF documents
• An open standard? That you need to pay ISO 200GBP for?! Are there at least two interoperable implementations of PDF/A?
• Probably only one conforming implementation (Guess who!). Is there a test suite?

Pros of HTML

• You can read HTML in the simplest of text editors
• An algorithm for parsing HTML is defined
• You can "sign" an HTML file by using XML digital signatures. Widgets in fact use a subset called Widgets 1.0: Digital Signatures.
• Scalable. Want text on your big or small screen? Sure thing.
• Easy to edit and maintain. Anyone can edit HTML with a plethora of tools and support.
• Simple to index, find and use the information marked up within an HTML file. Same is not true of a PDF.
• HTML is space efficient. PDF isn't.
• HTML can include "marginalia" like comments and notes.
• HTML has several ways of adding metadata support, though Google search generally does not rely on them for best results
• HTML can convey critical information. It's done so more effectively that PDF has ever done.
• Need to package some HTML content? (i.e. self-containment) Use a widget!
• You can generate static snapshots of HTML to formats like PDF, with tools like Prince. You can't do the reverse very easily!
• HTML is already the primary medium for archival of information! Checkout the waybackmachine
• Worried about data being tampered with? Mandate source control like git where each document can be explicitly tracked.

Cons of HTML

• Can't be rendered consistently across devices or mediums -- HTML is not a (static A4 print) presentation format
• Printing is particularly tiresome, which is good news for trees
• It's living markup and it ideally needs to be maintained

Comments sez:

speedtester.bt.com see http://www.kitz.co.uk/adsl/btwspeedtest.htm
Dial 17070, press option 2 listen for pops, clicks or noisy/buzzy line.

Imagine you want to read the attribute test= from this fragment of XML called test.xml:

<widget test="foo">
    <name>blah</name>
</widget>

Using lxml, you need to run getroot.

import lxml.etree as etree
tree = etree.parse("test.xml")
print(tree.getroot().attrib['test'])

After rooting my UK T-mobile G1 and then flashing with JesusFreke’s ADP 1.5, I was able to install android wifi tether.

Previously I tethered using the adb forward tcp:1080 tcp:1080 socks trick, but that sucked because:

• DNS didn't work
• if it did, you could only use HTTP easily
• bit of a pain to setup

Ideally I would have liked to tether via a USB cable, though I couldn't quite figure out how to create a USB based network. Anyway a Wireless access point (AP) is better for sharing and being social, though it does need to be physically tethered to a power source since the device sucks battery juice whilst tethering.

Ad-hoc Wireless Networking Debian to the Android G1

This is a bit tricky, as I couldn't seem to get a DHCP IP over ad-hoc mode. So here I set up everything manually, after inspecting the device with adb shell ifconfig tiwlan0.

I added to /etc/network/interfaces:

iface wlan0 inet static
    wireless-essid G1mobile # configure this in 'Wifi tether' on your G1
    wireless-mode ad-hoc
    address 192.168.2.20
    netmask 255.255.255.0
    gateway 192.168.2.254
    dns-nameservers 192.168.2.254 # you need to install [resolvconf](http://packages.qa.debian.org/r/resolvconf.html)

And commented out the existing wpasupplicant configuration. Next sudo ifup wlan0 and you should be away.

Comparing England's T-mobile, Orange and Vodafone 3G

I borrowed a Vodafone SIM card, but I couldn't get it working until I manually chose the Vodafone network and setup the APN with wap crap: wap.vodafone.co.uk user: wap pass: wap

T-mobile don't use the loaded legacy wap word, but their APN is confusingly called 'general.t-mobile.uk'. User: 't-mobile', Pass: 'tm'. I need to experiment with APNs as I hope I get around content transformation and crappy looking images.

Orange nicely just requires 'orangeinternet' to hop on. They give Vodafone a run for their money from Guildford! Orange also don't seem to run content through any transformation on my test. So images look decent! Orange WINS!

Just 12 months of poor T-mobile service to go of my 18 month contract... then PAYG for me! PAYG deals for mobile data are getting seriously reasonable of late. So much so, I might switch SIMs where I know T-mobile will suck.

I'm not quite certain if the aforemnetioned APNs are HSDPA. The 3G icon is present on Android during all the tests.

Want prettier shortcuts or bookmarks to your favourite Web applications?

Checkout shortcut.dabase.com and the reasons why.