- From: Erik Wilde <dret@berkeley.edu>
- Date: Thu, 08 Apr 2010 11:40:17 -0700
- To: uri@w3.org
- CC: Dan Brickley <danbri@danbri.org>, Sandro Hawke <sandro@w3.org>, Bob Aman <bobaman@google.com>, wot@webofthings.com
hello all. > Yes, the use of URIs in QR struck me as rather ad-hoc too, relying on > heuristics too often. this certainly is the case, and why i haven't done any systematic study, the few apps that i tried on mobile devices all seemed to use their own methods and conventions, and most of them were not as robust and generic and configurable as they should be (if they were trying to be useful as general-purpose QR apps). i would be hard-pressed to exactly define what "robust and generic and configurable" means, though, and it seems to me that answering this question could be very valuable. > I've often thought we should do this, but only recently got my hands > dirty coding (integrated a QR reader into an iPhone app). i still hope to see QR support popping up in mobile OS platforms, and since there's an open one out there, if somebody is really adventurous, that would be a very interesting exercise to go through... > I don't know the status of QR Codes as a spec, in terms of things like > public availability of the standards docs, royalty free status, etc. > etc. http://en.wikipedia.org/wiki/QR_Code#Standards suggests "NTT > docomo has established de facto standards for the encoding of URLs, > contact information, and several other data types" but the use of > "URL" rather than "URI" doesn't fill me with confidence that the work > is 100% done. But even having a 'state of the landscape' document > (rather than something standards-like) could be a huge help for > everyone. Although an XG is a good idea and I'd try to participate, > for now I'd settle for a fact-pooling Wiki page... my take on this is that wikis tend to be much less useful that actual deliverables with a well-defined set of what should be covered, and by when. maybe we could have an QR dinner at www2010 and see how we might best proceed with this? > Have a play with http://github.com/diva/digital-voices/ > http://www.youtube.com/watch?v=cjnPwV6yP6o > http://www.ics.uci.edu/~lopes/dv/dv.html too, especially the birdsong > encoding I think is quite lovely - > http://www.ics.uci.edu/~lopes/dv/BirdInfo.wav - you could have similar > software scanning audio going through your machine looking for secret > codes in radio jingles, youtube videos etc... i did not know of this. pretty amazing. so, instead of looking at QR, probably it would make sense to say what to best in real-world representations of "web-friendly handles", and then QR or audio would just be different representations. QR is ISO and thus may be a little further along that the audio encodings, but generally speaking, connecting the real world and the web should probably work in the same way for both representation types. > I think there's a lot to be gained here around mobile apps, eg. to > avoid a proliferation of barcodes outside points of interest (shops, > restaurants etc) I hope we'll see a move towards a single barcode that > is for a page describing the location, and embedded RDFa to make that > description machine-readable. this idea will make facebook or google very happy. have a sole provider of identity and everything goes through them. i think how web-friendly real-world encodings will be used should not be prescribed in any way, but we need to make sure that the web architecture parts of it work ina well-defined way. > Can you advise on the options when a W3C work item is heavily based > around work already standardised elsewhere? Are there formal > conventions/constraints already, or just social conventions like - > play nice and establish friendly liaison? my take is that this is basically the same as almost all web stuff using unicode; unicode is stable and that's all that matters. the same can be said for QR. it's an ISO standard and that's all that matters (maybe not quite giving IP issues, but at least from the technical perspective). > A lot of QR use does seem to be to discover identifiers. My guess is > that heuristics are doing 80%+ of the work just fine, so there hasn't > been a strong driver to 'catch up with the paperwork' and say exactly > how this should work. all of the apps i tried work in some cases and not in others. many get URI decoding wrong with non-ASCII URIs or even with "+" signs in them. many don't recognize non-HTTP(S) URIs. many have no way of associating schemes with apps. all of this is not rocket science, but it might help the ecosystem a lot to tell developers what they're supposed to do if they want to support not only QR scanning, but also the mobile web. cheers, dret.
Received on Thursday, 8 April 2010 18:40:58 UTC