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

On Sun, May 18, 2014 at 2:10 PM, Thomas Schraitle <tom_schr@web.de> 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: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

docbook-apps message