Re: [docbook-apps] Permalinks resources
Hi Scott, On Tue, 20 May 2014 08:26:55 +0300 Scott Rifenbark wrote: > I am trying to implement some permanlinks throughout a manual and am > working from here - > http://doccookbook.sourceforge.net/html/en/dbc.html/permalinks.html Great, you found my cookbook! :) There is a small typo, the "/" should be "."; the correct URL is: http://doccookbook.sourceforge.net/html/en/dbc.html.permalinks.html > I am hitting some issue where some links are being constructed > correctly (chapters) but some are not (sections). In that case, I think you've hit a bug in my stylesheet(s). I will look into the issue and come back to you later. > Does anyone know > of any more information available on implementing these links beyond > the URL I have mentioned? I can't seem to find much information out > there on the Internet. Well, a permalink is a constant string which is immune to reordering or restructuring of your document. The best approach that fits into this requirement is your own IDs. With the "use.id.as.filename" parameter you can create stable filenames as well. I'm not aware of any better approach. -- Gruß/Regards, Thomas Schraitle - To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
[docbook-apps] Permalinks resources
Hi, I am trying to implement some permanlinks throughout a manual and am working from here - http://doccookbook.sourceforge.net/html/en/dbc.html/permalinks.html. I am hitting some issue where some links are being constructed correctly (chapters) but some are not (sections). Does anyone know of any more information available on implementing these links beyond the URL I have mentioned? I can't seem to find much information out there on the Internet. Thanks, Scott
Re: [docbook-apps] EPUB: dbtimestamp PI in pubdate or date
On 18.5.2014 20:10, Thomas Schraitle wrote: > 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. :) You will just import different base stylesheet. > 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? ;) If you use different images for HTML and EPUB I probably would. >> 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". 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. >> I think that for EPUB we can just document the following best practice: >> >> >> > > 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. 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. > What about the following solution? > > > > > > That's messy and hard to process as PI's pseudo-attributes are not easily accessible in XPath. > 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. Then your life and requirements are easy :-) > 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. -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz -- signature.asc Description: OpenPGP digital signature
Re: [docbook-apps] EPUB: dbtimestamp PI in pubdate or date
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 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 or 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 or > > > >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: > > > > > > > > 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) s are a good solution. After thinking a > bit more, I would prefer _one_ 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? > > > > > > > > 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-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org > >
