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,

On Mon, 19 May 2014 19:14:01 +0200
Jirka Kosek <jirka@kosek.cz> wrote:

> > Using profiling just to avoid
> > a conceptual issue in the stylesheet(s) is not the cure, but adds
> > additional burden. :)
> 
> You will just import different base stylesheet.

I know, but... :)

Well, currently we don't have an official blessed profile-chunk.xsl for
EPUB, neither version 2 nor 3, do we? If you think it is useful, it
should be added to the EPUB stylesheets to be consistent with the
other formats. :)

However, coming back to my original point:
From my understanding, profiling is used to create other variants from a
single source. Variants are text which covers different target groups
(beginners, experts), different operating systems (Linux, Mac,
Windows), or something else text related.

To get it right, you say, an output format is "just another variant"
of the document, right? For me it's a different thing and I try to
avoid variants which "belongs" to output formats.

I think you stretch the paradigm of the stylesheets a bit too much by
saying "use profiling for generating EPUBs". Profiling is not required
to build all the other formats, be it HTML, FO, or manpage (and others
as well).

Only EPUB is different in this list. Doesn't it tell us something?

If you deviate the generation of EPUBs, the handling will be
inconsistent to all the other formats. From my perspective, this is not
very userfriendly.

In my opinion, there are some things that I don't like:

* Our users has to know not to use chunk.xsl but profile-chunk.xsl
  (which doesn't exists ATM by the way) Do they remember all the time
  the correct stylesheet?

* Markup needs to contain the right attributes and structures to do "the
  right thing".
  Does it have an official blessing? Where is it documented?

* Customization is made a little bit harder as you have to take
  profiling into account too

 
> > You wouldn't recommend to use profiling for just selecting the
> > right image, would you? ;)
> 
> If you use different images for HTML and EPUB I probably would.

Why? There is no need for that: You can use the <mediaobject> and put a
role="html" or role="epub" in imageobject:

  <mediaobject>
    <imageobject role="html">
       <imagedata fileref="foo.png"/>
    </imageobject>
    <imageobject role="epub">
       <imagedata fileref="bar.png"/>
    </imageobject>
  </mediaobject>

No profiling needed; different images for different output formats. :)


> > 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".
> 
> In EPUB you have different ISBN then in printed version of your book,
> some other parts of content has to be adjusted -- for example
> colophon.

Well, not necessarily. We use *single source* for a reason! :) Actually
we don't write specific things for a specific output format.

Don't think a colophon or a simple ISBN number qualifies it to use
profiling. For example, I have a customer and it is usually a good idea
to include *all* ISBN numbers into the product, regardless if it is EPUB
or a printed version.

A colophon can be written that it can be used for every format, not
only for one specific. Which *could* be a better way of advertising all
the different output formats, but that's a different story.

Sure, everybody has to decide which one is better for his use case.
However, as most users have a customization layer anyway, it could be
appropriate to do "small" things in it (like selecting the right ISBN
for EPUB from a set of different ISBNs).

By the way:
DocBook 5.1 contains the nice outputformat attribute for such purpose.
It is not included (yet?) in DocBook 4. ;)


> [...]
> Well, then easiest solution is to provide template for populating EPUB
> field. By default it can put current date into an EPUB file and user
> can override it to use different date or populate date dynamically
> from source and format it into xs:date format.

Can we the "populating EPUB field" task done in our EPUB stylesheets? :)


> > What about the following solution?
> > 
> >   <date>
> >     <?dbtimestamp format="Y, m"?>
> >     <?dbtimestamp format="Y-m-d" output="epub"?>
> >     <?dbtimestamp format="m (Y)" output="fo"?>
> >   </date>
> 
> That's messy and hard to process as PI's pseudo-attributes are not
> easily accessible in XPath.

Well, "messiness" is in the eye of the beholder, I would say. ;)

As with the PI's pseudo-attribute: yes, XPath can't access it nicely.
However, I've played around a bit and it seems possible.


> Then your life and requirements are easy :-)

Sometimes. :)

 
> > We should keep it simple and do the magic in our stylesheets,
> > without any profiling involved or required for this issue.
> 
> Profiling is also magic hidden in the stylesheets.

Yes, it's hidden. And magic. ;) See above.


-- 
Gruß/Regards,
    Thomas Schraitle



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