Re: Goal of this group?

Jean, no offense, I was just referring to the EPUB specs. They really 
are bad. I suppose if you are immersed in the technology, you may not 
realize how obtuse and academic and pretentious that documentation is.

I invite anyone to read section 2.2 of 
http://www.idpf.org/epub/30/spec/epub30-publications.html for example, 
and master all of that. That language is risible.

And with all due respect, since you mentioned CFI, I think that things like:

book.epub#epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10)

as mentioned in 2.1 of http://www.idpf.org/epub/linking/cfi/epub-cfi.html are abominations.

Maybe that's just me. But I'm a developer since the '70's, and I surely 
would not wish that syntax on any implementor.

You'll forgive me for being somewhat cynical about EPUB. On any device 
that I'm familiar with - desktop 15 inch to 27 inch, say, or a variety 
of smartphones, or a variety of tablets, I never noticed that PDF or 
XHTML was problematic. I contend that NIH still exists.

I'm not in the business of raining on parades, but often the last people 
who should shape specs are the folks who specialize in being experts.

Arved

On 12/29/2013 05:54 PM, Jean Kaplansky wrote:
> Sorry Arved – regarding "has anyone actually even stepped back and 
> clinically examined EPUB, for example?”
>
> Why, yes. As a matter of fact. I have. It’s actually part of my day 
> job to know EPUB pretty well. You should also know that following the 
> 80/20 rule, about 80% of the EPUB books in the world are not intended 
> to have specific page layouts and are not designed to be printed, but 
> instead are designed to be displayed in some way on some device which 
> the implementor will not know in advance. EPUBs aren’t intended to 
> replace PDFs or other ways of getting page layout algorithms onto 
> printed pages. We already have plenty of standards about those 
> particular subjects.
>
> EPUB was designed to build on existing standards, BTW. HTML, CSS, and 
> ZIP compression being the primary examples of the “don’t reinvent the 
> wheel” approach.
>
> In places where some would argue that EPUB does reinvent the wheel, I 
> recommend digging deeper. If you talk to someone who was involved in 
> one of the areas that have been accused of going where specs already 
> exist (for example, the Canonical Fragment Identifier (CFI) 
> specification – which looks like it could be solving use cases very 
> similar to those solved by Xlink and XPATH), the conversation may 
> reveal that existing specifications were carefully evaluated for use 
> before the decision to strike out in a different direction was made. 
> We had such a conversation very recently in an Open Annotations 
> Working Group telecon regarding the CFI spec.
>
> <opinion>The argument of “you should’ve used ‘X existing 
> specification’” can turn into a holy war conversation within in any 
> standards group, however. There are ongoing attempts outside of the 
> IDPF to simplify what some people have declared to be overly complex. 
> Some of these efforts are truly made in earnest, others are less well 
> intentioned, and some people are just, well… crabby and refuse to be 
> pleased. In short, you don’t have to look very hard for a cat fight, 
> no matter what letters are at the top of the cover page… err… 
> reflowable screen.</opinion>
>
[ SNIP ]