I guess, what @paperdigits is suggesting, is too keep data and layout as seperate as possible (and I would highly recommend that, as well). This way, it is relatively easy to collect and maintain the data and only worry about the layout when its time for it.
The exact data format is less important than its structure. There are lots of editors that can handle xml or html or even markdown - markdown having the advantage of an extremely easy syntax that submitters might already be familiar with - discuss works with markdown as well as wikipedia and the likes.
With this workflow, you only want to mark what kind of hierarchical element a specific piece of text is (that word “kind” was marked with an asterisk in markdown) and later define in the layout, how that element looks. So, you mark something as <chapter>Caption here</chapter> and later define a format for the chapter captions (font size, indentation, enumeration…) - most editors (and even MS Word) do even a chapter count and create a table of contents for you based on that structure.
xml/html works similar, with a slightly more complex structure, but with the advantage of being able to better nest and define elements - if you like, I can give you an example from my work - I exported some data to an xml which was then layouted in Adobe InDesign.
Also, this would easily be convertible to a website, if your boss has some crazy ideas after the book 