Hi,

handle XML+CSS well. However, most (all?) EPUB readers don't. So, the
> question is asking if instead ConTeXt could generate a XHTML


Precisely.


>  If you need both EPUB and PDF, start with a semantically rich XML
>> vocabulary, e.g. DocBook. In this case you can relatively easy transfrom
>>
>
My database doesn't generate DocBook. It generates a custom XML document
from which I generate a web page, and a LaTeX document (though soon to be
ConTeXt!). There is no reason, technically, why I cannot convert the source
XML to either DocBook or directly to EPUB. There are, however, problems
doing that, which Aditya correctly surmises:


> - Automatic section numbering taking care of different conversions.
> - Automatic index generation and sorting
> - Inserting hyphenation points at the appropriate place in the generated
> output (so that the browser can effectively rely on TeX's hyphenation
> algorithm to do line-breaking).
> - Convert TeX math to MathML.
>
> The current ConTeXT XML source can translate a well formed ConTeXt
> document into a XML document with the above features.


Those are exactly the issues that I would love to resolve using ConTeXt for
generating an EPUB. (The MathML isn't as important to me, but I can see
other people wanting such a feature.)

What about accessibility? I expect that visually impaired people would
> depend on document structure rather than its visualisation.


That is a good point. The current XML structure produced by ConTeXt (Hans
correct me here if I'm mistaken) is not accessible, as it doesn't adhere to
strict XHTML. I suspect that <div> tags would not be accessible -- the only
way to provide true accessibility in EPUB format would be by using the
strict XHTML tags.

for instance, we have more levels than H1..H6, so how to do H7? if someone
> has to deal with that, he/she can as well transform all into H1 with some
> class which is a local solution then


I realize there is not going to be a one-to-one map of all possible ConTeXt
macros to XHTML. For someone who has 7 levels of nested sections they would
either have to rewrite some Lua or perform some post-processing (e.g., with
XSLT). I would posit that a document with 7 levels of nested sections is
not going to be a common occurrence.

When I talk about strict XHTML, I'm proposing that a _simple_ ConTeXt
document (up to 6 header levels, numbered and unnumbered lists, images,
text emphasis, etc.) should generate a simple, validating XHTML document.
Trying to attain 100% coverage of ConTeXt transmogrification to XHTML is
ridiculous when, I suspect, 80% coverage would meet most needs. :-)

It is definitely possible to translate the ConTeXt EPUB output to XHTML.
However, there are practical realities that hinder such an approach.
Architecturally, if anyone is going to translate an XML document to EPUB
format, it certainly won't be this way:

*XML + XSLT -> ConTeXT File -> ConTeXt EPUB XML + XSLT -> EPUB + CSS*

It'll be this way, which is less time-consuming, less complex, and less
susceptible to err:

*XML + XSLT (or API) -> EPUB + CSS*

However, it does not, as we all know, produce as feature rich output as
leveraging the ConTeXt abilities that Aditya mentioned, which was the point:

*XML + XSLT -> ConTeXT TeX -> EPUB + CSS*

Kindest regards.