OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Jirka,

Am Samstag, 17. Mai 2014, 20:14:31 schrieb Jirka Kosek:
> [...]
> I think that instead of using . we should call apply-templates, so
> <?dbtimestamp?> is processed. Something like:
> <xsl:template match="date|pubdate" mode="opf.metadata">
>    <xsl:variable name="content">
>      <xsl:apply-templates/>
>    </xsl:variable>
>    <xsl:variable name="date">
>      <xsl:call-template name="format.meta.date">
>        <xsl:with-param name="string" select="normalize-space($content)"/>
>      </xsl:call-template>
>    </xsl:variable>

Thanks Jirka for your idea. However, I think this is only one part of the 
solution. :) We have a conceptual issue here IMHO.

Lets consider this use case: 
someone wants that the date on his titlepage should appear as "May 2014". 
Perfectly fine. I would say! He can insert it directly inside a <date> or 
<pubdate> if it should be a fixed date. Or he could use the dbtimestamp PI and 
let the current date calculated through the stylesheets. With the above 
change, both ways work.

Whenever our user creates HTML or FO/PDF, all is fine. No warnings, everything 
as expected. However, if he creates an EPUB, suddenly the <date> or <pubdate> 
falls apart with the known warning message.

What can our now unhappy user do?

He can withdraw his own date format and is forced to use a format that he 
never wanted, just to be consistent with the EPUB spec. Or he can change 
<date> or <pubdate> whenever he creates an EPUB, also forced by switching back 
and forth. Both options are not very nice IMHO. It contradicts our "use *one* 
source, create multiple formats" paradigm.

My hope would be that the user can use whatever format or string he wants in 
<date> or <pubdate> and *all* formats work. This is currently not the case and 
I think it's a deficiency.

After thinking a bit about this issue, I see the following possible solutions:

1. Use <pubdate> or <date> for titlepage, use a separate format for EPUB
   Internally, the correct format is used. However, it gets always the
   current date. Maybe it is not what the user wanted. 

2. Use heuristic approach to detect format and assemble it for metadata
   I guess, it needs a clever approach to detect what is a year, month and
   day. Can also have localization issues. Probably works only in certain

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
   However, we need to define what to do when no 2nd <pubdate> or <date>
   is available.

4. Extend dbtimestamp PI with an additional output="epub"
   Only one <pubdate> or <date> is used, but inside there are two (or more)
   PIs with refers to a certain output format. The stylesheet could pick
   the correct PI for a specific output.

5. Anything else...?

I think options (3) and (4) are the best approaches at the moment.

What do you prefer?


  Thomas Schraitle

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]