Re: [docbook-apps] EPUB: dbtimestamp PI in pubdate or date

[Thomas Schraitle <tom_schr@web.de>]

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