Hi, I just wanted to respectfully chime in here to say that Thomas is not alone. I'm in the same situation and agree with his viewpoint. thanks, --Tim Arnold
On Sun, May 18, 2014 at 2:10 PM, Thomas Schraitle <[email protected]> wrote: > Hi Jirka, > > Am Sonntag, 18. Mai 2014, 18:19:51 schrieb Jirka Kosek: > > On 18.5.2014 14:42, Thomas Schraitle wrote: > > > 3. Detect an additional <pubdate> or <date> with role="epub" > > > > > > This could solve the issue as both formats can live happily > together. > > > We > > > used this approach also for imagedata which "belongs" to certain > output > > > formats. > > > However, we need to define what to do when no 2nd <pubdate> or > <date> > > > is available. > > > > You can achieve this today with profiling, I'm not sure whether there is > > any need to standardize this behaviour. > > Yes, I thought about profiling too, but didn't add it to the list. In my > opinion, it's a bit "too much": Using profiling just to avoid a conceptual > issue in the stylesheet(s) is not the cure, but adds additional burden. :) > > This issue is exactly the same than selecting the right image format in the > mediaobject/imageobject elements by using a role attribute. No profiling is > involved and the stylesheets just select the respective image format > correctly. You wouldn't recommend to use profiling for just selecting the > right image, would you? ;) > > In my opinion, date formats and image formats are very similar concepts in > how > the correct result is selected. > For image formats, there is a "best practise" for years, it's stable, well > documented, and all stylesheets support it. This is not the case for date > formats in EPUB. At least I'm not aware of it. > > Maybe not all users create EPUBs and run into this problem. I do. EPUB > validation always fails due to this issue. The EPUB stylesheet doesn't work > "out of the box". > > For that reason, I would really vote for a "best practise", > "standardization" > or recommendation, similar to what we have for imageobjects. > > > > There are dozen of similar cases and there is no direct support for them > > as well. > > What cases do you have in mind? If there are more use cases, maybe this is > an > indication that we really need a "best practise". > > > > I think that for EPUB we can just document the following best practice: > > > > <date condition="noepub"><?dbtimestamp?></date> > > <date condition="epub"><?dbtimestamp format="Y-m-d"?></date> > > Well, maybe, maybe not. Whatever we prefer, I think we have to distinguish > two > cases in EPUB: > > 1. The date, probably somehow/somewhere definied by the user, which > appears on > a titlepage. > > 2. The date inside any meta information, usually hidden for the user. > This is required by the EPUB specification. > > For (1) the user can choose whatever he likes. There is no restriction. > > However, for (2) the EPUB demands a YEAR-MONTH-DAY format. Either the user > defines it manually or he lets the stylesheet(s) do the correct output. > > Unfortunately, usually (1) is different than (2). > > In my opinion, it's the task of the stylesheets to do "the right thing". > :) If > the user did "the wrong thing" (whatever it will be), the stylesheet should > warn the user and give a hint. The hint should contain the preferred > markup. > > I'm not sure if two (or more) <date>s are a good solution. After thinking a > bit more, I would prefer _one_ <date> without any profiling attributes. The > reason for this is, no profiling attributes mean no conflicts with user > semantics. I would avoid such things and better leave this detail to PIs. > > What about the following solution? > > <date> > <?dbtimestamp format="Y, m"?> > <?dbtimestamp format="Y-m-d" output="epub"?> > <?dbtimestamp format="m (Y)" output="fo"?> > </date> > > No profiling attribute is needed, the user can still add a condition > attribute > if he needs it. > > When the EPUB stylesheet needs a date, we prefer the 2nd line for both > titlepages and meta information. Another idea could be we use the 2nd PI > for > meta information and the 1st PI for the titlepage. Whatever it will be, we > should clearly define it. > > Profiling adds just another layer of complexity which I would prefer to > avoid. > > > > Anyway, if you are producing EPUB and other targets it is very likely > > that you are already using profiling. > > Hope you didn't mind, but I have to friendly disagree. :) > > No, I don't use profiling when I create my EPUBs. ;) Nor for other formats. > Building EPUBs and other formats doesn't involve necessarily a profiling > step. > By no means it should be required. > > Remember, profiling is an _optional_ step! It's an additional feature: > sure, > in some cases you need it, in other you don't. > > We should keep it simple and do the magic in our stylesheets, without any > profiling involved or required for this issue. > > > > -- > Gruß/Regards > Thomas Schraitle > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
