I've (laaaazily) started collecting my blog posts, reorganized, into a  
book that I'd use for my mentoring activities. The choice so far has been  
DocBook + Maven + a specific Maven plugin that allows me to include live  
portions of code samples. So far so good. But so far I've worked  
copypasting my existing blog posts, translated from HTML to DocBook XML,  
while I realize that it would be much more efficient, for new blog posts,  
to write them in DocBook XML and convert to HTML. At this point, the  
question: with HTML5 which supports microformats, is DocBook still worth  
while? Cay Hortsmann, in an interview, said he's using XHTML for writing  
his book about Scala:

http://blog.eisele.net/2011/10/heroes-of-java-cay-horstmann.html

Actually, what I find annoying for DocBook is editing. I'm using XmlEditor  
 from XmlMind (http://www.xmlmind.com/xmleditor/) which explicitly supports  
DocBook XML, but it's not the most agile editing I've experienced so far.  
Until a few weeks ago I was not satisfied with HTML editors as well, so it  
made little difference. But now I've found Bluegriffon and I work wery  
well with it. That's why I'm evaluating whether moving definitely to HTML5  
is a good idea. More in detail, as I'm moving all my sites to a compact  
CMS I've written, the idea for publishing DocBook stuff was to integrate  
into my CMS the XSLT transformation from DocBook XML to HTML. The HTML5  
approach could make this integration unneeded.

And, BTW, I'm a bit confused about the relationship between HTML5 and  
XHTML5, and whether the latter will be really adopted or not.

Thanks for any suggestion.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio.giud...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

Just my 2¢, but the value of XHTML isn't necessarily in delivering
XML-compliant web pages. With XML namespacing it's easy to integrate XHTML
into other XML formats to provide (for example) rich text elements.

On Fri, 03 Feb 2012 11:36:38 +0100, A McDowell  

Good points, but it depends on the context. For instance, for my sites I  
do some postprocessing on (X)HTML files (e.g. with XSLT) and XML can be  
manipulated in a better way (e.g. you don't need JTidy). On the other  
side, the idea of integrating elements from other namespaces is good, but  
it fails if you want to use a WYSIWYG editor. In my experience, most HTML  
editors won't properly manage extra-HTML elements in an efficient visual  
way. What I'm trying is a different approach, that is to stay with the  
XHTML scheme and using divs with special classes. For instance, I have the  
problem of representing photos in a compact way such as:

<myns:photo>
    <id>20050817-0092</id>
    <caption>The lower Albegna valley and Isola del Giglio on the  
horizon.</caption>
</myns:photo>

The idea is that this compact information can be converted in something  
more complex, including JQuery support for pop ups, slideshows, etc...  
when rendered in a browser. This approach for me failed for visual  
editing. What seems to work better is to use <div>s with classes having a  
semantic meaning:

             <div class="nwXsltMacro_Photo">
                 <p class="nwXsltMacro_Photo_photoId">20050817-0092</p>
                 <p class="nwXsltMacro_Photo_caption">The lower Albegna  
valley and Isola del Giglio on the horizon.</p>
             </div>

Those classes don't match a CSS, but are used for a XSLT transformation.  
Actually, with XHTML5 I could do the same thing staying in HTML:

<figure>
     <legend>The lower Albegna valley and Isola del Giglio on the  
horizon.</legend>
     <img src="20050817-0092" alt="" />
</figure>

which seems to be supported by editors such as Bluegriffon, unfortunately  
that 20050817-0092 is not a full image path, just an id that is later  
manipulated. With the 2nd approach I can see it while editing because it's  
a <p>, <img> in this case is rendered as blank.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio.giud...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

Have you considered LaTeX? I haven't used DocBook so I don't know how
that compares.

I did LaTeX in my youth. Now I'm too old :-)

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio.giud...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

DocBook is good for "real" books where you want to/have to produce a
PDF, thanks to the DocBook-XSL stylesheet package. How do you produce
PDF from HTML5 source?

DocBook is good if you can live within its schema. I store all kinds
of metadata in its attributes and haven't felt limited yet. There is a
fairly strong movement against modifying the schema, though I guess
that's better than HTML5 where you have no choice at all for elements
and very little choice (except at your own risk) for attributes.

The DocBook community is obviously much smaller than the HTML[5]
community, and composed primarily of writers rather than developers. I
get the feeling that most writers work in companies and are provided
with a toolchain which significantly insulates them from DocBook. I
edit in emacs, which isn't so unusual in web-world but is definitely
unusual in DocBook-land.

Overall I think DocBook is a worthy industrial alternative to LaTeX,
but I think that most people will find DocBook too heavyweight and
will instead be satisfied with [X]HTML5.

On Feb 3, 2:07 am, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:

DocBook is good for "real" books where you want to/have to produce a
PDF, thanks to the DocBook-XSL stylesheet package. How do you produce
PDF from HTML5 source?

DocBook is good if you can live within its schema. I store all kinds
of metadata in its attributes and haven't felt limited yet. There is a
fairly strong movement against modifying the schema, though I guess
that's better than HTML5 where you have no choice at all for elements
and very little choice (except at your own risk) for attributes.

The DocBook community is obviously much smaller than the HTML[5]
community, and composed primarily of writers rather than developers. I
get the feeling that most writers use a toolchain which significantly
insulates them from DocBook. I edit in emacs, which isn't so unusual
in web-world, but is definitely unusual in DocBook-land.

Overall I think DocBook is a worthy industrial alternative to LaTeX,
but I have a feeling that most people will find DocBook too
"corporate" and will instead be satisfied with [X]HTML5.

Sphinx is much easier than DocBook:
http://sphinx.pocoo.org/

Akka is using Sphinx, have a look at the source and the final result:
https://github.com/jboner/akka/tree/master/akka-docs
http://akka.io/docs/