At Least I Can Walk To Work, Part 2

OK, I may have overreacted before. I was really pretty depressed there for a couple of days. I even started seriously considering buying a gun to have in the house "just in case". I think I've calmed down a bit. For one thing, I couldn't stay in that state without going literally mad.

As a counter to the depressing doomsaying of James Kunstler I found Peak Oil Debunked, which seems to be a reasonably thoughtful counter to the most extreme of the Peak Oil predictions. It cheered me up a bit, although I found a number of the arguments therein to be not entirely convincing or accurate-but-missing-the-point, especially as regards agriculture. Peak Oil Debunked (POD) isn't actually debunking the notion of peak, just trying to counter the most extreme doomsday prognosticating, which is good. POD isn't saying there is no peak, just that the results of it can't be as extreme as Kunstler and other Peak Oil doomsayers are predicting.

But it's hard to see how a serious contraction of resources, especially food (and by extension, capital for investment), isn't inevitable in the relatively short term. That can't play out well. Our current recession has to be a taste of what's to come--there just isn't going to be the level of energy input needed to pull us out the way WWII did for the Great Depression, so even if the contraction is slow it will still be a contraction and that will be hard on everyone who is even a little overextended or otherwise dependent on continued growth, which may be all of us, even those of us who have eliminated our debt and have a little cash set aside.

We're starting to see practical electric vehicles coming on line, but does that help if it keeps us from replacing the suburbs with more dense towns and villages? If we aren't building trains at the same time we're building wind farms, I fear we're missing the point. Why can't I take a 300kph train from Austin to Houston or Austin to Dallas?

On the other hand, it's going to be a long time before we can electrify air travel, barring some unexpected miracle in electricity storage density and planes can't run on coal, so I think we're not far away from seeing air travel severely curtailed. The answer to my train question is "because I can fly Austin to Dallas on SWA for $100.00"--what motivation does any private enterprise have in building that train and what motivation does the State of Texas have, given it's millions in the hole just now? None. But I think that economic picture has to change soon (within the next decade).

But in many ways Kunstler's arguments are about financial chaos as a side effect of inevitable contraction and that seems much scarier and more likely than simply running out of fuel for cars. We're already in a situation where credit is hard to get. It won't matter how many electric cars GM or Toyota builds if nobody can get a loan to buy them.

So I don't know. It seems likely that market forces will tend to reduce consumption as prices increase, mitigating at least the immediate effects of fall-off in supplies. As the Peak Oil Debunked blog points out, there is a lot of room for conservation in the U.S. For myself, I could almost entirely eliminate the use of my car for things like getting groceries, the pharmacy, going out to eat, as long as I was willing to eat the time cost. We live within walking distance of all the essential services we need. But Austin, like most U.S. cities, doesn't provide the level of public transport needed to make more far-flung trips convenient, must less pleasant. I could shave a couple of kWhs a day from my electricity use if I really had to. But my house is already very energy efficient so it would be about using less A/C and putting all the wall warts on switches and that sort of thing, stuff for which we currently have no economic incentive in the face of the inconvenience and discomfort. I'd rather just invest in more solar panels as long as I have the cash to do so.

Let's say oil supplies tighten significantly over the next two years and bus ridership goes up--Austin's transit agency is already in serious budget trouble and would have a hard time reacting to a surge in ridership (as they did in 2008). While we finally have a (largely pointless) light rail system, it would take a remarkable effort to put in a more comprehensive trolly or Portland-style light rail system in less than 5 years given public demand for it.

[I say our light rail system is pointless because it essentially serves one suburb of Austin, making it convenient for people who work downtown and live in Cedar Park to get to work. The train doesn't go anywhere else interesting and doesn't usefully serve anyone south of down town. Ridership has been a fraction of projections and of capacity. Small surprise. Now if there was a train that went from downtown to the airport and that came south to at least Ben White on Congress that would help a lot. I know of no plans along those lines.]

So is there anything actionable out of this new-found appreciation for peak oil and the inevitable contraction in our economy and life styles? Thanks to a recent inheritance I have some cash available. Should I buy a Volt? Expand my PV system? Buy gold? Put by a year's worth of rice and canned goods? Buy Treasury bonds? Fill my garage with machine tools? Buy a shotgun?

For now I think I'm going to take the following actions:

1. Put my name down on the list for the Chevy Volt. Austin is one of four launch cities.
2. Travel with my family as much as we can before air travel becomes a thing of the past for all but the richest humans.
3. Put in the rain water cistern we had to cut from our original house construction project (the rain capture plumbing is in place).
4. Think seriously about expanding the PV system, although I'm hesitant to do so too quickly as new PV technology is developing rapidly.
5. Avoid taking on any new debt--we are currently free of consumer debt and I'd like to keep it that way.
6. Continue to reduce our expectations, as a family, of what "enough" means, and try to teach my daughter that things are not what life is about.

I'm going to keep tracking opinion and bloviation in the Peak Oil space--it's entertaining if nothing else.

More as it develops....

Good Thing I Can Walk to Work

Given some of my colleagues in the XML community, I feel like I might be coming a little late to this party, but I just read James Howard Kunstler's The Long Emergency, a cogent and calm analysis of peak oil and an exploration of what that is likely to mean for the world as a whole and the U.S. in particular.

Kunstler's point is basically this: 100 years of cheap oil have allowed us to create a society of artificially inflated wealth, allowing us to overpopulate the Earth far beyond its normal carrying capacity (literally "eating oil" in the form of crops grown with artificial fertilizers, pesticides, and irrigated using water pumped by cheap oil), live in unsustainable suburbs and skyscrapers, and generally live far beyond our means. And this period of cheap oil is about to (and now, 6 years after the book was published, has) start ending, as we pass the "peak oil" point, the point at which the world supply of oil steadily decreases.

His prediction is that the decrease in supply will inevitably lead to a number of very serious problems, of which the most dire will simply be a lack of food--without cheap oil to irrigate, fertilize, and transport food people will starve. Lots of people. He makes the point that the world population at the start of the industrial revolution was about 1 billion people, which we can take to be the maximum solar carrying capacity of the earth. We're roughly 6 times that now. Not good. This can only lead to resource conflicts of the most serious kind.

Thus we are entering a time of contraction on all fronts: food supplies, energy for transportation, fuel for heating and industry, feedstocks for chemicals and plastics, etc. The reduction in real wealth will make it harder to maintain our current infrastructure and even build those things that might replace some of the lost oil (how do you raise the money to build wind farms or solar panel fabs when the growth-based economy has collapsed and the cost of everything is rising?).

In short, the 100-year period of constant growth in wealth is over, never to return. The disruptions will be severe and hard to predict.

All of this will be exacerbated by global warming (itself caused by coal and oil), which will further disrupt agriculture not to mention flooding coastal cities and, in the worst case, shutting down the gulf stream and freezing Europe.

Kunstler's arguments seem to be well grounded in fact and a clear historical context. Many of his facts were consistent with what I've read in other contexts. I didn't check his primary sources but he at least documented his key facts. He's not hysterical and does not appear to have any particular ideological axe to grind, other than clearly viewing all politicians as spineless and useless.

One part of the book that I found particularly striking was his remarkably accurate prediction of the financial meltdown that occurred in 2008.

He also makes the point that no alternative energy source is going to do much to help, certainly not in the short term (meaning the next few decades) for the simple reason that, even if we could generate all the electricity we needed with solar, wind, and nuclear, we can't replace our oil-based transportation system with an electricity-based one. Not to mention it's unlikely the U.S. would be willing or able to build enough nuclear plants fast enough. Hydrogen is patently nonsense and ethanol is a scam. If start rebuilding the train network now, we might avoid the worst, but we're not seeing any political movement in that direction (although Warren Buffet's investment in Union Pacific Santa Fe seems much more shrewd than it may have seemed at the time).

If he's anywhere close to right (and I think he is, or I wouldn't be mentioning it here), then we're in for some pretty serious disruptions in all aspects of society.

For information technology, one question becomes: where does the electricity come from to power the servers that we now depend on for our Google and Amazon and Bing? Not to mention the manufacturing facilities to build the computers themselves. Chip fabs cannot be scaled down to cottage industries.

I find it interesting that the trend in large-scale server farms has been to cite them in the Pacific Northwest where hydro power is plentiful. That could be to our advantage. Will the economy remain sufficiently intact to even have a need for the sort of abstract computing infrastructure we build and maintain? Will soaring transportation costs make computing that much more important?

I just returned from a week-long trip to Oxford, UK, which I found to be precisely the sort of small city Kunstler says we'll all have to live in before too long: dense, walkable, with good public transport, not too vertical. I walked and took the bus to get from my hotel to my client about 2 miles away. I ate in neighborhood restaurants, all quite good, no more than a few minutes' walk or a short bus ride away. Several of my colleagues did not own cars and several biked to work every day. The cars on the streets were significantly smaller, on average, than I'm used to here in the States.

When I got home to Austin I was struck by the almost cartoonish hugeness of the vehicles in the airport parking garage--they seemed to be almost exclusively the hugest SUV models made. Even when we drive our 15-year-old Explorer, which was the largest SUV Ford made at the time we bought it, we often lose it behind bigger monsters parked around it. Our Toyota, which would have been a large car in Oxford, was really hidden.

How many more overseas trips can I expect to take in my job? I didn't do anything that couldn't have been done well enough remotely, although being there physically made things more efficient and had significant social benefit.

