Re: Goal of this group?

Mohamed,

Section 2.2, and I will analyze this like a developer. In that one 
section I am being required to check out over 20 hyperlinks. With all 
due respect to Sir Tim Berners-Lee, excessive use of hyperlinks is bad. 
They are disruptive if too many are used. A *few* links (known as 
references or citations when we refer to classical printed books) is 
fine...but when someone asks me to jump to over 20 hyperlinks in the 
course of one desktop screen, just to figure out what they are talking 
about, that's a joke.

I meant no disrespect by using the word "risible", but I suggest that if 
people are able to implement EPUB systems, they are spending much more 
money than needed just because the specs are too complex. My educational 
background is physics and engineering, and we were taught to simplify to 
communicate. I see few signs of that from W3C or IDPF or many other 
bureaucracies.

And Mohamed, I agree that the point is more re-creation of new sub-specs 
to re-solve existing problems. Between company rivalries, professional 
and individual competition, personal aggrandizement and posturing, most 
of us just waste most of our time. Technologies existed to solve 
business problems a long time ago: we continue to invent new ones.

Arved

On 12/30/2013 09:01 AM, Innovimax W3C wrote:
> Arved,
>
> Can you be more precise in what you find risible in section 2.2?
> With respect to CFI, I concur that it looks like a reinvention of 
> XLink/XPointer, but the point is more :
>  --> Will this spec dies like XLink & XPointer or take off because 
> people desperatly needs it *now* (but not 15 years ago... or event 30 
> years ago with HyTime Architectural Forms...) ?
>
> Cheers,
>
> Mohamed
>
>
>
> On Mon, Dec 30, 2013 at 8:51 AM, Arved Sandstrom 
> <asandstrom2@eastlink.ca <mailto:asandstrom2@eastlink.ca>> wrote:
>
>     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 ofhttp://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 ]
>
>
>
>
> -- 
> Innovimax SARL
> Consulting, Training & XML Development
> 9, impasse des Orteaux
> 75020 Paris
> Tel : +33 9 52 475787
> Fax : +33 1 4356 1746
> http://www.innovimax.fr
> RCS Paris 488.018.631
> SARL au capital de 10.000 €