DOCBOOK-APPS: Re: XIncludes
On Wed, 12 Mar 2003 10:45:14 +0100 Stefan Bylund <[EMAIL PROTECTED]> wrote: > Hi Damian, > > I first tried xincluder but I soon found out that xmllint is > more fully featured. I use the following command to resolve all > xincludes before invoking the XSLT processor (Saxon): > > xmllint --xinclude --catalogs document.xml > resolved.xml > > Note that xmllint uses the SGML_CATALOG_FILES environment > variable to find the catalog(s). > > The xmllint tool is part of libxml2 which is located at > http://xmlsoft.org/. It is also a very good validating XML > parser; I use it the following way: > > xmllint --xinclude --postvalid --noout --catalogs document.xml If your document uses entities which declared in external DTD (like DocBook), you should add --loaddtd -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: Re: needing clarification about XSL transformation
On Mon, 3 Mar 2003 09:59:18 -0500 (EST) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > On Mon, 3 Mar 2003, Vitaly Ostanin wrote: > > > With this style xslt-processor must not copy comments and PI. > > This style not overriding built-in templates, so saxon is > > incorrect. > > ah, so as i read this, the conflict resolution is that, > even if i have a template that matches "node()", that will > be overridden by the more explicit built-in rule that matches > "comment()" explicitly, whose effect is to do nothing with > the comment. Sometime I see in spec "node", sometime -- "element"... :( > perhaps it's just kay's wording, but in his book at the > bottom of p. 315, he writes (after a list of how template > matching is done): I don't read this book, but I believe in http://www.w3.org/TR/xslt :) > "If there are *no* [my emphasis] templates that match > the selected node, the built-in template for the relevant > node type is used." > > the way i read this is that the "node()" test *would* > match a comment(), and thus my template would be used. > apparently, that's not what he meant, but you can see > how it could be interpreted that way, i hope. node() is not a comment, not PI, not attribute - it just node like comment() is just a comment like processing-instruction() is just PI like -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: Re: needing clarification about XSL transformation
On Mon, 3 Mar 2003 09:07:53 -0500 (EST) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > before this gets even further afield, let me stress that i > *know* how to add extra rules to ensure processing of comments > and processing instructions. what i was baffled by was the > clearly differing behaviour between xsltproc and saxon, using > the following stylesheet (shown in its entirety): > > --- > > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > version="1.0"> > > > > > > > > > > > > > > > > given that i'm not trying to do anything fancy, it > seems to me that using *any* XSL transformation tool > should give me the same output. > > but xsltproc does *not* copy over comments or > processing instructions, while saxon *does*. ergo, > at least one of them is incorrect. With this style xslt-processor must not copy comments and PI. This style not overriding built-in templates, so saxon is incorrect. > so my question is, given that the node() function > is defined as matching comment and processing instruction > nodes, which of these tools is behaving incorrectly? Saxon. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: needing clarification about XSL transformation
On Sun, 02 Mar 2003 14:51:41 -0500 (EST) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > i spent the last hour trying to figure out why i was losing > my PIs and comments in transforming my original XML source file > to another XML format. > > my stripped-down stylesheet to isolate the problem was > > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > version="1.0"> > > > > > > > > > > Try: http://www.w3.org/TR/xslt#built-in-rule IMHO, xsltproc - the best. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: Changes in website 2.4.0
On Thu, 06 Feb 2003 11:33:05 +0100 "Fischer, Oliver" <[EMAIL PROTECTED]> wrote: > Hello, > > I missed the announcement of website 2.4.0. There can I find > it? I looked only at > http://docbook.sourceforge.net/projects/website/ http://sourceforge.net/project/showfiles.php?group_id=21935 -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Website and catalog.xml from distro
Hello, All! I'm use website-2.4.0 and original catalog.xml from distribution and have some questions: 1. It's possible to make long names for resolving location of XSL styles ? Name from this example may be not uniq and this not worked for import styles by full URL: http://docbook.sourceforge.net/release/website/2.4.0/xsl/autolayout.xsl BTW, http://docbook.sourceforge.net/release/website/current points to old website version. 2. In catalog.xml missing chunk-common.xsl - it can be used for customization layers (for example, for my :)) 3 (offtopic :)). Can XSL styles have a PUBLIC id ? -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: links between documents
On Fri, 13 Dec 2002 16:30:10 + Lisa Carey <[EMAIL PROTECTED]> wrote: > Hi folks, > > I have quite a large book broken up into chapters, each of > which is a separate xml file. The book file just uses entities > to tie them all together. Anyway, I want to add some links > between chapters - "You can find out more about x here" sort of > thing - and am wondering how best to do it. works fine > within chapters, but not between them (I get a link, but it > doesn't go anywhere). Do I need to use s? Yes. Look at http://www.sagehill.net/xml/docbookxsl/Olinking.html this works fine. Note: For FO output you should to make 'target.db' like for HTML output. Also note, what 'id' values must be uniq in the all of documents. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: Problems with website 2.3 and the menu
On Mon, 09 Dec 2002 18:35:32 +0100 "Fischer, Oliver" <[EMAIL PROTECTED]> wrote: > %.html: autolayout.xml > $(PROC) -o $@ \ You should specify absolute path for autolayout.xml, for example, add --stringparam autolayout-file "$(shell pwd)/autolayout.xml" \ > /home/plexus/data/website/2.3/xsl/tabular.xsl \ > $(filter-out autolayout.xml,$^) -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
On Tue, 03 Dec 2002 09:19:19 -0600 Paul Grosso <[EMAIL PROTECTED]> wrote: > >In modular set of docbook/xml after processing XInclude some > >documents may to have duplicates of ID. > > True, and this would be a validation error. The same is > true if you used external parsed entities. XInclude does > nothing to solve the ID uniqueness problem. > > In particular, if you reuse the same chunk of XML in two places > in the same document and any element therein contains an ID, > you will end up with a document that is not valid (whether you > use external parsed entities or XInclude). You right. Thanks for the answer. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
On Tue, 03 Dec 2002 07:30:03 -0500 Norman Walsh <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > / Vitaly Ostanin <[EMAIL PROTECTED]> was heard to say: > | DocBook DTD doesn't support 'xml:base' attribute from > | XInclude. > > I think we're planning to fix that[1]. Thanks. > | Yes, this attribute appear to content model, and useful for > | many of included documents - 'xml:base' could be useful for > | getting uniq values of 'id', uniq names of images in > | in the all set of documents. > > Base URIs have no bearing on ID values. ID values used for linking and must be uniq, right? In modular set of docbook/xml after processing XInclude some documents may to have duplicates of ID. I think what using 'xml:base' + 'filename' + 'id' can produce uniq values as result. In this case final value of 'xml:base' can be calculated also from 'xml:base' of parent tags (if there exists relative values). This changes appear 'idref' of and . For images we have a similar problem - files with images must have uniq names. BTW, all html build exist in the one dir (except of olinking schema from Bab Stayton). 'xml:base' could be useful for split documents into separate dirs. Sorry for disturb. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
On Sun, 01 Dec 2002 21:07:45 -0800 Bob Stayton <[EMAIL PROTECTED]> wrote: > It isn't that we (the DocBook Technical Committee) don't > want to add an xinclude element, or that we think it is > not needed. It would be easy to add an xinclude > element to the DTD. But that isn't enough, because > the xinclude element must appear > in content models for it to be useful. > > The problem is that it is hard to write the content models > for all cases of possible xinclude usage. An xinclude can > replace just about any content, including required > elements. That means just about every part of each > element's content model needs to change "somestuff" > to "(somestuff | xinclude )". IMHO, no - document should be valid _after_ xinclude processing, so DTD must not have support for . DocBook DTD doesn't support 'xml:base' attribute from XInclude. Yes, this attribute appear to content model, and useful for many of included documents - 'xml:base' could be useful for getting uniq values of 'id', uniq names of images in in the all set of documents. Now DocBook DTD and stylesheets not have full support of modular documents. PS Sorry for bad English -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: Re: [xml] xsltproc and website.dtd
On Wed, 20 Nov 2002 09:47:10 -0800 Bob Stayton <[EMAIL PROTECTED]> wrote: > There is also the alternate build process for website > using Make rather than pure XSLT. That should avoid > the use of the exists() extension function. See: > > http://docbook.sourceforge.net/release/website/example/buildmake.html > > The example uses xsltproc. Thanks, I know about it - this is not autobuild process. User must create depends.tabular by hand. And this way used Makefile, but all info already exists in layout.xml. Anyway, for build in XML way saving datetime specific info in XML-file would be better. IMHO, XML site must not depend of java or processor extensions. PS Sorry for bad English. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: [xml] xsltproc and website.dtd
On Wed, 20 Nov 2002 10:51:52 +0100 "Fischer, Oliver" <[EMAIL PROTECTED]> wrote: > Hello, > > I spumbled across a problem with Norman Welshes website.dtd and > its xsl style sheets. Those style sheets uses a non-standard > (?) function exists(), which isn't supported by xsltproc, but > by xalan and saxon. IMHO, using non-standart java functions with standart XML and XSLT is not good. > Is there a way to use xsltproc and to avoid the switch to java? Yes, you can simple modify website stylesheets and use xsltproc, but you get update for all pages on each build. Example of customization is attached. PS 2docbook-apps: sorry for the attach -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED] test.xsl Description: Binary data
DOCBOOK-APPS: Re: Olinking support in FO stylesheets
On Thu, 24 Oct 2002 09:29:18 -0700 Bob Stayton <[EMAIL PROTECTED]> wrote: Hello! Sorry for the long time delay! > On Thu, Oct 24, 2002 at 03:41:51PM +0400, Vitaly Ostanin wrote: > > Hello, All! > > > > We use modular documents and linking. > > > > For html output we can to collect targets into database and > > use it for links resolving. > > > > It's possible to add support for to FO stylesheets ? > > Can you be more specific? The FO stylesheets currently do > support olink. Olinks to targets within the current > document (set by $current.docid parameter) have > a fo:basic-link generated and the generated xref text > inserted. Olinks to targets outside the current document just > get the generated xref text, and an optional title > appended if the $olink.doctitle parameter is set. > > What more did you want? I was thing what FO stylesheets doesn't support since I not found param 'collect.xref.targets' in the FO dir. I found my error (and possible error in the docs ;): For building FO output from documents with , I must to create target.db with HTML stylesheets, and after it I can to build output with FO stylesheets. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: Olinking support in FO stylesheets
Hello, All! We use modular documents and linking. For html output we can to collect targets into database and use it for links resolving. It's possible to add support for to FO stylesheets ? PS Sorry for bad English. -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
DOCBOOK-APPS: 'refname' key in Russian
Hello, All! I translate text for 'refname' key in Russian in the source 'ru.xml': http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/gentext/locale/ru.xml Small patch: --- ru.xml.orig 1970-01-01 03:00:52 +0300 +++ ru.xml 2002-09-25 18:49:58 +0400 @@ -112,8 +112,8 @@ - - + + -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