Another question that immediately came to my mind is what can I do to really prepare for the sort of almost unthinkable change that Kunstler says is coming? I've already done a good bit by moving closer to the city center, building an energy-efficient house that supplies some of it's own electricity (and could supply more given an investment in more PV panels or a small wind generator). We raise chickens and grow a few vegetables and could grow a good bit more. There's land in the neighborhood on which a community garden could be based (could probably feed a good bit of the neighborhood with the open (and largely unused) areas on elementary school grounds just a couple of blocks away).

But what about natural gas? Kunstler points out something I hadn't known, which is that when natural gas wells tap out, they do so very quickly and without warning. And he claims most of our gas fields are already starting to play out. There's not much you can replace natural gas with. Could I build a digester and produce enough methane from chicken poop? Where would I get the grain to feed the chickens to make the poop? Right now we get organic grain from a mill here in Texas, but before that mill opened, we got it from a mill somewhere quite far away (Kansas? Pennsylvania? I don't remember now). Seems unlikely I could produce enough to keep my on-demand water heater running, much less run the stove or the furnace.

Here in Austin we're reasonably well situated--we have relatively warm winters, good solar exposure, water from lakes (not the Ogalalla aquifer), decent agricultural land, and less sprawl than most other cities in Texas. But would that be enough? I don't know. Austin was the edge of the frontier when it was first settled in the 1830s. It could be again.

It would be hard for us to survive full summer heat without air conditioning, even with the passive solar aspects of our house, although our PV system was designed in part to cover the daytime load of the A/C system, so maybe we would be OK there. With an electric car we could get around as long as there was sun to charge it. And we can walk or bike to most of what we need. (Should I get on the list for a Volt--Austin will be a launch city. I'm seriously thinking about it since I do now have the cash to buy one.)

In any case, the book is a real eye-opener.

If there is any silver lining to all this it seems pretty clear that a lot of current issues like over-dependence on corn-based food, globalization's homogenizing and dislocating effects, over-sedentary, over-fed first-worlders, will go away pretty quick. But I can't seen those changes being necessarily pleasant or welcomed by the majority. I'm glad I'm handy with tools and subscribe to Make. I'm thinking that maybe having a milling machine and a metal lathe in the garage might be good moves.

My father grew up on a pear and apple ranch in the Hood River valley of Oregon. We visited there recently and I got to talk to the woman who now runs the ranch (the granddaughter of the man who founded the ranch back in the early 20's, just as oil-based agriculture was coming into its own). We talked about globalization of agriculture and the local food movement and such.

She pointed out that their ranch, which is small by Hood River valley standards, produces as many pears as the state of Oregon consumes in a year. Most of the pears they grow are sold overseas. If they didn't have access to those markets, where would they sell? It's hard to see that ranch (or the Hood River Valley or the Yakama Valley) being viable in their current forms for much longer.

So enjoy those pears and $3.00 a pound Yakama cherries while you can. I know I am.

My Precious: iPad Day 1

I bought an iPad at 9:30 am CDT 3 April 2010. I had to.

My nominal justification was to see if it would work for my dad. It absolutely will.

But really I just couldn't not have one.

Here are my initial impressions:

-typing is remarkably efficient. I am writing this on the iPad sitting in a comfy chair, pad in my lap (put it on a pillow after a while so cord would reach--battery finally running down). I am a fast touch typist and I can sort of touch type but really it's just fast hunt and peck. But I don't feel like it's slowing me down. I do miss arrow keys--finding navigating around in a multiline edit field a bit tedious.

- the response is very fast. Web pages load fast, apps load fast. Not like an iPhone at all.

- web browsing has full computer feel. Have not yet gone to site that didn't seem to work in safari (flash sites excepted of course)

- so far everything has just worked, which is a lot of the point of all apple products

- the only potential issue so far has been the volume indicator wouldn't go away watching some YouTube videos but it hasn't recurred

- everyone who sees it wants one. Badly.

- netflix app worked well. Punched up Willy Wonka and it played very nicely

- The Elements interactive book is a pretty amazing demonstration of what the device can mean for instruction and reference.

- I downloaded all the free newspaper apps I could find and they all provided a very satisfying reading experience. One of e things i was looking for was that Dave-Bowman-reading-the-paper-on-his-tablet-over-breakfast experience and i think we have it. Will definitely consider a NYT subscription--we get the Sunday times and usually buy the Tuesday edition. So $4.00 a month for full access would be reasonable.

- iBooks seemed to work pretty well although I'd really like to be able to add my own epub books to it. Not sure if there's a way to do that in iTunes.

- upgraded to plants vs zombies HD and have been having a hard time dragging the device away from my daughter (age 6). She also likes the drawing apps.

- mail working pretty well, but not that different from iPhone experience except for more screen space and easier typing

- battery life seems as advertised ran all day on a charge including video, lots of PvZ playing, and weak wifi signals

It definitely meets the pick it up and carry it everywhere requirement, which raises several practical issues:

- will I ever be able to put it down? There's a serious danger of always having it to hand which means always reading something or playing a game or whatever.

- where will I set it down? We have concrete floors so you want to set it in a relatively safe place, of which we have few

- how do you keep it from being stolen?

So far I can say without reservations that it has exceeded my fairly high expectations after a day of use.

Cory Doctorow has made an eloquent and principled argument against the iPad as being a closed system that is counter to the basic concept of freedom and access the Internet represents. I agree with Cory in principal. I have spent my entire career championing standards specifically because they protect against proprietary control and lock in. Yet I have a MacBook and an iPhone and now an iPad and would not part with them. Why? Because they fricken work. They are solid and beautiful and reliable. Even though Cory is right it doesn't matter because there are very few of us who can trade reliability for openness.

If Google can build a software and hardware platform comparable to the iPad then I'm there. But so far not even Microsoft much less the open source world has succeeded in building a device (since WebTV) that I would put in father's hands. Even my mother, who is quite computer savvy, has just traded in her dell for a Mac.

At the same time, the content standards my clients depend on are all well supported: epub for ebooks, HTML for web delivery, PDF for page fidelity. Lack of flash is an annoyance but not a deal killer since nobody should be depending on flash exclusively anyway.

There is the question of whether the App Store as Apple manages it is draconian or a necessary evil in order to have a system safe for unsupervised use by children. I'm sure I can form a useful opinion without a lot more thought. I'm not one for censoring children's access to information in general once they are old enough to understand what they might be finding, but 6 is not yet that age.

Need a WebTV Replacement

Some years ago now I set my father up with WebTV. It met his needs perfectly: it gave him email and Web access from his TV (he spends most of his time in front of his TV), it was reliable, it didn't require him to learn how to use a computer generally, and it didn't require any support from me (my father is in Tacoma, Washington and I'm in Austin, Texas, so I can't just pop over to provide hands-on support).

My father is not tech savy--he used a manual typewriter to produce a club newsletter for years until the club finally forced him to upgrade to an electric typewriter. He refuses to carry a mobile phone or use ATMs. You get the idea. However, he depends on email and e-bay so he has to have some sort of Internet access.

Unfortunately, while Microsoft has not completely abandoned WebTV, they have not enhanced it in years and clearly have no intention of doing so--you can't even download the emulator they used to provide.

The problem for my father is that WebTV is simply no longer up to the task of supporting modern Web sites and it's becoming harder and harder for him to use e-bay and other Web sites, like Amazon or Flicker. And forget about Facebook.

My quandry is what to replace WebTV with. So far I haven't been able to identify any obvious good solutions. The Wii's Web browser is close but it's still pretty clunky--even with a keyboard I don't think it would be reliable or simple enough for my dad--it requires a lot of wimote fiddling to scroll and pan around Web sites that don't fit nicely on a screen.

AppleTV would seem likely except that it doesn't come out of the box with a Web browser and I'm not going to support a hack that adds one.

A Mac mini might serve, but that gets us into the having a full computer problem, and I'm not sure my dad's TV takes HDMI input (I need to find out about that).

It seems like the new tablets that are all the buzz of the gadget world might serve, especially the rumored Apple tablet, but I'm not sure my dad would be willing to drop a grand on it, and I'm not keen to have him be an early adopter.

But I feel like I'm missing some obvious technology choice. Anyone out there have any thoughts about how to provide a TV-connected Web browser that is easy to use, works reliably, and will work with modern Web sites?

PDF2 Transform Now Enabled for Plugin-Based Extension

In the latest 1.5 Toolkit distributions, the PDF2 transform has been enabled for plugin-based extension. This means that you can use normal plugin techniques to provide extensions to the PDF processing that support specializations or global overrides, rather than customizations for specific publication sets or book designs.

As originally implemented, the PDF2 processor could only be extended through its unique Customization facility, whereby you either add things to its built-in Customization directory or create copies of that directory and then specify where the Customization directory is as a parameter to the transform. This is appropriate for customizations that are not global, that is, they are specific to particular publications, sets of publications, products, or whatever.

It is not appropriate, however, for providing general extensions, such as support for new domains where the domain-specific processing would normally be the same in all outputs or where the base processing is the same but can be customized using the normal PDF2 customization facilities.

In the latest DITA 1.5 Toolkit, you can now have both plugin-provided extensions as well as Customization-based extensions. This makes it easy to provide generic PDF2 support for specializations or provide global overrides for existing topic and map types.

A PDF2-extending plugin can provide only overrides, or only a Customization directory or both.

For example, for DITA for Publishers, I've started implementing support for the Publication Map (pubmap) map domain, which is similar to bookmap but tailored for Publishers. To support the PDF2 transform, I've created a plugin that provides both general extensions and a base Customization directory that can be used as a basis for local customizations.

The directory structure of the plugin is:

net.dita4publishers.pubmap.fo/
  Customization/
  xsl/
  plugin.xml

Where the Customization/ directory follows the rules and conventions for the PDF2 Customization directories and xsl/ holds the plugin-provided XSLTs that extend the base PDF2 processing.

The plugin.xml file looks like this:

<plugin id="net.sourceforge.dita4publishers.pubmap.fo">
  <require plugin="net.sourceforge.dita4publishers.formatting-d.fo"/> 
  <require plugin="net.sourceforge.dita4publishers.pubContent-d.fo"/> 
  <require plugin="net.sourceforge.dita4publishers.xml-d.fo"/> 
  <feature extension="dita.xsl.xslfo"
      value="xsl/pubmap2xslfo.xsl" type="file"/>      
</plugin>

The elements are indicating dependencies on other PDF2-extending plugins for the different domains that DITA For Publishers provides.

The line is what integrates the XSLTs into the main PDF2 XSLT transforms and it works just as for the HTML plugins, namely, the integrator.xml Ant tasks adds an xsl:include of the plugin-provided XSLT module into the main PDF2 transform shell XSLT.

One thing that plugin-provided PDF2 transforms can do is define additional customization points: named attribute sets, named variables, and new XSLT modes, which can then be customized using the normal PDF2 customization mechanisms.

In the case of the pubmap extensions, I've extended the XSLT so that publication maps produce the same output as bookmaps (that is, a pubmap-d/chapter topicref goes through the same base processing as a bookmap/chapter topicref) and added support for DITA for Publishers-specific topic types, in particular, sidebar, which gets a box around it by default (XSL-FO 1.1 can't render multi-page floats, which would be the ideal way to render sidebars).

This enhancement to the PDF2 processor, along with the many other improvements made by the Suite Solutions team, makes it much easier to extend and customize the processor and, in particular, support new domains and topic types. The Customization process is as it was, but now you only need to use XSLT in your customization when you need truly customization-specific processing (for example, generating a publication-specific title page or copyright page).

Why DITA Requires Topic IDs (And Why Their Values Don't Matter)

The DITA standard requires all topics to have an id= attribute.

Why?

The reason is simple: so you can point to elements within topics. And for
no other reason.

Surprised?

Most people seem to assume that topics are required to have IDs so you can
point to the topics. And they further seem to assume that topic IDs need to
be unique within some fairly wide scope (e.g., within their local topic
repository).

But that's not the case at all.

For the case of topics that are the root elements of their containing XML
documents and that contain no elements that themselves have IDs, the topic
ID isn't needed at all. In this case the topic can be unambiguously
addressed by the location of the containing XML document (e.g.,
"mytopic.xml").

In the case of topics that are not root elements and that are not themselves
pointed to and that do not contain any elements with IDs, again the ID is
not needed (because nothing points at the topic or its elements).

So why does the DITA standard require topics to have IDs?

It is because topics establish the addressing scope for their
direct-descendant non-topic elements.

By the DITA spec, to point to an element that is not a topic you use a
two-part pointer: {topicid}/{elementid}.

Without a topic ID it would be impossible to point to a non-topic element.

By requiring all topics to have some ID, it ensures that any non-topic
elements with IDs are immediately addressable without the need to also add
an ID to their containing topic.

In general by normal DITA practice, non-topic elements are given IDs only
when they are intended to be either used by conref or be the target of a
cross reference. Both of these tend to be carefully considered decisions
driven by editorial and business rules, not arbitrary author decision. Which
means you would tend to know, in advance of creation of a given element,
that it is a candidate for conref use or xref use, which means you know to
give it an ID at the time you create it.

By requiring that topics always have IDs it means that authors don't have to
worry about adding IDs to topics just because they also happened to put an
ID on an element. [In normal XML practice, elements are addressed directly
by ID within their containing document, which means it is sufficient to
simply put an ID on the element with no other dependencies. That is not the
case in DITA, which defines its own unique syntax for non-topic element
addressing.]

Because topic IDs are XML IDs (as opposed to non-topic-element IDs, which
are just name tokens and have no special XML-defined rules), any XML editor
will both require topics to have IDs and ensure that topic IDs are unique
within the scope of their containing document.

If topic IDs were not required, DITA-aware editors would have to have
special rules to know to require topic IDs whenever non-topic elements got
IDs and it would mean that generic XML editors would not ensure that this
important DITA rule was met (topics with elements with IDs must themselves
have IDs).

So the DITA spec requires that all topics have IDs.

But the fact that topics must have IDs does not imply that topic IDs need to
be either descriptive or unique within any scope wider than the XML
documents that contain them.

In the case where every topic is the root of its own document, the topic ID
can be the same *for every topic*. To make this point I have standard
practice of using the value "topicid" for the IDs of all my root topics.
There is absolutely no need to generate unique topic IDs for document-root
topics as a matter of standard practice.

The only other case is ditabase documents.

If you are using ditabase documents, stop.

Sorry.

There are some legitimate uses of ditabase documents, for example, as a
first-pass target for data conversions and as a way to hold otherwise
unrelated topics that need to be managed as a single unit of storage, such
as topics that exist only to hold reusable elements.

[NOTE: Using ditabase simply to allow the mixing of different topic types in
a single document during authoring* is the wrong thing to do. You should
have already created local shell DTDs and within those shells you can allow
whatever topic type mixing is appropriate for your local environment. There
is no need to use ditabase in that case and many reasons not to. See my many
other posts about why you should always create local shell DTDs as the first
step in setting up a production use of DITA.]

In that case, the topic IDs must be unique within the scope of the ditabase
element, simply because XML rules demand it. But the IDs need not be unique
beyond that scope and they need not be meaningful.

One of the implications of this is that if you always edit topics as
individual documents and never have nested topics you never have to think
about topic IDs. Your topic document template should already have an ID
value and it can be something like "topicid" and there is no reason
whatsoever for that ID to ever be changed.

In the case where you do edit topics with nested topics (for example, you're
authoring more or less narrative documents or you've designed some topics
types that need nested topics to allow a bit of hierarchy where the nested
topics would never be meaningful in isolation) then you either have to
configure your editor to assign IDs to the nested topics for you (if your
document template doesn't already have the subtopics with IDs assigned) or
you have to think about it. But even in that case, the IDs can be pretty
generic, e.g. "st1", "st2", etc. The IDs in that case still don't need to be
unique beyond the scope of the containing document.

Help Me Learn: How to Design a Solar Charging CIrcuit

I have an general interest in sustainable power systems (my home has a 5-star rating and a 3Kw PV system) but I am not an electrical engineer and have no useful understanding of electrical circuit design beyond very basic stuff (I know what a resister is but I couldn't reliably tell you how resistance relates to current and voltage).

I have two projects in mind that I'd like to pursue, both of which require a bit more knowledge than I have and I have no idea where to go to get the knowledge--all of my resources are focused on small-scale electronics (digital circuits, basic occilators, etc.).

My first project is to create a water feature that is variously powered by wind, solar, humans, etc. where all the different power sources contribute to charging a storage system which then drives an electrically-powered pump of some sort. I'm thinking of something like a 6-volt marine battery, something that can hold a good charge and produce enough current to drive a beefy motor.

What I don't know is how to design a charging circuit that will feed the battery from multiple input sources.

The other project I'm thinking about is modifying an RV to be electrically driven so that it could be, as much as possible, solar powered (e.g., for traveling about the American West during summer). That is, building an electric RV that would run off batteries for cruising and be recharged by a combination of solar, auxiliary generator (presumably a diesel engine that could run on waste vegetable oil or the most ecologically sound fuel available at the moment), or grid connection when parked.

It would need to enable a 200- to 300-mile range on a single charge to account for the (almost) worst case where you have no solar input and must recharge overnight from a campground. The worst case is no solar input and no grid access, so you'd have to run the generator in order to get to the nearest power source (or wait out the clouds without your beer getting too warm).

Some obvious questions are:

- Assuming an Airstream RV (chosen to minimize drag, even though they're frightfully expensive), how much energy would be required to provide a 200-mile range at 55 MPH?

- Assuming a more affordable typical RV, what would the cost from drag be?

- Given current solar panel technology, what output could be expected from the maximum area one could reasonably attach to an Airstream? Would it make sense to include some sort of fold-out panel system for use when parked (e.g., you're stopped for the afternoon at some tourist spot)?

- Assuming worst case of no solar input and no access to the grid, what size of generator would be needed to enable direct operation of the vehicle at say 40 MPH?

All of this would go to answering the first question, which is "is this even practical with today's generally-available and affordable technology?" If the answer to that is "no", then what advances would be required to make it affordable?

We could start with the presumption of a 50,000 USD budget, which is about what it costs to buy a full-sized conventional RV. So if I bought a used one and refit it, could that even be done for that budget?

Another consideration is the value of not buying fuel. With gasoline pushing 4.00USD a gallon and diesel already over that as of May 2008, a 3000-mile trip at say 8 MPG starts to add up pretty fast. That's roughly 1500 USD in fuel costs for that trip. At 4 dollars a gallon, I can recoup 15,000 USD in investment in 10 years of driving vacations. If fuel was at European rates that payback would of course be much higher (and it seems reasonable to expect that U.S. fuel will climb to approach European rates over the next 10 years simply because of both market pressures and increasing social acceptance of the true cost of our life styles in the face of global warming).

So I'm wondering if anyone can provide pointers to resources, online or otherwise, where I could start developing the necessary knowledge to start answering these questions?

I don't think any of this is particularly challenging from either a design or implementation aspect, I just have no idea how to go about learning about it efficiently....

Choosing an XML Schema: DocBook or DITA?

Richard Hamilton has presented a thoughtful analysis of when to choose DocBook or DITA, published on the Content Wrangler blog here: http://www.thecontentwrangler.com/article_comments/ choosing_an_xml_schema_docbook_or_dita/

I started to post the following as a comment to that post but it got long enough that I thought it better to post my full response here.

I generally agree with Richard's analysis as far as it goes, but I think it misses several important points that I assert tip the scales significantly in favor of DITA over DocBook.

If you are looking for a documentation schema that you can just pick up and use and you don't need the modularity features of DITA (that is, you don't need the functionality of DITA maps) then DocBook probably makes the most sense for the reasons Richard cites, namely that there are more element types of likely utility out of the box and the processing infrastructure is more mature and better documented.

However, if you know you need to add markup for your specific requirements or are developing a new XML application where things like markup tailored for local users or requirements is important or modularity is important, then DITA has a very clear advantage because it is so much easier to develop and extend custom document types from a DITA base than from a DocBook base.

The reason is very simple: DITA's specialization mechanism, coupled with the declaration set design patterns defined by the DITA architecture, make it as easy as it could possibly be to develop new markup structures. In particular, having defined specializations you may need to do nothing more in order to have documents that use those new types work with existing DITA processors, editors, CMS systems, etc.

DocBook cannot have this characteristic until such time as it either adopts the DITA specialization mechanism (which it could easily do--I worked hard to have the specialization aspects of DITA defined as distinct from the DITA element types specifically so that it could be adopted by other XML applications with a minimum of fuss) or adds the equivalent functionality using some other syntax [one limitation in the current DITA specialization mechanism is no good way to support namespaced elements--that will be fixed in DITA 2.0 but nobody has yet started to work in earnest on what that might be--this could be an opportunity for DocBook to take the lead since DocBook definitely has a namespace requirement.]

With any DocBook application, if you define new element types, there is no defined way to map those back to existing types and DocBook processors are not designed to handle new types by processing them in terms of some base type. That means that if you define new element types in a DocBook context you must update all processors that need to act with those documents even if all they need to do is nothing with those elements.

On the subject of narrative documents, there is essentially no practical difference between DITA and DocBook in their ability to support the creation of single-instance documents of arbitrary depth. This is obvious for DocBook (because that's what it was designed for), not so obvious for DITA (because it was designed for the opposite).

But with DITA all you need to do is configure your local doctypes ("shells" in DITA parlance) to allow topics to nest. For example, the simplest case is to simply allow generic topic to test. With that you can represent any possible narrative document structurally.

The only meaningful difference in this scenario between DITA and DocBook is that DITA requires the body of a section to be wrapped in a container (the topic body), while DocBook does not provide such a container (or at least it didn't last time I looked).

This is really a trivial difference.

For several clients who are doing publishing rather than technical documentation I have developed essentially trivial specializations that provide generic topics distinguished only by their topic type names but using otherwise generic DITA elements for content. I usually define a specialized topic called "subsection" that can nest to any depth. With that model you can represent documents as well as or better than you can with DocBook and you get all the other DITA goodness as well.

Finally, there is a free DITA-to-DocBook transform that is part of the free DITA Open Toolkit that allows you to use all the DocBook processing infrastructure with DITA-based content. This is used, for example, to use non-DITA-aware composition systems like XPP with DITA-based content.

Because DITA offers a number of very important features that DocBook does not, in particular specialization, modularity, and external links (relationship tables), and because DITA can be configured to work as well for non-modular documents as DocBook can, and because DITA lowers the cost of developing new element types as low as it could possibly be, I've come to the conclusion that DITA is the best answer for any XML-based document-centric application I've seen.

Just the fact you can get OxygenXML for almost nothing, define a completely new DITA specialization, deploy it to your local Toolkit as a plugin (a very easy operation once you know what to do, something I need to write a tutorial for), you can then edit documents using that specialization in a full-featured graphical, tags off editor with no additional work of any sort is pretty powerful. DocBook simply cannot enable that because it doesn't have DITA's specialization feature.

If DocBook adopted DITA's specialization mechanisms then this discussion wouldn't even be meaningful because DocBook would get all the value that specialization accrues to DITA and would still have the value of being a conceptually simpler model for documents.

Which raises the question: why doesn't DocBook simply adopt DITA's specialization mechanism? It would cost DocBook almost nothing to add and add tremendous value. It would not require DocBook changing anything about its current markup design, except to possibly back-form some base types that are currently not explicit in DocBook but would be useful as a specialization base. But that would only make DocBook cleaner.

XML is 10

The XML Recommendation is celebrating its 10-year anniversary, that is, the anniversary of the official publication of the Recommendation on 10 February 1998. However I think of XML as really starting in 1996, when the activity was revealed publicly for the first time at the SGML 2006 conference. I wrote about XML and its development at that anniversary here: Dr. Macro's XML Rants: XML: Ten Year Aniversary (And I discovered this post, which I had totally forgotten about, when I googled "sgml 1996 conference" in order to verify that my memory of the dates was correct. How sad is that? [or conversely, how cool is that?--you choose.]).

I will re-iterate what I said two years ago: while Tim Bray and Michael Sperberg-McQueen, as the editors of the XML 1.0 Recommendation, are most publicly associated with the XML it was Jon Bosak who made XML happen. It was Jon who put the "SGML on the Web" working group together, personally invited all the initial members, set the working rules that allowed us to work quickly and productively, and managed the political and procedural process of getting XML through the W3C. Jon knew what he wanted and knew the ingredients that were needed and knew how to put them together in a way that would most likely produce the desired result. In that sense he was like a chef producing a dish dependent on the complex interactions of different ingredients, a dish that is not a simple assembly task but one that involves carefully managed reactions and cooking times applied to a variety of ingredients where quality was a key determining factor.

Without Jon's drive, judgment, and leadership, the XML development process could have easily bogged down or been derailed in any number of ways. It would have taken only one spoiler or resistance from inside the W3C or simple poor management of the process to kill or delay the whole thing.

It's also important to remember that what we developed as XML represents absolutely no technical innovation. There is nothing in the XML 1 Recommendation that isn't in SGML, with the possible exception of well-formedness being sufficient (since SGML required the use of DTDs with document instances). The genius of XML, and the challenge in developing the spec, was figuring out what to leave out of XML. Each of us on the Working Group had our pet features, without which we felt XML would be at best crippled, at worst useless. I think we did a remarkably good job of not including features that were not essential.

In retrospect, I wish we had gone farther and left out DTDs and entities entirely, but of course that would not have been politically acceptable at the time and there would have been nothing to replace DTDs with (in fact, I still find it amazing that the XSD spec was ever finished given the challenge inherent in developing that specification given the wide range of requirements and constituencies driving it).

I think it's also fair to say that XML has succeeded far beyond any of our initial expectations. All we really wanted was a way to publish SGML data using Web technology. It never occurred to us that it would be embraced as a general-purpose data structuring and program-to-program communication format (for good or ill). I've always found it a little annoying that the vast majority of data using XML has nothing or little to do with documents in the sense of information intended primarily for human consumption. Whatever.

I suppose prognostication is expected at this point.

Where do I see XML going in the next 10 years?

I think it's fair to say that XML is entrenched and unlikely to be replaced any time soon. It's hard to imagine that any group would have the motivation and resources to build a general-purpose XML alternative given XML works more than well enough for most of the applications to which it is put. From an engineering standpoint, it would be a case of overoptimization.

In the domain of structured documentation I think that the DITA standard in particular will accelerate the adoption of XML for docment representation. The values have been well understood for decades and they aren't going to change. Because DITA, leveraging XML's deep and ubiquitous infrastructure, lowers the cost of entry of using XML for sophisticated document representation it can only serve to bring more enterprises and users to XML, users for whom in the past an SGML or even XML solution would have been prohibitively expensive. I find that very exciting. I don't remember well enough to know if that particular effect of XML was envisioned or even hoped for, but I think we all, even at that time, understood to some degree the power that Web technology had in general to make things easier and cheaper. But certainly lowering the cost of building XML parsers was a primary design driver, our mythical "graduate student with a weekend" to build a parser. That vision has definitely been realized.

In the domain of program-to-program communication it would not surprise me if something specifically designed for that task supplants XML, something like JSON. This is a domain where, because there is no particular great body of data, but only processing code, APIs, and support libraries, the engineering equation would make optimization more attractive: there's no question that XML is not the best solution for character-based serialization of arbitrary objects and data structures. I certainly wouldn't object to proposals to replace XML with JSON for those applications. The key is to understand that XML is still the best available solution for persistent data. I think a lot of people who use XML day to day forget (or never were told) that XML, via SGML, was originally designed to facilitate search and long-term, application-independent archiving of data. It is almost coincidence that makes that same application-independence useful for communication of transient data. Convenient but not optimal.

I fully expect to be able to do more or less what I'm doing now ten or twenty years from now. Whether I will be is another question, but so far, just when I thought I was completely bored of it, something new in the XML world has come along to re-energize my interest. And we're still struggling to build truly useful XML-aware hyperdocument management systems. Hopefully that won't be the case in 2018.

And lets not forget Dr. Charles Goldfarb, who's own singleminded passion, drive, and leadership produced SGML, without which XML (and HTML, for that matter) would never have happened. SGML turned 20 in 2006. It's largely now forgotten except by a few early adopters who have been using their SGML-based systems productively for ten or fifteen years now and had no compelling business reason to move to XML. But I remember.

Kids today....

FASB ASC U.S. GAAP DITA Application Is Live

[How many initialisms can I get in one post title?]

For the last year or so I've been working as part of a larger team at the Financial Accounting Standards Board (FASB), helping with the implementation of a DITA-based system to support authoring and delivery of the newly-codified U.S. Generally Accepted Accounting Principles (GAAP), the Accounting Stanards Codification (ASC).

I contributed design of the DITA topic and map specializations used for the codified content and also implemented automated data conversion from an earlier XML format used in the initial codification editorial process.

The live Web site is here: http://asc.fasb.org/home

I've posted some details about the project on the Really Strategies blog: http://blog.reallysi.com/2008/01/live-dita-appli.html

Update: I should have mentioned (but wasn't 100% sure of the details) that the CMS system was built on the empolis e:CLS product and the Web delivery platform uses the empolis e:IAS search platform. The empolis Web site is www.empolis.com. I was not personally involved with that aspect of the system and was not involved with FASB's technology selection process (I was brought onto the project after they had selected their core techology). The system integration and development work was done by Ovitas, empolis' chief North American integrator.

I For One Welcome Our Cleaning Robot Overlords

As long as they keep the house clean.

My main gift this holiday season was a new Roomba 560 floor cleaning robot. This brings the cleaning robot population of Chez Kimber/Woods to 3, including our original Roomba 300 series and the Scooba.

I wanted the new Roomba because I found that, with a two-story house, it was just inconvenient enough to move the one roomba between floors that I was less likely to go to the trouble to run it at all. We also found that the 300 series couldn't really deal with the area rug in our livingroom (we have concrete floors with one big run in the livingroom) and that the noise of running it on the concrete floors was just a little too annoying. So in short, the robot was underused and the house tended to be not as clean as we would like (but couldn't actually be bothered to clean ourselves, not being what you would call obsessive house cleaners).

The 500 series promised to address all those problems with improved tolerance of things that would stop the 300 series (such as cords, furniture it tended to get trapped under, and the edge of the rug), reduced noise levels, and more effective capturing of pet hair (the 300 tended to just push around big clots of pet hair rather than sucking it up).

So far I have been very pleased with the 500 series--if anything it exceeded my expectations. It is significantly quieter, handles the rug just fine, doesn't get trapped where the 300 did (we have one big sideboard with these decorative bits at the base that the 300 would tend to get wedged under, the 500 never does) and seems to have a longer battery life.

So now the old 300 lives upstairs where it can focus on keeping our master bedroom clean and the 500 takes care of the downstairs.

As I said in my report on the original Roomba, these are amazingly well-engineered products that can serve as models and inspirations for all of us that build things for other people to use. Compared to the 300 the 500 is not signficantly different but there are a number of minor but important refinements that add up to a much improved user experience, from the simplified controls (got rid of one button that wasn't of much use) to the better brushes to the easier-to-empty dirt chamber. And all at a reasonable price.

And it makes cleaning the house fun.

Loopwing Wind Generator

IMG_4216

One of my best Christmas gifts this year was this model of a loopwing wind generator from Tamiya (http://www.tamiya.com/english/products/75021loopwing)

I was unaware of this particular wind generation technology but it seems quite intriguing in that it claims to be better able to extract energy from light winds and takes less vertical space (and presumably is less dangerous to birds) than straight-wing wind turbines. This means you could have one on your house in your back yard and maybe not put the entire neighborhood in danger or violate local noise ordinances.

The kit itself went together quite quickly, the hardest part being cutting out the wings themselves, which actually required a little skill and care rather than just screwing the parts together (there's no gluing or anything).

The turbine drives a generator that then charges a little model car that plugs onto the top of the generator body. The energy is collected in a super capacitor that can then run the car for about 3 minutes on a full charge.

The connector to the car appears to be standard connector so it ought to be easy to build other things that can charged. I was thinking a little LED display that indicates the level of output or something or maybe something decorative. It would certainly be easy to adapt it to charging solarengine BEAM robots.

The generator doesn't swivel to face the wind but it would easy enough to mount it on a turntable with a wind vane if you really cared. I've got it mounted on a pipe that rises to about 5 feet and stands where the north side of our house forms a little wind tunnel that catches the northwest wind that tends to blow this time of year.

I find the prospect of having a home-sized loopwing generator interesting. We already have a 3K watt PV system on our house--it couldn't be that hard to add in the output from a small turbine, such as described here: http://www.treehugger.com/files/2006/11/loopwing_wind_t.php

Where we are in Central Texas we have a pretty reliable 5-10 MPH breeze most of the time and quite often stronger winds, especially in the spring and fall.

I think this year will start to see some interesting developments in alternative energy generation. Austin will be home to a new thin-film solar cell factory and is already home to a company trying to make high-capacity capacitors usable in electric vehicles. Taken together those technologies could make electric and solar-electric vehicles much more attractive in cost and range, not to mention the possibilities for home energy.

For example, imagine having a bank of capacitors that could provide the same power output as the little gas motors in all the three-wheel taxis in all of Asia and that can fit in the space currently used by the fuel tanks those vehicles carry (or otherwise fitted into available space).

Now imagine putting low-cost, flexible solar panels on the top of each of those three-wheels (they all have some sort of canopy on them) as well as on taxi stand shelters scattered around a typical Asian city. If most of those three-wheelers spend most of their time waiting for a fare, it seems reasonable to think that they could be mostly or entirely charged by their solar panels, taking from the main grid or a taxi-stand battery or capacitor bank only during peak times (e.g., morning and evening rush hour). Or maybe they could use one of those small fuel cells the Japanese are selling for home power use for peak-time charging where the grid is not reliable (or where natural gas is inexpensive).

The effect of such a change would be dramatic: a significant source of air polution would be eliminated, the need for fossil fuel would be significantly reduced in a part of the world where oil demand is rising much too sharply, and the operating cost of the taxis themselves would be reduced (assuming both that electricity costs per kilometer would be lower than fuel costs and that much of the operating energy would be from the vehicles' own solar panels).

With current battery technology, batteries could never be used to realize this vision: they're too expensive and too toxic and have too little energy capacity. But capacitors, if the current claims of orders of magnitude improved capacity prove out, could, because they have both a much higher energy density and lower toxicity (at least I assume they do) and they can charge very quickly, meaning that a taxi could do a 15 or 20 minute fare and then recharge in minutes at a recharging station or charge over say an hour using its own solar cells. That means a three-wheel taxi doesn't need to carry as much on-board energy capacity as it would for a battery solution.

Assuming the technology were there, what would it cost to, for example, provide a retrofit kit to every tuk-tuk operator in, for example, the Philippines? It would be several hundred million dollars at least (e.g., say $500.00 per vehicle) and as difficult to administer fairly and efficiently as any other aid project, but I would think that there would be lots of incentive from many parties to make something like that happen. And once the local population got used to the technology and had access to spares and second-hand parts so forth, the technology would be applied in many other creative ways. And at some point you'd hope it would be good enough to, for example, allow Philippine jeepneys to be retrofitted for electric power.

And cities like Manila and Columbo and New Deli would be much much quieter, with all those two-cycle motors replaced with electric drives.

Of course, the possibilities for other transforming uses of low-cost, physically flexible (that is, bendable) solar panels in developing and third-world countries are quite exciting. It will be interesting to see how the technology develops in terms of its economics and manufacturing environmental costs.

While there's no obvious direct connection between XML and alternative energy we, as an industry and as a society of large-scale computer system users are starting to realize that the collective cost of computing equipment does represent a significant fraction of our total societal energy draw. So the degree to which a technology like XML enables more people to do more with system, the greater the power such use will draw.

As a I write this, I'm sitting in a room with three computers running, drawing a couple hundred watts, as well as using Google and Yahoo, backed by massive data centers drawing terawatts of largely coal-produced electricity (except for those data centers built in Central Washington to take advantage of the cheap hydropower provided by salmon-habitat-destroying dams on the Columbia river and its tributaries). I'd feel a little better about that if I could at least make my urban house electricity self sufficient without spending too much more than I already have on alternative energy systems that make little economic sense under current U.S., Texas, and Austin energy policy (in particular, that, unlike Europe, utilities can buy back excess power at a steep discount from market rates, making the payback on my solar PV system 15 years or more *after* having half the initial cost rebated by the city and federal tax credits). Obviously we did it because we felt it was the right thing do and we could afford it, not because we had any financial incentive to do so).

Anyway, that's a long way from a cool toy that I got for Christmas....

I'm Bein' Macified

Through a series of more or less accidents I came to have physical possession of Really Strategies' one and only MacBook, purchased in order to support testing and delivery of software to a Mac-based client (which, considering that most of our clients are publishers should be most of them, but apparently hasn't been to date).

After some soul searching I have decided to make this Mac my primary development machine, giving up my oh-so-familiar Dell Windows-XP-based laptop.

We'll see how it goes. I must say that it's been quite an adjustment for me, somebody with nearly 20 years of Windows brain damage, to move to a Mac.

Of course it helps that most of the development tools I use are completely cross platform: Eclipse, Java, OxygenXML, Syntext Serna. It also helps that OS X is an *nx-based system under the covers, so I can get a command line that is familiar, although the configuration details are not (I've been using Debian-based distributions for most of the time I've used Linux). And other key tools have solid Mac versions (e.g., all the Adobe products).

I will even be able to get an RSuite server running on this machine, using an unsupported OS X build of MarkLogic.

I'm even starting to get used to the bizare control key mechanism, although it's still a struggle--it feels like trying to learn a new musical instrument that is just enough different from one you know to really hose you up.

I'm even writing this post using Safari, rather than Firefox, which I would normally use, but it's acting up this morning.

So wish me luck as I start on this new adventure in computing....

Automatic Handling of DITA Docs In XML Editors

I'm in demo prep heck at the moment, trying to get some real DITA functionality built on top of Really Strategies' RSuite CMS product. One of the key challenges here is integrating XML editors to handle this use case:

Initial state: You are presented with some valid, conforming DITA documents in some locally configured and/or specialized document type, organized by one or more maps. You (and your repository and supporting tools) have never seen this particular set of documents or their DTDs before.

Step 1. Import map and all dependencies (including its DTD) into the repository

Step 2. Within the repository, find a topic to edit and push the "Edit with {name of integrated editor}" button in the repository UI.

Step 3. Editor opens with document, with all DITA support features applied.

It is that step 3 that is currently causing me a bit of pain. And it shouldn't.

The reason it's causing me pain is because every graphical XML editor has been built on the presumption that document types are relatively static and that some XML specialist will develop lots of doctype-specific setup and then deploy that setup once, followed by a long time with no changes to that setup.

Thus, if you're presented with new documents in a heretofore unseen DTD, they're not going to work in the editor until you go through the setup and configuration process for the new document types [And remember that DITA 1.1 requires at least six distinct shell types: map, concept, reference, task, glossentry, and dita, plus any additional specialized map or topic types you might have--that's a lot of DTD-specific configurations to set up, even if most of that effort is just copy and paste, it's still tedious and prone to the usual errors of catalog misconfiguration, filename misspelling, and so on.]

However, DITA totally chunks the assumption of static, well-known doctypes out the window. DITA says "hey, every shell is different, specialize away, apply agile approaches to developing and refining your local DITA-based DTDs, combine topics from everywhere willy-nilly, go nuts, have fun".

To support this DITA does something very important: it enables reliable auto-recognition of DITA documents, regardless of the details of the local configuration or the use of specialization.

DITA must have this mechanism because the specialization feature allows generic DITA processing to be reliably applied to any conforming DITA document. Because it can be, it should be.

For the DITA Open Toolkit this means applying default processing (transforms, filtering, etc.).

For editors it means applying default editing style sheets, enabling DITA-specific user interface components (e.g., "Insert topicref"), etc., if no more specific configuration already exists for the document or its shell doctype.

And there's no reason for any DITA-aware editor not to, except that, without exception that I can find, they've all implemented their document-to-functionality mapping in a way that doesn't enable this sort of dynamic association. The closest I've found so far is Syntext's Serna editor, which while it doesn't recognize specialized topics as DITA topics and apply its (very nice) built-in DITA support, it does make it a two-click process to manually apply their built-in DITA support. So kudos to Syntext. But it should be a zero-click process.

For this automatic process to work processors have to be able to examine any document they're presented with and reliably determine whether or not the document is or is not DITA-based. Note that the Open Toolkit presumes that what it's given is DITA-based because that's the only thing it is designed to process. But things like editors and CMS systems are, for the most part, completely generic and designed to handle any XML at all. So they cannot presume (or at least they should not presume).

The recognition of DITA documents cannot be based on the use of any particular DTD's system or public ID, because they'll all be different. You can't look for a particular well-known element type because the element types could be completely different from anything previously seen (let's imagine a specialization where all the element type names are in Chinese--there's nothing that prevents it and if I was a native reader of Chinese and wanted to create tech docs I'd probably do just that).

That means you've got to go by something invariant that is reliably in every document. In XML that really means the use of a particular well-known namespace. However, DITA element types cannot be in namespaces because the current DITA class mechanism syntax cannot support namespace-qualified names. Knowing that about DITA you might think "well what to do then?"

However, just because elements can't be in a namespace, it doesn't mean attributes can't be. And that's the trick DITA uses in DITA 1.1 to enable autorecognition of DITA documents, regardless of any other aspects of the DTD (it's public or system IDs, the element type names used, etc.).

This trick is the DITAArchVersion attribute. This attribute is in the namespace "http://dita.oasis-open.org/architecture/2005/". Any document that includes this namespace is almost certainly a DITA document, especially if the namespace qualifies an attribute named "DITAArchVersion" and the element on which that attribute occurs has a class= attribute conforming to the DITA class attribute syntax.

This means that regardless of the actual DTD or schema a DITA document uses, it can be recognized as being a DITA document. That means that you can then reliably and usefully apply default DITA processing to the document without having specifically configured its particular DTD or schema as being a DITA schema.

That is, the behavior I expect from any editor that claims to be DITA-aware is that if I open any conforming DITA document, regardless of what declaration set it happens to use, I should get all the default DITA-specific stuff automatically.

While the most robust implementation of this behavior would make all the checks described above, it is probably sufficient to assume that if a document's root element has a DITAArchVersion attribute or if the root element is named "dita" and any of its children have a DITAArchVersion attribute, then the document is a DITA document.

The DITA spec only really recognizes three possible configurations of elements in a conforming DITA document: root of base type "map", root of base type "topic", or root of type "dita" [the dita element is not specializable in DITA 1.1] where its direct child elements are of base type "topic"--anything else is not a conforming DITA document (although it may contain individually conforming topics or maps) and you have no obligation to apply DITA-specific features to it (although you could if you wanted to).

That's by way of saying it's probably good enough to just look for the DITA namespace anywhere in the document and go by that, but it could lead to false positives in cases where the document is not strictly a conforming DITA document.

And it would be really cool if editors provided defined extension points by which this type of recognition could be added to doctypes as plug-ins to the editor.

It Just Works: Not So Much

When I started my new job I bought an inexpensive desktop to have as a home development machine (my last desktop had long since died and I'd not had justification or need to replace it). The machine, a Gateway Dual Core Pentium, came preloaded with Vista Business, which would not have been my first choice but there didn't seem to be a lot of options. After putting in another Gig of RAM (having discovered that Vista at idle takes about 950 Meg--yow) Vista ran OK but it just seemed to be stupidly slow, especially Windows Explorer. I really don't know anything about Vista nor do I care to, but at Windows XP seemed to work reasonably well. Vista, running on twice the hardware seems to perform half as fast. Why? Microsoft is certainly capable of producing good software.

I more and more got tired of having to wait for Explorer to respond and the inexplicably show unzip times and stuff and came close to putting on Ubuntu a couple of times, even though I don't really have time to spend on it. But finally I ran into a problem where I couldn't unzip the Web Tools distributions of Eclipse because of some filenames in the package that are too long for Windows to handle. WTF?

So I found some very clear instructions for installing Ubuntu alongside an existing Vista installation, resized my Windows partition and installed Ubuntu. That went quite smoothly, which I've come to expect from Ubuntu. So far so good.

But then things went down hill. First, I couldn't get the sound to work and what I could find in some frantic Googling suggested that others had had the same problem and had not had much luck fixing it. How can that be? This machine should be a pretty standard setup--it's clearly all-Intel motherboard with built-in sound and video.

I could live without sound (although I wouldn't like it--my desktop is also my office music system) but then the video stopped working and I can't get it back. The machine is attached to a Westinghouse 22in display. On install the desktop was using the standard 1280 x 1024 resolution. Once I got things otherwise working I turned my attention to the display. I reran the X-config application, chose the appropriate resolutions and so forth, and restarted the X server.

Boom "Out of Range". So far nothing I've been able to do to my X configuration file has made a difference. I was able to track down the manual for the display to get the actual horizontal and vertical sync frequencies but specifying those didn't work. I was not able to find any particularly useful guideance online beyond "rerun the configuration utility" or "specify the right sync values in the config files". The log-in screen is clearly running at the appropriate resolution for the display but why does it stop working when I log in? It's quite maddening.

But the real problem is that this just should not happen. It should not be possible for the windowing system to not work. As long as this is the case, as long as the first and only way to approach this failure is to open a terminal window and use sudo to edit a configuration file, it's a non-starter for anyone except the geekiest of geeks. If there's anything that should always work it's the display, even if it's to fall back to a lesser resolution. But I'm not even getting that.

I would really like some distribution of Linux to be a viable alternative to Windows for non-geeks but Ubuntu has definitely failed this test. I'm a geek. I've installed Linux countless times and gotten it working on a variety of machines. I should be able to make it work. Granted I was doing this while trying to do other stuff and didn't have endless hours to solve this problem, but that's the point: I shouldn't have to have endless hours or only expect Ubuntu to work on ancient machines (which is where I've been most successful). Ubuntu advertises itself as the Linux that just works. So it should just work. Certainly it should work on a commercial machine from a major vendor using generic Intel hardware.

I'm not sure if the problem is a technical one or a cultural one or an economic one. I recognize that hardware manufacturers don't have a huge motivation to write Linux drivers and that a volunteer-based project is dependent on people actually doing what's needed and maybe they will and maybe they won't. But there also seems to be a cultural component of "well, if you can't edit a configuration file you really don't belong in our club". And of course, since there's no single enterprise with economic incentive to make Ubuntu or any Linux distribution work as smoothly as Windows or OS X there's no reason to expect it will.

But that doesn't make it any less frustrating. It doesn't help that I've recently had to use a Mac for work, which makes it clear that there's no reason a *nx-based system couldn't be as smooth as the commercial systems are, but clearly it helps to have a multi-billion dollar company driving the activity.

Anyway, it's very frustrating since I had to boot back to Vista, I still can't install the Eclipse Web tools (and don't have any more time to spend working out that problem than I do on my Ubuntu problem), and now half my hard drive is tied up with a a useless operating system.

I know I can get back to a minimally working system by re-installing Ubuntu, but I have no confidence that I'll have any better luck getting the display to work.

Hmph.

InDesign CS3 and XML Authoring: Could be Good

In my new job at Really Strategies I have started digging pretty deeply into how to get XML into and out of Adobe InDesign CS3. This has turned out to be pretty interesting.

In InDesign CS2 the XML support was somewhat weak. While you could import an XML document into InDesign and then associate styling with it, it was very simplistic in that you had no direct way to do context-based associations and no easy way to script it, either on import or inside the editor.

In CS3 that has largely changed. CS3 adds several new XML support features that appear to serve to make InDesign a quite powerful XML rendering tool that could be integrated loosely or tightly with any other XML authoring tool to create an interesting environment. (You could, in theory use InDesign to author the XML as well but it wasn't really designed for that and I don't think it's a good use of resources to try to make it an XML editor, not when the process I outline here is so easy to implement.)

Here's the general mechanism I'm working toward:

1. Using InDesign, you create a template document that will accept your XML. This requires setting up all the usual styling stuff (page masters, frames, named styles) as well as creating instances of the markup structures that will populate different text frames (InDesign's XML import works by matching imported elements to existing elements and replacing the existing ones with matching structures on import, more or less).

2. You create an XSLT that takes your XML source and "augments" it with Adobe-specific attributes that specify the per-element-instance mapping to InDesign paragraph and characters, as well as generated elements for any generated text that needs to be rendered as a separate paragraph (analogous to the gentext psuedo elements Arbortext Editor uses to manage generated text display).

This XSLT can be pretty simple--it's just an identity transform with a little bit of per-element-type logic to define the mapping (and it could be further parameterized through some sort of more direct mapping specification, although I'm not sure it's worth the effort). This script could also re-order things as needed, generate TOCs, etc. But the minimum required is pretty small. There're a few more things you need to handle, but they can be generalized easily enough.

The main gotcha here is that InDesign is sensitive to newlines in the XML data, because newlines trigger the application of paragraph styles. What I've found so far is that you have to manage the text content very carefully so that you only emit newlines at true paragraph boundaries. This also means that you only apply paragraph styles to the lowest-level elements that will become paragraphs in InDesign--you can't just blindly apply styles at higher levels in the XML hierarchy (InDesign is not XSL-FO).

3. You run this transform outside of InDesign. InDesign lets you apply a transform as part of the import process, but we don't want to do that for reasons that will become clear in a moment (unless I've missed a feature of InDesign, which is quite possible--I'm still coming up to speed on its intricacies).

I use OxygenXML for most XML editing and it provides a very convenient mechanism for applying a transform to a document and saving the result wherever you want. But any good XML editor should provide a way to do this so that you have some sort of "run the transform" button or menu item. The key is that the result (the XML with the InDesign augmentations) is always put to some consistent place.

4. Import the augmented XML (not the XML you're authoring in your XML editor) into InDesign using InDesign's XML import (without applying the XSLT) but being sure to check the "link to XML" check box and select "merge" not "append"--this is the key.

5. Go back to your XML editor, make changes to the XML and push the "transform" button again.

6. Switch to InDesign and bring up the Links pallet. In that you'll find your XML document listed. Select it and click the "update link" button. Magically, your XML changes are re-imported into InDesign and the styles applied.

Hey presto! Immediate, easy, convenient pagination of XML using InDesign. Something that was not immediate, easy, or convenient with CS2.

I haven't looked into it but it should be possible to script the triggering of the link update as well, although that might require a little C code, I'm not sure. But it's clear that by this mechanism you can use InDesign as a "page preview" mechanism from any XML editor with very little work.

Beyond the simple element-to-style mapping you can do on import, CS3 also provides scripting support for working with XML in the form of XPath-based functions that allow you to easily apply any script to elements in context. I haven't used this yet but a brief look at the docs suggests that it's just the thing to take your XML to the next level.

It's still not going to give you what products like Typefi give you, which is complete complex layout heuristics, but it should be sufficient for relatively simple layouts such as typify technical documentation. It occurred to me, for example, that it wouldn't be very hard to create a process that would allow you to use InDesign to create nice books from DITA source using this mechanism. Hmmm

Note that you can download a one-month eval of InDesign from Adobe's Web site.

And Now for Something Completely Different....

Well, not that different actually.

As of Monday 2 July I will be moving from Innodata Isogen (www.innodata-isogen.com) to Really Strategies (www.reallysi.com). This move comes after 11 years at ISOGEN in its various incarnations, from a 20-person consultancy to a part of DataChannel (riding that Internet wave) to part of Innodata. It was a great period in my career--I got to do lots of interesting things and work with really great people, but it was time for a change, time to see what else was out there.

One big change with this job move is that I will, for the first time since becoming a Standards Maven, work for a company with a product. I have until now been a fiercely product-independent integrator, working for companies that had no preferential agreements with any vendors, partners with all.

Really Strategies has in the last year developed and marketed its RSuite Content Management System, targeted primarily at publishers.

How do I justify this change as still being consistent with my values and principles as a standards-championing consultant? Am I simply throwing away the reputation I've built as a person who hates all products, for the reasons outlined in the first posts to this blog? I hope not. I'm sure people will tell me if I have.

My justification is driven by the following observations:

1. My personal situation has changed over the last two years in a way that has forced me to realign my priorities, in particular, having started a family and built a house, I have to give more weight to compensation than I ever had to in the past. In short, I've gone from living well below my means to living just beyond them. And I've got to think about things like gymnastics class and preschool tuition and what it costs to travel with a child and so on. So yes, my convictions have been moderated just a little by demon cash.

2. For financial and other reasons, I'm not ready to hang up a shingle. It's just too much risk right now. Maybe in a few years.

3. There are only a few companies that do independent XML-related systems integration in North America and even fewer who could meet my outrageous compensation requirements or otherwise integrate me into their business.

4. Really Strategies is still first and foremost an integration consultancy that happens to have a product, rather than a product company that has an unavoidable services group. So far they've found that having the product is resulting in much more services work, mostly unrelated to the product. That is, the product is serving as much as a marketing tool as it is as a revenue source (although I understand we're selling a few licenses too, which isn't bad). That means that it's not all about the product, but still about solving client problems.

5. As ISOGEN was and is, Really Strategies is still about standards and that is reflected in their products as well as their services work (and if it's not, you can be sure I'll have something to say about it, and maybe even something to do about it).

6. Part of my job responsibility will be contributing to the architectural definition of the RSuite product. Because it's a very new product, even if it turns out to be heinous (which I don't think it is but I haven't yet had a chance to look under the hood), there's lots of opportunity to correct it. In addition, it's built on top of MarkLogic, for which I have a great deal of respect, both in terms of its engineering quality and in terms of its respect for and adherence to the standards it implement Just the fact that the RSuite engineers made that choice is a good sign (although it's no guarantee of anything, but there are only a couple of correct choices for a CMS base and a whole lot of wrong ones, and MarkLogic is definitely one of the correct choices, in my opinion).

Thus, while I will be working for a product company, it's in a situation where standards are still paramount and where I'll personally have an opportunity to express my principles and thoughts and ideas about how a product like RSuite should serve its users and not the other way around. And I suspect that most of my work as an integrator will not be related to RSuite at all, simply because of the nature of the types of projects that Really Strategies tends to sell.

Time, of course, will tell.

In any case, I'm very much looking forward to this opportunity to have early and direct influence on a product and not just via bug reports and feature requests and whining at the engineers I happen to know inside the company. I'll continue to do that of course, but now I'll be able to whine at engineers I actually work with.

I will also continue to be involved in standardization activities as much as I can, continuing the work I've been doing with the DITA and XSL-FO standards and probably contributing to other standards that are more relevant to Publishers rather than technical documentors, which has been my primary focus to date.

And it shouldn't surprise anyone if you start to see stuff about DITA-specific features in RSuite. Just saying....

Comments: My Bad

I just realized that since I turned on comment moderation to reduce comment spam, I actually have to go in and moderate comments. Doh!

My apologies to those who waited a month or more to see their comments approved. I'll try not to let it happen again.

A Message To Warm a Taghead's Heart

no-xml-response

Trying to connect to my Yahoo! Mail account, I got this popup box. I was quite pleased to see that it was upset about not getting any XML in the response.

DITA Standard Practice: Always Make Local Shells

As I started doing serious work with DITA and in particular implementing specializations, it became clear to me that the first thing anyone using DITA should do is make local copies of all the DITA-provided shell DTDs or schemas. This should just be automatic. [Note: I'm going to use the term "DTD" to mean "DTD or schema" from now on.]

Why?

DITA, like DocBook, is a generic standard designed specifically to allow controlled local configuration and extension. Anyone who uses DITA in any non-trivial way will need to do at least some configuration, if not specialization, before too long. It is the rare user of DITA who genuinely needs to use all of the topic types and domains reflected in the base DITA distribution. Even if you're not using any specializations you probably only need some of the domains DITA provides out of the box.

By "configuration" I mean adjusting the set of topic types and domains that are or are not used for a given document set. For example, if you're not documenting interactive software you probably have no use for the User Interface domain and would just as soon not have those element types available to authors. Turning off that domain for your authors is "configuration".

By "specialization" I mean new domains or topic types derived from the base DITA-defined types (see my specialization tutorial for a deeper discussion). Even if you don't develop your own specializations, it is likely that you will use specializations developed by others. This will be increasingly likely as the DITA community begins to develop more and more special-purpose specializations--this is one of the really cool things about DITA--it enables and rewards the creation of "plug-ins" that are relatively easy to create, distribute, and integrate with the base DITA document types and supporting infrastructure.

In order to do either configuration or use specializations you must create local shell DTDs that reflect the local configuration or integrate the specializations.

Since you're going to do it sooner or later, you might as well start your DITA life there and be prepared. Eat the (minor) pain up front of configuring your local environment to use your local shells and then you're set to go.

If you set up your local shells first, then as you add new DITA-aware tools to your system, you can simply configure them to use your shells from the get-go, rather than building a system of tools and a set of documents that then have to all be reconfigured later when you finally do implement local shells (or worse, you discover that your system has become such a lava flow that you can't reconfigure them meaning that you can't do any configuration or use new specializations because the cost of reconfiguration would be too high or too risky).

NOTE: when you create local shells you must give them unique global identifiers (URIs or PUBLIC IDs). You must not refer to them by the DITA-defined URIs or PUBLIC IDs. Local shells are just that, local. You create them, you own them, you name them. You should consider the DITA-defined shells and attendant module and entity files to be invariant, meaning that you should never ever modify them directly, but only use them by reference, configured using the DITA-defined configuration mechanisms (parameter entities for DTDs, named groups for schemas).

All DITA-capable tools should (dare I say "must"?) be capable of using local shells, otherwise they aren't DITA-capable, QED. Probably the biggest potential problem tool is FrameMaker, but then FrameMaker is something of a special case because it's not a true XML tool and it's design makes reconfiguration much more expensive than it is with any other XML editor you're likely to use. I'm sure it can be done but I wouldn't want to have to do it (of course, as systems integrator I might be asked to and of course I would do it but that doesn't mean I'd have to like it).

For example, I've just gone through the exercise of setting up Arbortext Editor 5.3 to support editing of heavily specialized topic types. Once you know what to do it's not too hard and is reasonably well documented in the online help. The basic process is:

1. Put each shell DTD in its own directory, named the same as the DTD or schema file. This organization is at least suggested, if not required, by Arbortext, but it's pretty good general practice anyway (even though the base DITA distribution doesn't organize things this way, there's no reason it couldn't and I've suggested that maybe it should, just on general principles of neatness).
2. Create an old-style (non-XML) OASIS entity catalog for mapping the URIs of your local shell DTDs to their local location. (Arbortext Editor 5.3 doesn't support XML-syntax catalogs.)
   
3. For each topic or map type shell, copy the Arbortext-specific configuration and style files from the Arbortext-supplied DITA doctypes that are the closest match to your local shells. Rename as necessary per the Arbortext naming conventions.
4. Edit the configuration files to reflect the details of your shells. This is stuff like setting the name used in the New file dialog, pointing to templates and samples, and so on. For specializations you'll need to account for new element types in the editor configuration, style sheets, and whatnot, if they require special handling.
5. Update the Arbortext Editor catalog path to include your catalog so it can resolve the references to the DTDs.

That's it. I would expect other XML editors to require a similar process (I haven't tried setting up XMetal for these specializations yet so I don't know what its configuration details would be).

Note too that as long as you are putting your shells in your own directory structures, and not in the dtd/ directory of the DITA Open Toolkit (which you should never do), it doesn't matter what you call your shell DTDs. That is, there's no particular reason not to call your local configuration of the concept shell DTD "concept.dtd".

So if you are a new user of DITA (by which I mean somebody setting up the DITA environment for a defined set of users, not an individual author [unless you are a writing team of one, in which case you are performing both roles]) I strongly urge you to create your own local shell DTDs right now if you haven't done so already.

Comment Spam Continued

So after turning on comment moderation, I still got two or three spam comments from Blogger.com members (which are not moderated) and blocked two from non-Blogger members. Which means that comment moderation is not very useful. At least the spam just inane and not particularly offensive.

My initial take was that it must be humans doing the spamming, but googling on "captcha bypass" quickly leads to information indicating that picture-based captcha can be cracked with 80 to 100% accuracy.

So I guess there's not much I can do about the spam.

Hmph.

It does lead to the idle thought that maybe it will be the spammers who first develop true AI in their quest to win the humans vs bots arms race....

Moderating Comments

Either spambots have cracked the comment captcha mechanism or humans are being paid to leave comments. In any case, I've turned on comment moderation to try to turn off the comment spam.

XML Documents vs XML Data Packages

Both James Clark's recent posts on XML and JSON as well as some recent attempts I've made to describe what I do professionally with respect to XML led me to realize that there doesn't seem to be an easy way to distinguish XML documents that are intended primarily to produce human-consumed results (e.g, published books, Web pages, online help, whatever) and XML documents that are purely for program-to-program communication (e.g., the use case things like JSON are trying to address more effectively than XML necessarily does).

Also, there's a part of me that wouldn't mind XML being returned to it's more or less strictly document-centered use rather than being the all-purpose data serialization and communication language it's become. Of course that's not really a productive line of thought.

But it did make me start to think that the stuff that James and others are starting to think about reflects the historical accident that the world, and in particular the Web-based world, needed a more transparent data communication mechanism than things like CORBA and DCOM provided just when XML appeared. People with the requirement saw XML as a way to do what they needed without spending too much time thinking about whether or not it was optimal--it was there and it would work well enough and here we are.

But it leads me to think that I agree with what I think James is saying: that it's probably not a bad thing to start designing serialization languages that are optimized for the specific tasks of program-to-program communication.

The existence of such languages would not in any way threaten the status of XML as a language for (human readable) document representation.

One thing that XML has done is embedded a number of key concepts and practices into the general programming world, such as making a clearer distinction between syntax and abstraction, which sets the base for realizing that once you have the abstraction, the original syntax doesn't matter, which means you can have multiple useful syntaxes for the same abstraction. It has made the general notion of serialization to and from abstract data structures via a transparent, human-readable syntax a fundamental aspect of data processing and communication infrastructures.

I think this means that we are now at a place where the community at large can see how you could refactor the syntax part of the system without the immediate need to refactor the abstractions (which is where most of the code is bound, that is, code that operates on DOM nodes rather than code that operates on SAX events or directly on XML byte sequences).

But it seems reasonable to me to at least start planning this refactor simply in the name of system optimization. It will probably take 20 years (it took 20 years to go from SGML as published in 1986 to today, when we can clearly understand why XML isn't the best solution for some applications) but it seems doable.

While the infrastructure for XML is widely deployed and ubiquitous, we also have the advantage that that infrastructure is by and large modular (in the sense that it's provided by more or less pluggable libraries in Java, .NET, C++, and so on) and in languages that are themselves ubiquitous.

For example, if Java or .NET released core libraries with base support for something like JSON it would not be hard for application programmers to start refactoring their systems to move from using XML for data packages to using JSON. Of course the systems using heavyweight things like SOAP would have a harder row to hoe.

If we take the Flickr API as an example of an XML-based API where something like JSON might be a better fit (or at least simplify or optimize the serialization/deserialization process), it would take a few person months on the Flickr end to provide an JSON version of the API (which would have to live along side the XML version) and a few person days or weeks for each of the language-specific client-side bindings for the Flickr API to use the JSON version instead of the XML version. At some point, say in a couple of years, the XML version of the API could be retired. That seems like a reasonable refactor cost if the value of using something like JSON is non trivial (I don't have an opinion on the value of something like JSON in this case--I just don't care enough and I've never had too much patience for "but this is more elegant than that" arguments if that's your *only* argument).

The Flickr API may be a poor example only in that the data structures communicated are fairly simple, mostly just sets of name/value pairs (metadata on photos) or lists of pictures or sets or users or tags. In that use case, XML works as well as anything else.

But in a more complex use case, where the data structures serialized are more complicated, in the way James talks about, with non-trivial data types and complex composite object structures and whatnot, I can definitely see a purpose built language having real value, primarily in the ease with which programmers doing the serialization/deserialization can both design and understand the mapping from the objects to the serialized form.

I spent some time working with the STEP standard (ISO 10303), a standard for generic representation of complex data structures, originally designed for interchange of CAD drawings and 3-D models and eventually generalized into a language for general product data interchange. It provides a sophisticated data modeling language. I was involved in the subgroup that was trying to define the XML interchange representation of STEP models. This turned out to be a really hard problem precisely because of the mismatch between XML data structures and data types (String at the time) and the sophisticated STEP models. It confirmed what I already knew, which was that mapping abstract data structures to efficient and complete XML representations is hard and naive approaches based on simple samples will not work.

That means that a comparable interchange syntax that is a better match for complex data structures will have value simply by making the conceptual task easier, so that designing and understanding serialization forms is easy (or at least easier) than it is using XML.

And then I can have my XML all to myself for creating "real" documents....