For the last few days, I've been busy updating ProXist, my XProc abstraction layer and app for eXist. There is a new(-ish) XProc package for eXist that promises to support a lot of (Norm Walsh's XProc engine) Calabash's capabilities, so I decided it was time to test it out and do a new ProXist at the same time.
My XML Prague ProXist version supported only my custom document type and stylesheets, and barely those at that. It was meant to be a demo. For the new version, though, I'm thinking of doing a default implementation for DocBook, including some of the more commonly used stylesheets and a couple of standard pipelines, packaged so they can be used with ProXist--it should be a question of writing a ProX blueprint XML file, theoretically, plus something that helps me list DocBook resources included using XInclude.
At the same time, I'm finally updating the ProXist documentation. It's written using DocBook, incidentally, and now part of the git repository.
ProXist is not even close to being finished, but at least I seem to have moved on from procrastinating to actually doing something.
Saturday 25 October 2014
Monday 20 October 2014
I Guess I'll Have to Find Another Email App
About a year and a half ago, I bought Airmail to replace Apple's standard Mail app as my primary OS X email client. Not only was it miles above what Apple could offer, it was a bargain at $1.99. It was a no-brainer; I would gladly have paid more, considering its great feature set.
Lately, though, the Airmail updates have done little to fix the bugs I've encountered, from unread post counts not matching the actual numbers and poor threading of mailing list posts to annoyingly slow performance with large inboxes, etc. These annoyances haven't been enough for me to bother looking up another email client just yet, but that's mostly because I'm lazy and keep hoping that an update will eventually fix the problems.
So imagine how pleased I was earlier today, when I noticed that a version 2.0 of Airmail is available from the App Store. Finally!
Except then I spotted the price tag. The upgrade costs $19.99, and yes, that applies for customers both new and old. Although, for a limited time, you can get it at a special introductory price of $9.99.
WTF?
I feel cheated. It's not the money - a year and a half ago, I would have considered $19.99 to be more than reasonable - it's that they want to make me pay twice to get what essentially is an upgrade, the first more major upgrade since I bought version 1.0. See, they've reworked the app "from the ground up" and there's now a "faster engine", that is, they've finally addressed the performance issues and maybe more, but apparently they think they didn't charge their customers enough the first time around.
And what happens the next time they plan a bigger upgrade? What happens when they move to version 3.0? Do they expect me to pay for the damned thing again, a third time?
So, sorry but no; not only will I not be buying the 2.0, I will also uninstall the 1.0 and replace it with an email client developed by someone who isn't planning to rip me off.
Lately, though, the Airmail updates have done little to fix the bugs I've encountered, from unread post counts not matching the actual numbers and poor threading of mailing list posts to annoyingly slow performance with large inboxes, etc. These annoyances haven't been enough for me to bother looking up another email client just yet, but that's mostly because I'm lazy and keep hoping that an update will eventually fix the problems.
So imagine how pleased I was earlier today, when I noticed that a version 2.0 of Airmail is available from the App Store. Finally!
Except then I spotted the price tag. The upgrade costs $19.99, and yes, that applies for customers both new and old. Although, for a limited time, you can get it at a special introductory price of $9.99.
WTF?
I feel cheated. It's not the money - a year and a half ago, I would have considered $19.99 to be more than reasonable - it's that they want to make me pay twice to get what essentially is an upgrade, the first more major upgrade since I bought version 1.0. See, they've reworked the app "from the ground up" and there's now a "faster engine", that is, they've finally addressed the performance issues and maybe more, but apparently they think they didn't charge their customers enough the first time around.
And what happens the next time they plan a bigger upgrade? What happens when they move to version 3.0? Do they expect me to pay for the damned thing again, a third time?
So, sorry but no; not only will I not be buying the 2.0, I will also uninstall the 1.0 and replace it with an email client developed by someone who isn't planning to rip me off.
Sunday 19 October 2014
OS X Upgrade
I upgraded my MacBook Pro to the new OS X version, Yosemite, yesterday. Some observations:
- The new system font looks great. I'm really glad they finally realised how crappy the old one was.
- As expected, the upgraded zapped my rEFInd bootloader. I can no longer dual boot, so no more Ubuntu until I've rerun the rEFInd script. Unfortunately the word on the web is that the bootloader becomes awfully slow, so I think I'll wait.
- The new dock is sort of ugly and sort of old-fashioned. Didn't it use to look like this, a couple of versions ago?
- And speaking of looks, it all feels to me as something that might have happened if Apple had merged with ToysRus. Which isn't the case, as far as I know, so it probably means that the iOS camp at Apple is winning.
- I'm feeling a bit cheated because the Handoff features require a newer computer than my mid-2010 model. I would have loved to test them out.
Friday 17 October 2014
On Reflection
Having reread my recent post on HTML5, I suppose I'd better stress the fact that it was never meant to be a commentary on HTML5 itself. It was a rant, something that happened because of the attitudes I think have increased in tandem with HTML5's growing popularity. I really don't know enough HTML5 to have an informed opinion beyond what I see suggested and discussed about it that is related to markup in general. My comments should be read in that light.
Take the addition of document semantics in HTML5 as a case in point. For example, the article and section tags are welcomed additions, as are, in my humble opinion, the fairly minor redefinitions of the em and strong semantics. And there's some important work being done in the area of extensible semantics for the web (see, for example, Robin Berjon's XML Prague paper, Distributed Extensibility: Finally Done Right? and the Web Components web page on best practices), which turned out to be a heated topic at Balisage this year because quite a few of its participants are, like me, grumpy old men defending their own turf.
These are steps in the right direction, because they move away from the presentational horror that is the "old" HTML and to a more semantic web. Semantics is about meaning, and meaning is now being added to the web rather than simply empty but oh-so-cool visuals. I should add that some very cool visuals are being added, too, but in, and please pardon the joke, a meaningful way.
But, and maybe this is just me, it's when those steps are being heralded as original and unique, never thought of before or at least never done right, when history and past (and working) solutions are ignored or misinterpreted because they are part of a standard (XML or even SGML) that is regarded as failed, when I react. Google's Dominic Denicola provided a case in point when he held a controversial presentation on the subject called Non-Extensible Markup Language at Balisage; unfortunately, only the abstract seems to be available at their website.
That grumpy old men thing, above, is meant as a joke, of course, but I imagine there to be some truth in it. Part of the HTML5 crowd will certainly see it that way because they are trying to solve a very practical problem using a very pragmatic standard. HTML5 is, in part, about keeping old things working while adding new features, and it seems to do the job well. Having to listen to some older markup geeks argue about what XML was actually designed to do must seem to be as being utterly beside the point.
So, what to do? Well, I think it's largely about education, both for the newer guys to read up on the historical stuff, and the older guys to try to understand why HTML5 is happening the way it is, and then attempting to meet halfway because I'm pretty sure it will benefit both.
Me, I'm in the midst of the reading up phase, and HTML5 - The Missing Manual is an important part of that.
Take the addition of document semantics in HTML5 as a case in point. For example, the article and section tags are welcomed additions, as are, in my humble opinion, the fairly minor redefinitions of the em and strong semantics. And there's some important work being done in the area of extensible semantics for the web (see, for example, Robin Berjon's XML Prague paper, Distributed Extensibility: Finally Done Right? and the Web Components web page on best practices), which turned out to be a heated topic at Balisage this year because quite a few of its participants are, like me, grumpy old men defending their own turf.
These are steps in the right direction, because they move away from the presentational horror that is the "old" HTML and to a more semantic web. Semantics is about meaning, and meaning is now being added to the web rather than simply empty but oh-so-cool visuals. I should add that some very cool visuals are being added, too, but in, and please pardon the joke, a meaningful way.
But, and maybe this is just me, it's when those steps are being heralded as original and unique, never thought of before or at least never done right, when history and past (and working) solutions are ignored or misinterpreted because they are part of a standard (XML or even SGML) that is regarded as failed, when I react. Google's Dominic Denicola provided a case in point when he held a controversial presentation on the subject called Non-Extensible Markup Language at Balisage; unfortunately, only the abstract seems to be available at their website.
That grumpy old men thing, above, is meant as a joke, of course, but I imagine there to be some truth in it. Part of the HTML5 crowd will certainly see it that way because they are trying to solve a very practical problem using a very pragmatic standard. HTML5 is, in part, about keeping old things working while adding new features, and it seems to do the job well. Having to listen to some older markup geeks argue about what XML was actually designed to do must seem to be as being utterly beside the point.
So, what to do? Well, I think it's largely about education, both for the newer guys to read up on the historical stuff, and the older guys to try to understand why HTML5 is happening the way it is, and then attempting to meet halfway because I'm pretty sure it will benefit both.
Me, I'm in the midst of the reading up phase, and HTML5 - The Missing Manual is an important part of that.
Wednesday 15 October 2014
Reading Up On HTML5 - A Rant
I've been reading up on HTML5 lately, feeling that I should brush up my web development skills before I attempt an upgrade of a personal web page. Every other web page these days seems to be taking its design cues from some for me yet unknown source and I figured HTML5 is probably the place to look.
I've come across it before, of course, both in my day-to-day work and at markup conferences. We've been doing various web solutions and mobile apps involving HTML5 for some time now, and this year's Balisage, to pick the most recent markup conference I've attended, started with a one-day symposium on HTML5 which was both interesting and illuminating. There's a lot of it going on, right now.
And the other day, I came across HTML5 - The Missing Manual and have been reading it on and off since. It seems to be quite comprehensive and more or less what I need right now, but it is not a book primarily written for markup geeks. Don't get me wrong; it is well written, as are all of the Missing Manuals I've read, and it seems to do a reasonably good job explaining its subject.
But--and there's always a but, isn't there?--there's stuff in that book that makes me cringe. Or rather, it's not the book itself but what the book represents. See, the book seems to define that moment in time when I am no longer able to selectively ignore the HTML5 crowd.
There are a couple of terminology issues, of which the most annoying to me right now is that empty elements are apparently called void elements these days. This is not the author doing a reinterpretation of anything, this is the W3C working group talking--I just checked--but it is a symptom of what I am talking about here.
Another symptom, and one known to everyone who's done any web-related markup since the inception of the web, is how markup errors are frequently shrugged at. Nesting errors are the most glaring, of course, and the way they are ignored is to say that everybody does them but the browsers can all handle them, so while you may decide to be anal and actually validate your HTML, the message between the lines is that it's OK and you shouldn't worry about it since the browsers can handle it.
Coupled with this lax attitude towards draconian error handling (actually any error handling that is not related to browser-based limitations) in the book is the not-so-subtle hint that this is all the fault of the oh-so-obviously failed XHTML attempt from a few years back, when W3C tried to introduce XML syntax rather than fix HTML.
And there are the usual mentions of missing end tags (but no recognition of the fact that this was actually an SGML feature, once upon a time) and how that's really not such a bad thing after all because modern browsers can handle it, and the closely related ignorance towards empty (sorry, void) element syntax. It's OK, no need to be anal about it, because modern browsers can handle it. It's a question of style.
The HTML DOCTYPE declaration is explained, of course, and its lack of any kind of versioning indicators, SYSTEM or PUBLIC identifiers, etc, declared to be a good thing. Again, the motivations are browser-based and basically about doing it in this way because the browsers can handle it. The DOCTYPE declaration's existence is only important because of legacy reasons.
And the whole concept of well-formedness is explained as a matter of good style but really not much more than that (since yes, the browsers can handle it), and the benefit mainly the ability to include a couple of attributes in the root element.
And on and on it goes.
I don't mean to say that HTML5 is a bad set of standards--I know far too little about it to have an informed opinion--but much of the attitude I'm seeing in the wonderful world of HTML5, both now in this book and earlier in the various presentations and discussions I've witnessed or been a part of, seems both frivolous and dangerous. It seems to me to be a combination of reinventing the wheel and ignoring the lessons learned by others, and I can't help wondering what damage it will do to other markup technologies.
The Balisage symposium from earlier this year did give me hope--the people present were both smart and reasonable, more than willing to listen and learn from each other, and the discussion that ensued was informative and balanced--but most people do not go to Balisage, or any other markup conference, for that matter. They learn by doing, and some by reading, and quite a few sources now are like HTML5 - The Missing Manual, well written, comprehensive--and potentially dangerous to anyone with no experience of markup technologies outside their immediate needs, because they reinvent, reinterpret and redefine what they need and ignore everything else.
The result, I fear, is a more complex situation than ever in the world of markup, a situation where different sets of standards apply depending on the context and where XML, while sorely needed by some parts of the community, is ignored by others.
End of rant. Thanks for reading.
I've come across it before, of course, both in my day-to-day work and at markup conferences. We've been doing various web solutions and mobile apps involving HTML5 for some time now, and this year's Balisage, to pick the most recent markup conference I've attended, started with a one-day symposium on HTML5 which was both interesting and illuminating. There's a lot of it going on, right now.
And the other day, I came across HTML5 - The Missing Manual and have been reading it on and off since. It seems to be quite comprehensive and more or less what I need right now, but it is not a book primarily written for markup geeks. Don't get me wrong; it is well written, as are all of the Missing Manuals I've read, and it seems to do a reasonably good job explaining its subject.
But--and there's always a but, isn't there?--there's stuff in that book that makes me cringe. Or rather, it's not the book itself but what the book represents. See, the book seems to define that moment in time when I am no longer able to selectively ignore the HTML5 crowd.
There are a couple of terminology issues, of which the most annoying to me right now is that empty elements are apparently called void elements these days. This is not the author doing a reinterpretation of anything, this is the W3C working group talking--I just checked--but it is a symptom of what I am talking about here.
Another symptom, and one known to everyone who's done any web-related markup since the inception of the web, is how markup errors are frequently shrugged at. Nesting errors are the most glaring, of course, and the way they are ignored is to say that everybody does them but the browsers can all handle them, so while you may decide to be anal and actually validate your HTML, the message between the lines is that it's OK and you shouldn't worry about it since the browsers can handle it.
Coupled with this lax attitude towards draconian error handling (actually any error handling that is not related to browser-based limitations) in the book is the not-so-subtle hint that this is all the fault of the oh-so-obviously failed XHTML attempt from a few years back, when W3C tried to introduce XML syntax rather than fix HTML.
And there are the usual mentions of missing end tags (but no recognition of the fact that this was actually an SGML feature, once upon a time) and how that's really not such a bad thing after all because modern browsers can handle it, and the closely related ignorance towards empty (sorry, void) element syntax. It's OK, no need to be anal about it, because modern browsers can handle it. It's a question of style.
The HTML DOCTYPE declaration is explained, of course, and its lack of any kind of versioning indicators, SYSTEM or PUBLIC identifiers, etc, declared to be a good thing. Again, the motivations are browser-based and basically about doing it in this way because the browsers can handle it. The DOCTYPE declaration's existence is only important because of legacy reasons.
And the whole concept of well-formedness is explained as a matter of good style but really not much more than that (since yes, the browsers can handle it), and the benefit mainly the ability to include a couple of attributes in the root element.
And on and on it goes.
I don't mean to say that HTML5 is a bad set of standards--I know far too little about it to have an informed opinion--but much of the attitude I'm seeing in the wonderful world of HTML5, both now in this book and earlier in the various presentations and discussions I've witnessed or been a part of, seems both frivolous and dangerous. It seems to me to be a combination of reinventing the wheel and ignoring the lessons learned by others, and I can't help wondering what damage it will do to other markup technologies.
The Balisage symposium from earlier this year did give me hope--the people present were both smart and reasonable, more than willing to listen and learn from each other, and the discussion that ensued was informative and balanced--but most people do not go to Balisage, or any other markup conference, for that matter. They learn by doing, and some by reading, and quite a few sources now are like HTML5 - The Missing Manual, well written, comprehensive--and potentially dangerous to anyone with no experience of markup technologies outside their immediate needs, because they reinvent, reinterpret and redefine what they need and ignore everything else.
The result, I fear, is a more complex situation than ever in the world of markup, a situation where different sets of standards apply depending on the context and where XML, while sorely needed by some parts of the community, is ignored by others.
End of rant. Thanks for reading.
Tuesday 14 October 2014
Thursday 9 October 2014
I Should Probably...
Following this year's Balisage conference, I should probably do a rewrite and update of the whitepaper I presented. It's on my list of things to do.
On the other hand, I should do an eXist implementation of the version handling system I suggested in that paper. It's also on my list of things to do.
But then again, I still have to finish my ProXist implementation, the one I presented at XML Prague. It is (you guessed it) on my list.
I have lots of good (well, I think so) ideas first presented at XML conferences, many of which deserve (well, I think so) to live beyond them. After all, a lot of work goes into the papers and the presentations, so shouldn't I follow up on them more?
My version handling system, for example, should be easy enough to do in eXist. It doesn't require a revolution, it doesn't require me to learn how to code in Java, it should be enough to spend a couple of nights writing XQueries and XSLT to produce a usable first version.
ProXist is both simpler and more difficult to finish, but on the other hand, the basic application is already out there and works. It's a question of rewriting it to be easier for others to test, which basically means redoing it as a standard eXist app.
Yet, instead of doing something about either of them, here I am, writing this blog post. It's conference procrastination taken to yet another level.
And the next XML Prague deadline is coming up fast.
On the other hand, I should do an eXist implementation of the version handling system I suggested in that paper. It's also on my list of things to do.
But then again, I still have to finish my ProXist implementation, the one I presented at XML Prague. It is (you guessed it) on my list.
I have lots of good (well, I think so) ideas first presented at XML conferences, many of which deserve (well, I think so) to live beyond them. After all, a lot of work goes into the papers and the presentations, so shouldn't I follow up on them more?
My version handling system, for example, should be easy enough to do in eXist. It doesn't require a revolution, it doesn't require me to learn how to code in Java, it should be enough to spend a couple of nights writing XQueries and XSLT to produce a usable first version.
ProXist is both simpler and more difficult to finish, but on the other hand, the basic application is already out there and works. It's a question of rewriting it to be easier for others to test, which basically means redoing it as a standard eXist app.
Yet, instead of doing something about either of them, here I am, writing this blog post. It's conference procrastination taken to yet another level.
And the next XML Prague deadline is coming up fast.
Subscribe to:
Posts (Atom)