Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
On Sun, Dec 01, 2002 at 09:07:45PM -0800, Bob Stayton wrote: On Sun, Dec 01, 2002 at 11:38:07AM +0100, Yann Dirson wrote: My opinion is still that we need to be able to validate before, and that does not prevent to validate after as well. [...] Yes, and IMHO not adding the xinclude elements to the DTD will effectively constraint the use case of DocBook. 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. [...] Consider also that xincludes are very much like system entity references. A system entity reference can replace just about any content in a document. And everyone seems to accept the fact that the document cannot be validated until the system entities are resolved. Validating XML editors must be able to resolve system entities to be truly validating. Why not extend that mechanism to resolve xincludes? It seems that the hard part has already been done, now they just need to handle some different syntax for specifying the included text. I would just like to add the point that in most cases where XInclude is used to remplace external parsed entities, while you cannot validate the top document, one can still validate the included documents. I think that's the key point for usability, in the sense that if the document is being worked my multiple authors, each of them can actually validate their piece while they work. And if they use XInclude at their level, they should have no trouble to validate their subtree after XInclude processing. I'm actually quite pleased with the way XInclude is getting used (at least in the community I follow), I was thinking the ability to validate subdocument would be the key reason to use it, but in fact the capability to include text part like code examples coming from external files untouched seems to be the most used feature here, parse=text is a winner :-) 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/
DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
On Sun, 01 Dec 2002 21:07:45 -0800 Bob Stayton [EMAIL PROTECTED] wrote: skipped/ 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 xi:include/. 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 graphics in the all set of documents. Now DocBook DTD and stylesheets not have full support of modular documents. PS Sorry for bad English skipped -- Regards, Vyt mailto: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: Doubled page numbers with preface
Ian Castle wrote: There is an extra patch somewhere to cope with that. The rule is to start renumbering when you get to the main thing. However, you've got more than main thing ..I had a patch for that floating around somewhere.. but it isn't too hard to fix.. What is hard is coming up with a nice general rule - because there isn't really anything that says this is where we want to set numbers back to 1... It could be the first chapter, or the first preface or the first foreword So why not adding a new parameter, say %restart-page-numbering-at%, holding the element for which first occurence in document would trigger renumbering. As a fallback (element absent from doc) start numbering from 1 on titlepage. Also, what if someone wants same numbering for whole doc? .. Actually, I suppose it could be done.. but it was too hard to fit into the existing structure. On Fri, 2002-11-29 at 14:54, Camille Bégnis wrote: Hi, I have noticed the print dsssl backend (1.77) numbers first pages i, ii, ... (starting from book titlepage) and then restart i, ii, ... on preface. Is this intended? Camille.
Re: DOCBOOK-APPS: Problem using profiling stylesheets with xsltproc
On Sat, Nov 30, 2002 at 08:25:11PM -0600, John Himpel wrote:
Hi,
When I use the following command:
xsltproc \
--catalogs \
--nonet \
--xinclude \
--output ./html/${1}.html \
--stringparam profile.condition FullRel \
file:///usr/share/sgml/docbook/xsl-stylesheets/html/profile-docbook.xsl
\
${1}.xml
on the following file:
?xml version='1.0' encoding='utf-8' ?
!DOCTYPE article PUBLIC '-//OASIS//DTD DocBook XML V4.2//EN'
'http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd'
article
titleTitle/title
section condition=FullRel
titleFullRel/title
paraFullRel para/para
/section
section condition=UpdateRel
titleUpdateRel/title
paraUpdateRel para/para
/section
/article
I get the following output:
runtime error: file
file:///usr/share/sgml/docbook/xsl-stylesheets/html/profile-docbook.xsl
line 219 element apply-templates
xsltApplyOneTemplate: loop found ???
try increasing xsltMaxDepth (--maxdepth)
Templates:
#0 name * name head.keywords.content
#1 name * name head.keywords.content
#2 name * name head.keywords.content
#3 name * name head.keywords.content
#4 name * name head.keywords.content
#5 name * name head.keywords.content
#6 name * name head.keywords.content
#7 name * name head.keywords.content
#8 name * name head.keywords.content
#9 name * name head.keywords.content
#10 name * name head.keywords.content
#11 name * name head.keywords.content
#12 name * name head.keywords.content
#13 name * name head.keywords.content
#14 name * name head.keywords.content
Variables:
Using the following versions:
LIBXML2 2.4.23 (libxml2-2.4.23-1 from RedHat)
LIBXSLT 1.0.19 (libxslt-1.0.19-1 from RedHat)
DTD 4.2.1 (docbook-dtds-1.0.14 from RedHat)
XSL Stylesheets 1.57.0 (docbook-style-xsl-1.57.0-2 from RedHat)
I don't know if:
a) I'm doing something wrong
b) The stylesheets have a problem
c) XSLTPROC has a problem
You aren't doing anything wrong. But you can work around
it by setting the stylesheet parameter inherit.keywords to
zero.
I think it is a bug in xsltproc.
The problem is that in the template named
head.keywords.content, there is a recursive
call to the same template.
xsl:if test=$inherit.keywords != 0 and parent::*
xsl:apply-templates select=parent::* mode=head.keywords.content/
/xsl:if
In profile-docbook.xsl, this recursive template goes into
an infinite loop. The same template is in docbook.xsl, and
it does not go into an infinite loop. Nor does Saxon go
into an infinite loop when processing with
profile-docbook.xsl.
The loop should stop when it reaches the root node.
xsltproc keeps going with article, somehow thinking
the parent of article is article.
Since this doesn't occur with the same template in
docbook.xsl, it would appear that the difference is that
profile-docbook.xsl is operating on a exslt nodeset. But I
can't explain it any further than that.
Bob Stayton 400 Encinal Street
Publications Architect Santa Cruz, CA 95060
Technical Publications voice: (831) 427-7796
The SCO Group fax: (831) 429-1887
email: [EMAIL PROTECTED]
