Re: DOCBOOK-APPS: XSL-Style: bibliography - abstract
On Sun, Nov 03, 2002 at 07:41:01AM +0100, Stephan Wiesner wrote: Good Morning list, I would like to expand my bibliography with short texts to the books. abstract is an element that can be used for this, like: biblioentry id=biblioDocBook abbrevDocBook/abbrev titleDocBook: The Definitive Guide/title abstractparaThis book explains it all./para/abstract authorfirstnameNorman/firstnamesurnameWalsh/surname/author authorfirstnameLeonard/firstnamesurnameMuellner/surname/autho r isbn156592-580-7/isbn publisher publishernameO'Reilly and Associates/publishername address countryUSA/country /address /publisher /biblioentry This is just omited by the style. Surely something I could include in my personal adaption of the style, but I would think this to be a feature used by more than just me? Actually, the abstract does appear in the PDF output. In the HTML output, the stylesheet actively suppresses abstract, using this template from html/biblio.xsl: xsl:template match=abstract mode=bibliography.mode !-- suppressed -- /xsl:template Stylesheet author preference, I guess. You'll need to override this template to get the abstract into HTML output. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED]
DOCBOOK-APPS: Bibliography: Articles
Hi List, I need to reference articles. I started with the example from the DocBook book and adapted it. I have included the example and the resulting PDF in this mail. Has anybody an adaption for this, or am I just doing it wrong? One magazine and two articles would look like this: biblioentry abbrevInfSpek/abbrev biblioset relation='journal' titleInformatik Spektrum/title edition25/edition dateAugust 2002/date publisher publishernameSpringer-Verlag/publishername address countryGermany/country /address /publisher issn0170-6012/issn /biblioset biblioset relation='article' titleRealisierung eines Datenaustausches im elektronischen Handel/title abstractparaDer elektronische Handel befindet sich in der ersten Hälfte seiner Entwicklung und ist doch schon Normalität in den Unternemen. Für die Realisierung des Datenaustauschs benötigen die Unternhemen Kommunikationsstandards und Softwarelösungen./para/abstract authorsurnameEsswein/surnamefirstnameWerner/firstname/author authorsurnameZumpe/surnamefirstnameSabine/firstname/author pagenums251-261/pagenums /biblioset biblioset relation='article' titleXML-Strukturakquisition/title abstractpara/para/abstract authorsurnameStrohmaier/surnamefirstnameChristian/firstname/a uthor pagenums262-265/pagenums /biblioset /biblioentry Stephan StyleTest2.pdf Description: Adobe PDF document ?xml version=1.0 encoding=ISO-8859-1 standalone=no? !--!DOCTYPE book SYSTEM file:///C:/x/saxon/dtd/docbookx.dtd ?xml-stylesheet type=text/xsl href=C:/x/docbookxsl/old/html/docbook.xsl ?-- !DOCTYPE book SYSTEM file:///C:/x/docbookxsl/docbook-xsl-1.54.1/docbookx.dtd ?xml-stylesheet type=text/xsl href=file:///C:/x/docbookxsl/docbook-xsl-1.57.0/html/docbook.xsl ? book lang=en titleMicropayment/title bibliography titleBibliography/title bibliodivtitlePeriodicals/title biblioentry abbrevCOM!/abbrev biblioset relation='journal' titleCOM! Online/title edition11/2002/edition publisher publishernameNeue Mediengesellschaft Ulm mbH/publishername address countryGermany/country /address /publisher issn1437-3432/issn /biblioset biblioset relation='article' titleElektronische Geldbörse/title authorsurnamePatschowski/surnamefirstnameAnita/firstname/author pagenums136-139/pagenums /biblioset /biblioentry biblioentry abbrevInfSpek/abbrev biblioset relation='journal' titleInformatik Spektrum/title edition25/edition dateAugust 2002/date publisher publishernameSpringer-Verlag/publishername address countryGermany/country /address /publisher issn0170-6012/issn /biblioset biblioset relation='article' titleRealisierung eines Datenaustausches im elektronischen Handel/title abstractparaDer elektronische Handel befindet sich in der ersten Hälfte seiner Entwicklung und ist doch schon Normalität in den Unternemen. Für die Realisierung des Datenaustauschs benötigen die Unternhemen Kommunikationsstandards und Softwarelösungen./para/abstract authorsurnameEsswein/surnamefirstnameWerner/firstname/author authorsurnameZumpe/surnamefirstnameSabine/firstname/author pagenums251-261/pagenums /biblioset biblioset relation='article' titleXML-Strukturakquisition/title abstractpara/para/abstract authorsurnameStrohmaier/surnamefirstnameChristian/firstname/author pagenums262-265/pagenums /biblioset /biblioentry /bibliodiv /bibliography /book
Re: DOCBOOK-APPS: XSL-Style: Referencing links
On Sun, Nov 03, 2002 at 07:31:14AM +0100, Stephan Wiesner wrote: Good Morning list, Can I reference a link? Like, I have a section with resources and want to reference a link of it in the text. The source can be aquired here: xref linkend=link_SW/. And below, in my bibliography section: biblioentry id=bib_sw abbrevSW/abbrev titleMy Own Home Page/title bibliosource id=link_SW ulink url=http://www.stephanwiesner.de/java; http://www.stephanwiesner.de/java /ulink /bibliosource /biblioentry Neither HTML nor PDF style can render this. I could use the ID of the biblioentry, but this would not give me just the link. Actually, there is a larger problem here, which is that the bibliosource element is not supported at all in the XSL stylesheets. You should file a bug report on that. In general, the generated text for an xref to an element is that element's title text. For elements that don't have a title (such as a bibliosource), you can use the 'endterm' attribute. The 'endterm' is an IDREF to the ID of the element whose text you want to use for the generated text. In this case, it is the same element. For example: xref linkend=link_SW endterm=link_SW / This will basically reproduce the bibliosource element's output (when that bug is fixed) as the generated text of the xref. You have to be careful with endterm, because it will include all the text of the element pointed to. If that element happens to be a chapter by mistake, then the generated text for the xref is all the text in the chapter. Any element that is not rendered as just inline text will probably produce odd formatting in the xref. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: questions about XML catalogs?
On Saturday, November 2, Robert P. J. Day wrote: if one has queries about XML catalogs, where's the best place to ask? Hi Rob! Depends on the distribtion. Since I suspect you're interested in the RedHat implementation, Daniel Veillard is their defacto resident xml catalog policy wonk. (He also is on this mailing list, so I suspect he'll weigh in shortly.) You could also try posting your specific question(s) to the LSB-xml-sgml list by sending a message to [EMAIL PROTECTED] Hope that helps, Mark -- _ Mark Johnson[EMAIL PROTECTED] Debian XML/SGML [EMAIL PROTECTED] Home Page: http://dulug.duke.edu/~mark/ GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81
RE: DOCBOOK-APPS: Question about the ENTITY references
Hi David, I'm using version 3.0.5.065 (Unicode). I will report it to XMetaL support and see what happens... Are you still using XMetaL? Have you ever used the browser preview succesfully? Once you have made changes to the document the only thing you get are errors. I cannot believe that these kind of errors are in XMetaL... Thanks, Simon. -Original Message- From: David Cramer [mailto:dcramer;broadjump.com] Sent: vrijdag 1 november 2002 16:40 To: Kraa de Simon; [EMAIL PROTECTED] Subject: RE: DOCBOOK-APPS: Question about the ENTITY references Not. This is one of XMetaL's many limitations. Attached is a test case I provided XMetaL support long ago. Out of curiosity, what version of XMetaL are you using? I was working with 2.1 when I reported the problem. They're response was basically don't do that. David -Original Message- From: Kraa de Simon [mailto:Simon.de.Kraa;services.fujitsu.com] Sent: Friday, November 01, 2002 2:44 AM To: '[EMAIL PROTECTED]' Subject: DOCBOOK-APPS: Question about the ENTITY references Hello, I have a question about the ENTITY references. Part of the TDG directory structure: ./book.xml ./bookbody.xml ./ch00.xml ./entities/content.ent In bookbody.xml the reference to chapter 00 is: ch00; In entities/content.ent all entities are referenced by ../ch00.xml but shouldn't this be ./ch00.xml? Because the bookbody.xml and ch00.xml file are on the same level and ch00.xml is referenced from within bookbody.xml? !ENTITY ch00 SYSTEM ../ch00.xml The XML editor that I use (XMetaL) cannot find the file ../ch00.xml and when I think about it I think he is right... Or not?
DOCBOOK-APPS: link to chapter in pdf
hi,
I have some problems with the PDF output.
In the TOC the links to the chapters do not work,
the same with the pdf-outlines. The link references
the chapter-id, and this id is set to the corresponding
fo:page-sequence of the chapter (in component.xsl).
It works fine If I set the id after the fo:flow, for example
(short form):
xsl:template match=chapter
fo:page-sequence
fo:flow
fo:block id={$id}/
The same problem occurs with the other elements, like
appendix, where the id is set in the fo:page-sequence.
Is this a known problem?
Greetings,
Marko
DOCBOOK-APPS: Re: XML catalog resolution problems
On Wed, Oct 30, 2002 at 12:31:32PM -0800, Norman Walsh wrote: I am, to be frank, disappointed and frustrated that you've blown a great big hole in a smooth operation of XML Catalogs. The whole point was interoperability and you've $%#$@#ed that up. 1 user complain in 15months of operations. You call that $%#$@#ed that up while IIRC I was the first implementor ??? Now I am the one disapointed ! I think your action threatens the whole enterprise and it's deplorable. What will the spec be completed ? So far I have seen no movement since Aug 01, I raised my point shortly after because I got users reporting to me they got confused by the distinction (because initially I tried to make the separation). At that point I basically received an answer without content. So I merged both notions an had no problem until the beginning of this thread. In retrospect saying the course of my actions is to threatens the XML Catalog deployement could only be looked at with amazement for example from the Gnome community, damn, I got beaten and had to fight there to have them deployed . To be frank, it's my turn to be disappointed and frustrated :-( I take patches usually !!! Usually people who have troubles send me patches or report the problems they face, then I fix them. Show me a final version [*] of the XML Catalog spec and I will either fix the problem or remove the support. Daniel [*] http://www.oasis-open.org/committees/entity/ doesn't show any update since the 06 August 2001. -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 01:58:30PM -0600, Paul Grosso wrote: The XML spec in 4.2.2 explicitely state that in production 75 the System ID is an URI-Reference and link to RFC 2396. RFC 2396 ftp://ftp.ietf.org/rfc/rfc2396.txt defines: URI-reference = [ absoluteURI | relativeURI ] [ # fragment ] The XML spec says a system identifier cannot include a fragment identifier. So the XML system identifier matches [ absoluteURI | relativeURI ] in RFC 2396 (for which there is no single name given in 2396) whereas the URIs matched by the uri catalog entry match the full URI-reference production above. The spec says it's an URI-Reference. It references the RFCs explaining how to compute the final URI from those references. The fact that there are restrictions from the full set admited as the URI-References input doesn't mean that the mechanism should not be used. The only meaning is that one cannot try to point to a subsection of the target resource, period. It does not mean that the URI-Reference to URI mechanism by composition to the base must be voided or be made specific. The XInclude spec does the same for the href attribute. There is no XML Base, so both references uses the same base and anybody with some common sense would expect the two references to get to the same resource. An XInclude href consists of a URI. An XML doctype declaration's ExternalID consists of both a public identifier and a system identifier. They sound very different to me, and it makes perfect sense for two such different references to be able to resolve to different resources. When there is a public ID, then the public ID may point to something else. In the case where there is twice the exact same system ID I don't see any reasonnable justification to distinguish those. You're asking for the same resource, why would you magically get different results ? Moreover when there are both System ID and Puyblic ID the XML Catalog spec clearly separate the lookup processing by public and system ID. As a result the work to be done on a system ID is exactly similar to the one one need to take for another URI reference except the identifiers in the catalog need to be magically different. I very much disagree with your broken assertion, Daniel. I ask of resource A, then A again, and get different results without the actual resource having changed in the meantime. Yeah I think this is broken, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
