Re: Goal of this group?

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>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 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 ]
>



-- 
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 €