At graflex.org we have used Microtek and Epson flat scanners. You do not need a drum scanner for your task. You might try posting your question at there or on photo.net, or just reading the existing postings there.
And yes, you can still get 4x5 film. Try it out sometime!
>It's an impossible thing to accomplish (you can't even get an MP3 player for $100) Huh? I just checked on eBay, "mp3 player," North America, Buy it Now and found tons of new MP3 players under $100. In fact, this one caught my eye: "Palm Pilot Tungsten E PDA MP3" for $100.
It is pretty much the same thing as the OLPC proposal: if you consider that the Tungsten E is a couple of years old and the OLPC is expecting ~$150 next year and $100 in a couple of years, it looks reasonable. Probably about the same amount of memory within a factor of two or so, and about the same display cost (they're claiming cost reductions in display, but note that the OLPC display size is not that much bigger, maybe 4x).
So, take a run-of-the-mill PDA, add a keyboard, and make the display bigger, and that's pretty much it. I really don't see why that's impossible, especially if they get orders for a million or so and get Quanta to make it.
It looks like it's about 20:1 for actual responses, so I'll add mine. I built an ElecraftK2 (more pix). Mine looks pretty much like the one in the picture.
A couple of weeks ago I went to Amsterdam and used it on Saturday and Sunday and got my radio to signal to Bulgaria, Russia, Italy, Montenegro, Poland, and England. (OK, some of these were also with another kit, a handheld KX1, but it's smaller and took only a weekend to build; more info, magazine article with more pix)
>Which would you rather validate, a set of CGI parameters or a blob of XML? Um, a blob of XML. Quoting and escape characters are a big source of vulnerabilities. XML has well-defined quoting rules. CGI parameters have no structure, so structure must be done ad hoc. XML structure can be validated on the server using XML Schema or Relax, or other mechanisms.
The HTML Working Group recently decided to remove this mediatype constraint on text/html. It was originally intended to make the XML / tagsoup distinction easier; instead it has emerged as a stumbling block.
I'm not sure what you mean by "select1" being an error; please let me know.
There are certainly efforts going on to bridge between HTML and XForms, so watch this space. But if you're interested in binding a UI to XML data you already have, it's a best-fit solution. Also, it's not clear that the size of XForms is any different from the size of large JavaScript solutions.
When you say
<submission id="update" replace="instance"> what happens is that when you put a submit button down with
<submit submission="update"> then it will submit the XML data in an HTTP POST with the XML MIME type, and the HTTP server will respond with another XML document. (See http://del.icio.us/leighklotz/xforms for a series of articles by Nicholas Chase at IBM DeveloperWorks on how to get PHP, Perl, Java etc. to do this.)
When the instance data is updated, either by the server response or by your using a UI control bound to one of the nodes, all data display changes are driven automatically.
For example, to implement COPPA, you just write one boolean expression that says this:
<bind nodeset="/application/personalInfo" relevant="/application/age >= 13"/> then taht means that the entire tree of data under the <personalInfo> element won't be "relevant" if the age is under 13. Then the UI system follows this directive and will not display any UI controls bound to those nodes (presumably email, name, address, etc.). Likewise, the submission system follows the directive and won't submit them either.
Then, to fully simulate the COPPA experience, you can put
<bind nodeset="/application/personalInfo/email" required="true()"/> which tells the submission system that email is required, so you can't submit without it. It also tells the UI system that it's required, and that gets shown as CSS property:required, which you can style in CSS like this:
input:required { color: red; }
Is this a good enough start of showing how XForms fits with XML and HTML and CSS?
Try AJAX with markup only, no hand-written JavaScript, by using the W3C's XForms standard. There are a number of implementations such as the Servlet-based Chiba (which fronts for Dojo and other packages), FormFaces written entirely in JavaScript (no server-side component), entire server-side pipeline systems such as Orbeon, and full client implementations such as the Mozilla/Firefox XForms Extension (just type "xforms" into your Firefox extensions finder), FormsPlayer IE Plugin, or cell-phone capable implementations such as PicoForms and SolidForms.
I wrote an entire webmail reader using PHP for the back end and XForms for the client. It runs in the Mozilla XForms implementation but could easily be made to work in any of the above, which differ mostly in how the CSS works. xmlmail
And for completness, I was an editor of an earlier version of the W3C XForms recommendation.
The problem with modern AI (and the flaw in Ian Pearson's predictions) is that we really don't understand many kinds and elements of intelligence Your argument seems to be
There are some things I don't understand and other smart people don't either.
Therefore, it's completely impossible to predict when we'll be able to understand it.
I have tried this approach whenever my boss asks for a B-level schedule, and it still hasn't worked for me.
According to CosmicBlog, the Marex webcam aboard the ISS is just getting operational, and has posted two images. You can view them at the marexmg site, or receive them directly over a radio or scanner hooked to a computer soundcard.
There are also toolkits and JavaScript apps that combine W3C standards with AJAX, letting you write a lot of the dynamic page stuff in a declarative fashion, using just markup (XHTML+XForms; I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms).
The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.
Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/ [sourceforge.net]
I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.
One good mechanism for getting the XML and asynchronous features but without hand coding JavaScript is to use any of the various XForms implementations. XForms is a W3C standard that defines a mostly script-free way of doing much of stuff people want out of Ajax, and it's done in a declarative way that's friendly to accessibility agents, and easier to deploy onto other devices. I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms
The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.
Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/
I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.
Another important option is the work that the Mozilla Foundation and IBM are doing to make a native implementation of XForms as an XPI for Firefox and Mozilla. See http://www.mozilla.org/projects/xforms/ -- they're now in version 0.6, with 1.0 targeting full XForms 1.0 compliance. Like all other Mozilla extensions, it's a 1-click install, and I think it's about 200KB, so it's not very big, and I hope it gets added to the default build after it reaches 1.0. (It's presently built with the nightlies.)
There are a number of other implementations, including browser plugins (FormsPlayer for IE), native implementations for embedded devices such as cellphones and kiosks (PicoForms, SolidForms, and entire server-side systems using XForms, such as Orbeon Ops, so I see an increasingly bright future for using XForms to build dynamic HTML interfaces on top of XML web services and deploy them across a range of devices.
Your point was that adding XForms to browsers breaks the entire web at theoretical level, in a way that's fixable only by chucking XForms and implementing something else instead, but I just demonstrated that was wrong. In both theory and practice, it's possible to add XForms support to a browser and not break the rendering of existing web pages.
So in response you say that IE doesn't implement XForms, a W3C standard, which is true, but true in a different way that's fixable: if IE implemented XForms (or if IE were more modular so that the formsplayer.com plugin was seamless), then it would be a done deal, and there's no theoretical problem.
Here's an interesting piece of opinion from Kurt Cagle, at O'Reilly, about how IE can move forward to XHTML and XForms. It's based on some one-on-one discussions he had with top Microsoft developers.
So I think this shows at least this one vendor prefers to do more of its innovation in new formats not based on standards. Given the economics of their product base, it's hard to blame them.
Given the large investment required for IE compatibility (proper implementation of "quirks" mode, underspecified areas, bug compatibility, etc.), it's not surprising that vendors who have achieved it are reluctant to support anything that diminishes the value of that investment; again, from an economic standpoint, it's hard to argue with this. I won't cite specific examples from the same minutes, but you can surely find this sentiment there.
grasshoppa wrote: I never understood why web standards aren't maintained by the folks that actually are writing the browsers. Membership would require a browser with, say, x% market share.
I think (1) you have this, because any vendor who is a W3C member and has a product out there has credibility on many important issues and (2) you don't necessarily want just that: the establishment of standards can lower the barriers to entry, which would make for more browsers with smaller market share (and thus more diversity but better interoperability) and bring to consumers the benefits of competition for good implementation of the common ground, and "innovation" in the other areas. Unfortunately, if you limit membership to large existing vendors (your x% solution), you get members who want to shut out new products and innovation, and simply want to preserve the status quo (which is web terms is called "IE Bug Compatibility"), while the go off and "innovate" in other areas to try to make non-commodity products that they can charge for (InfoPath, XAML, just to pick on MSFT but there are other examples).
Disclaimer: I was editor of a W3C recommendation, but my opinions here are my own (duh).
Definitely XForms. It's a W3C standard and XForms 1.1 is about to be published, with feedback from existing implementations on interoperability and necessary features derived from real use cases. It wraps up a markup-based interface to many of the things people do with XMLHTTPRequest, and handles all the callbacks and stuff for you, and leverages other technologies for much of the work (XML for data, XPath for addressing the data, CSS for styling, XML/DOM Events for eventing, etc.)
With IBM's contribution of an XForms XPI to Mozilla, and an Opera implementation, we'd have a chance at a cross-platform mechanism for deploying web applications in a way that's good for device independence and accessibility.
And since this is slashdot, I should point out that I was one of the editors of the XForms 1.0 recommendation. I would also like to point out that Opera Software wrote Opera, but the article doesn't mention that...
You can monitor solar activity from Firefox with the Propfire plugin. It puts a tasteful text-based solar flux / A / K index display in the lower right corner.
At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence;-) and it does fit many of the needs people describe here, in particular security and accessibility.
We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.
Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.
There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.
If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.
I'm pleased that so many of the principals involved in the Cubesat program have joined this discussion.
I didn't know that they CubeSat Kits were unrelated to the current activities, but more importantly, I want to apologize for omitting the 14th satellite, MEROPE from Montana State University. I want to thank Brian Larsen of MSU for pointing this out to me, and I hope Brian joins this discussion.
One thing I learned about all this activity around space, satellites, and its intersection with computer science and other technologies is that at least among people who are skilled enough in all those disciplines to get a satellite into orbit, amateur radio is still interesting.
Slashdot Mirror
At graflex.org we have used Microtek and Epson flat scanners. You do not need a drum scanner for your task.
You might try posting your question at there or on photo.net, or just reading the existing postings there.
And yes, you can still get 4x5 film. Try it out sometime!
>It's an impossible thing to accomplish (you can't even get an MP3 player for $100)
Huh? I just checked on eBay, "mp3 player," North America, Buy it Now and found tons of new MP3 players under $100.
In fact, this one caught my eye: "Palm Pilot Tungsten E PDA MP3" for $100.
It is pretty much the same thing as the OLPC proposal: if you consider that the Tungsten E is a couple of years old and the OLPC is expecting ~$150 next year and $100 in a couple of years, it looks reasonable. Probably about the same amount of memory within a factor of two or so, and about the same display cost (they're claiming cost reductions in display, but note that the OLPC display size is not that much bigger, maybe 4x).
So, take a run-of-the-mill PDA, add a keyboard, and make the display bigger, and that's pretty much it.
I really don't see why that's impossible, especially if they get orders for a million or so and get Quanta to make it.
You should read about the Y operator, or if you are an ACM member (why not, you have CS homework?), read Taming the Y Operator).
It looks like it's about 20:1 for actual responses, so I'll add mine.
I built an Elecraft K2 (more pix). Mine looks pretty much like the one in the picture.
A couple of weeks ago I went to Amsterdam and used it on Saturday and Sunday and got my radio to signal to Bulgaria, Russia, Italy, Montenegro, Poland, and England. (OK, some of these were also with another kit, a handheld KX1, but it's smaller and took only a weekend to build; more info, magazine article with more pix)
>Which would you rather validate, a set of CGI parameters or a blob of XML?
Um, a blob of XML. Quoting and escape characters are a big source of vulnerabilities. XML has well-defined quoting rules. CGI parameters have no structure, so structure must be done ad hoc. XML structure can be validated on the server using XML Schema or Relax, or other mechanisms.
The HTML Working Group recently decided to remove this mediatype constraint on text/html.
It was originally intended to make the XML / tagsoup distinction easier; instead it has emerged as a stumbling block.
I'm not sure what you mean by "select1" being an error; please let me know.
/>
/> :required, which you can style in CSS like this:
There are certainly efforts going on to bridge between HTML and XForms, so watch this space.
But if you're interested in binding a UI to XML data you already have, it's a best-fit solution.
Also, it's not clear that the size of XForms is any different from the size of large JavaScript solutions.
When you say
<submission id="update" replace="instance">
what happens is that when you put a submit button down with
<submit submission="update">
then it will submit the XML data in an HTTP POST with the XML MIME type, and the HTTP server will respond with another XML document. (See http://del.icio.us/leighklotz/xforms for a series of articles by Nicholas Chase at IBM DeveloperWorks on how to get PHP, Perl, Java etc. to do this.)
When the instance data is updated, either by the server response or by your using a UI control bound to one of the nodes, all data display changes are driven automatically.
For example, to implement COPPA, you just write one boolean expression that says this:
<bind nodeset="/application/personalInfo" relevant="/application/age >= 13"
then taht means that the entire tree of data under the <personalInfo> element won't be "relevant" if the age is under 13. Then the UI system follows this directive and will not display any UI controls bound to those nodes (presumably email, name, address, etc.). Likewise, the submission system follows the directive and won't submit them either.
Then, to fully simulate the COPPA experience, you can put
<bind nodeset="/application/personalInfo/email" required="true()"
which tells the submission system that email is required, so you can't submit without it. It also tells the UI system that it's required, and that gets shown as CSS property
input:required { color: red; }
Is this a good enough start of showing how XForms fits with XML and HTML and CSS?
Try AJAX with markup only, no hand-written JavaScript, by using the W3C's XForms standard. There are a number of implementations such as the Servlet-based Chiba (which fronts for Dojo and other packages), FormFaces written entirely in JavaScript (no server-side component), entire server-side pipeline systems such as Orbeon, and full client implementations such as the Mozilla/Firefox XForms Extension (just type "xforms" into your Firefox extensions finder), FormsPlayer IE Plugin, or cell-phone capable implementations such as PicoForms and SolidForms.
I wrote an entire webmail reader using PHP for the back end and XForms for the client. It runs in the Mozilla XForms implementation but could easily be made to work in any of the above, which differ mostly in how the CSS works. xmlmail
And for completness, I was an editor of an earlier version of the W3C XForms recommendation.
Your argument seems to be
I have tried this approach whenever my boss asks for a B-level schedule, and it still hasn't worked for me.
At $699 a pair for a custom size, they probably aren't even going to need venture funding!
It's FEATURE(`greet_pause',5000) not FEATURE(`great_pause',5000).
The previously-referenced Acme page mentions it.
Yah, I submitted it twice before that too, with this link and later this link. I guess I'm just too nerdy for slashdot.
According to CosmicBlog, the Marex webcam aboard the ISS is just getting operational, and has posted two images. You can view them at the marexmg site, or receive them directly over a radio or scanner hooked to a computer soundcard.
There are also toolkits and JavaScript apps that combine W3C standards with AJAX, letting you write a lot of the dynamic page stuff in a declarative fashion, using just markup (XHTML+XForms; I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms).
The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.
Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/ [sourceforge.net]
I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.
The Orbeon folks have a nice blog that shows how to use XForms (their implementation, the Mozilla extension, or any of the other above toolkits) to accomplish typical dynamic page tasks such as listing countries and ISO codes, or resizing flickr (also via formsplayer.
One good mechanism for getting the XML and asynchronous features but without hand coding JavaScript is to use any of the various XForms implementations. XForms is a W3C standard that defines a mostly script-free way of doing much of stuff people want out of Ajax, and it's done in a declarative way that's friendly to accessibility agents, and easier to deploy onto other devices. I was an editor of the XForms 1.0 recommendation, but new revisions have come out; see http://www.w3.org/TR/xforms
The FormFaces OSS product is an entire XForms implementation done in JavaScript, running in the browser. You write your page in HTML with XForms markup, and FormFaces does the "HiJax" thing of re-writing it for you. You never need to use XmlHttpRequest, and you can interact with regular servers, RESTful services, etc., all via XML.
Another product that does this, in a slightly different way, is AjaxForms. I just found out about it, but it looks pretty good. AjaxForms uses some server-side components to do the translation from strict XHTML+XForms markup into Ajax (HTML4+JavaScript), but they claim it can work in PHP and Tomcat servers. Again, FOSS, and available at http://ajaxforms.sourceforge.net/
I recently implemented dynamic forms for weblogs and wikis, and did it using Chiba, another FOSS product, that like AjaxForms does its conversion on the server, using Tomcat as a container.
Another important option is the work that the Mozilla Foundation and IBM are doing to make a native implementation of XForms as an XPI for Firefox and Mozilla. See http://www.mozilla.org/projects/xforms/ -- they're now in version 0.6, with 1.0 targeting full XForms 1.0 compliance. Like all other Mozilla extensions, it's a 1-click install, and I think it's about 200KB, so it's not very big, and I hope it gets added to the default build after it reaches 1.0. (It's presently built with the nightlies.)
There are a number of other implementations, including browser plugins (FormsPlayer for IE), native implementations for embedded devices such as cellphones and kiosks (PicoForms, SolidForms, and entire server-side systems using XForms, such as Orbeon Ops, so I see an increasingly bright future for using XForms to build dynamic HTML interfaces on top of XML web services and deploy them across a range of devices.
If I had a dime for every time I hit C-x C-s while writing a post...
You need XKeymacs.
Your point was that adding XForms to browsers breaks the entire web at theoretical level, in a way that's fixable only by chucking XForms and implementing something else instead, but I just demonstrated that was wrong. In both theory and practice, it's possible to add XForms support to a browser and not break the rendering of existing web pages.
t ml_can_save_internet_ex.html
So in response you say that IE doesn't implement XForms, a W3C standard, which is true, but true in a different way that's fixable: if IE implemented XForms (or if IE were more modular so that the formsplayer.com plugin was seamless), then it would be a done deal, and there's no theoretical problem.
Here's an interesting piece of opinion from Kurt Cagle, at O'Reilly, about how IE can move forward to XHTML and XForms.
It's based on some one-on-one discussions he had with top Microsoft developers.
http://www.oreillynet.com/xml/blog/2006/05/why_xh
Yes, you're right, we build on existing standards: XML, CSS, XPath, XML Schema data types...
As for your point about breaking existing content, it perplexes me that you keep making it.
But, let's try a test.
1. Visit http://www.microsoft.com/ in FireFox and note the results.
2. Install the XForms XPI from http://www.mozilla.org/projects/xforms and restart Firefox.
3. Visit http://www.microsoft.com/ again and see if adding XForms support to the browser breaks existing content.
Thanks!
Ian, we've had this discussion before so I don't expect to change your mind, but as for public references I'd cite these:
2 0040601.html#topic19.62 0040601.html#topic26.4 .NET objects."
http://www.w3.org/2004/04/webapps-cdf-ws/minutes-
followed by
http://www.w3.org/2004/04/webapps-cdf-ws/minutes-
where one individual said "For the basic stuff, other than XML specs for well-formed and verifiable standard XML, we decided not to use any existing standards, and we made a decision that our priority in the design would be support for direct mappings to
So I think this shows at least this one vendor prefers to do more of its innovation in new formats not based on standards.
Given the economics of their product base, it's hard to blame them.
Given the large investment required for IE compatibility (proper implementation of "quirks" mode, underspecified areas, bug compatibility, etc.), it's not surprising that vendors who have achieved it are reluctant to support anything that diminishes the value of that investment; again, from an economic standpoint, it's hard to argue with this. I won't cite specific examples from the same minutes, but you can surely find this sentiment there.
grasshoppa wrote: I never understood why web standards aren't maintained by the folks that actually are writing the browsers. Membership would require a browser with, say, x% market share.
I think (1) you have this, because any vendor who is a W3C member and has a product out there has credibility on many important issues and (2) you don't necessarily want just that: the establishment of standards can lower the barriers to entry, which would make for more browsers with smaller market share (and thus more diversity but better interoperability) and bring to consumers the benefits of competition for good implementation of the common ground, and "innovation" in the other areas. Unfortunately, if you limit membership to large existing vendors (your x% solution), you get members who want to shut out new products and innovation, and simply want to preserve the status quo (which is web terms is called "IE Bug Compatibility"), while the go off and "innovate" in other areas to try to make non-commodity products that they can charge for (InfoPath, XAML, just to pick on MSFT but there are other examples).
Disclaimer: I was editor of a W3C recommendation, but my opinions here are my own (duh).
Definitely XForms. It's a W3C standard and XForms 1.1 is about to be published, with feedback from existing implementations on interoperability and necessary features derived from real use cases. It wraps up a markup-based interface to many of the things people do with XMLHTTPRequest, and handles all the callbacks and stuff for you, and leverages other technologies for much of the work (XML for data, XPath for addressing the data, CSS for styling, XML/DOM Events for eventing, etc.)
With IBM's contribution of an XForms XPI to Mozilla, and an Opera implementation, we'd have a chance at a cross-platform mechanism for deploying web applications in a way that's good for device independence and accessibility.
And since this is slashdot, I should point out that I was one of the editors of the XForms 1.0 recommendation.
I would also like to point out that Opera Software wrote Opera, but the article doesn't mention that...
You can monitor solar activity from Firefox with the Propfire plugin.
It puts a tasteful text-based solar flux / A / K index display in the lower right corner.
...please check out the Mozilla XForms...
At my work, we've chosen the XForms route using Chiba for a recent product. It's not that surprising that I use it, because I was one of the editors of the 1.0 spec a long time ago, but it progressed even in my absence ;-) and it does fit many of the needs people describe here, in particular security and accessibility.
We write our dynamic markup in XHTML+XForms, following W3C standards (including nascent accessibility standards), and then use Chiba server-side in Tomcat to translate it into HTML4 and JavaScript. Chiba also offers a translation to HTML4 with a "refresh" button to initiate the dynamic activity via plain old HTTP, so it's fully accessible, though not as dynamic.
Longer term, please check out the Mozilla XForms XPI, which will take the XHTML+XForms markup directly. The browser does all its security stuff already, and it follows the IETF HTTP RFC and other W3C specs directly, so there's no need for funky workarounds or security lifting. The Firefox implementation is at rev 0.5 or 0.6 about now, and it's definitely usable, but when it gets to 1.0 it will be really great for dynamic behavior.
There are other implementations as well, FormFaces, which is written entirely in JavaScript and is way cool, FormsPlayer for IE, with lots of advanced features and which is a plugin, not a native implementation (as in the Firefox one); X-Smiles, the open source standalone implementation from Finland, SolidApp, another OSS one with paid support for small devices (mobile phone vendors look here), PicoForms, also for embedded apps but not OSS, Orbeon, a complete back-end server solution incorporating XForms and pipelines. I'm sure there's more major implementations I've missed, and also partial ones as well.
If you want to know more check out the XForms FAQ and XForms or HTML authors Part 1 and Part 2.
Plus, Will Wheaton likes it.
I'm pleased that so many of the principals involved in the Cubesat program have joined this discussion.
I didn't know that they CubeSat Kits were unrelated to the current activities, but more importantly, I want to apologize for omitting the 14th satellite, MEROPE from Montana State University. I want to thank Brian Larsen of MSU for pointing this out to me, and I hope Brian joins this discussion.
One thing I learned about all this activity around space, satellites, and its intersection with computer science and other technologies is that at least among people who are skilled enough in all those disciplines to get a satellite into orbit, amateur radio is still interesting.