Re: The non-polyglot elephant in the room

(www-archive before the Chairs tell us we are off-topic.)

On Tue, Jan 22, 2013 at 10:59 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
>> I think requiring XHTML is the least of EPUB’s problems when it comes
>> to author ergonomics.
>
> Henri, with all due respect, you probably have carefully read the EPUB
> specs but I'm not sure you are well aware of what is the software
> production chain in the publishing industry...

My awareness of publishing industry EPUB tooling is indeed bad beyond
being aware of InDesign.

> Using an XML model is far more important than you think because it gives
> EPUB authors the ability to do a first trivial validation on the
> elements contained in a document instance w/o having to call an
> expensive (in terms of time) validator. All IDEs out there are able to
> tell you if you miss an end tag, or if your attributes are faulty
> and that's already a bit of something, trivially implemented.

Note: I was not arguing against XML in EPUB. Mike was.

>> The main annoyances are needless indirection (Why do you need to be
>> able to locate the OPF wherever you want and have a pointer to it in a
>>
>> well-known location? Why aren't you just put the OPF in the well-known
>
>
> Because EPUB is based on the assumption a reader may have no knowledge
> and even no visibility of a filesystem, mimetypes, and such. The OPF
> and its manifest then serve as a central declaration point for all
> things found in the package. Yeah, that can be seen as painful; it
> can also be seen as a savior by low-end devices.

I mean: There is the fixed well-known path META-INF/container.xml
anyway. The file there points to the OPF to allow the OPF to live at
an arbitrary path. What's the point? Why did the designers of EPUB
just require the OPF to live at a well-known path under META-INF and
do away with the container.xml layer of indirection?

>> location?), the dependency on an XML vocabulary even worse than OPML
>> (NCX), the requirement to declare various things that the reading
>
> NCX is obsoleted in EPUB 3.

Except you still need to care about NCX if you want the table of
contents to work in all Reader Mobile SDK-based e-readers out there.

> I am probably the only one in the world who implemented EPUB 3 metadata
> authoring _fully_ . EPUB 3 metadata are incredibly powerful, probably
> too powerful but the thing I know is that their power is currently
> impossible to express in html.

Who is consuming that metadata fully if nothing but BlueGriffon
supports authoring it fully? If metadata falls in the forest and there
is no one to hear it, does it make a sound?

I’d love to see empirical data about what OPF metadata features, what
epub:type attributes and what <guide> items actually have an
observable effect in what Reading Systems.

>> The annoyances mentioned in the previous paragraph make EPUB authoring
>> by hand is terrible enough that you need a tool, and once you have a
>> tool you might as well throw HTML to XHTML conversion into the tool.
>
> Please define "tool" here? You mean a specialized app with knowledge of
> the xml dialects used by EPUB or a generic editing tool with XML
> knowledge, for instance emacs or eclipse?

I mean a piece of software that makes sure the mimetype is the first
file in the zip and is uncompressed, takes care of font mangling,
generates NCX from some more human-friendly representation, etc.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 22 January 2013 09:18:37 UTC