RE: DOCBOOK-APPS: XInclude doesn't validate with xmllint
Good point! Thanks. kind regards Peter Ring -Original Message- From: Bob Stayton [mailto:[EMAIL PROTECTED]] Sent: 3. oktober 2002 19:27 To: Peter Ring; [EMAIL PROTECTED] Subject: Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint When I first read this, the final sentence suggested that xi:fallback is required. But that sentence is qualified by the first paragraph, which says fallback is invoked only when a resource error occurs (when the xinclude URI can't be resolved). I realize you may want to enforce having a fallback element using the DTD, and that's fine. But when you do that, you get no indication from the processor that your intended xinclude failed. You have to scan the output. So in a publishing environment, I'd rather not have the fallback elements so that it is impossible to produce output with missing content. A nice combination might be to declare a stock fallback element with an entity, and insert that entity in each xinclude so that draft processing can proceed. Then for final processing declare the entity as empty so fallback is removed.
Re: DOCBOOK-APPS: How do I get an email in verso titlepage?
On Thu, Oct 03, 2002 at 04:08:59PM -0500, Dennis Grace wrote: > I'm working with > > DocBook XSL 1.55.0 > xsltproc (libxmil2 2-4.24/libxslt 1.0.20) > PassiveTeX 1.19 > > My titlepage.xml file has within the ="article">, and the resulting articles include the portion of the > data. > > So why is it that, although I have the tag within the > for the recto and verso, neither one prints > the address? > > Anyone know how I can get the email to show in the recto of the > titlepage? I've been spending quite some time going through the FO titlepage templates to understand how they work so I can document them. I'm still sorting out how to present this rather complicated and flexible system of templates. But to solve your immediate problem, the machinery eventually calls this template in fo/titlepage.xsl: The only children of author it processes are name and affiliation. You'll need to create a customized version of this template by adding a line similar to "affiliation" for email. There is no template matching "email" in "titlepage.mode", so you'll have to create one of those too. Let me know if this works or not. -- 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: How do I get an email in verso titlepage?
I'm working with DocBook XSL 1.55.0 xsltproc (libxmil2 2-4.24/libxslt 1.0.20) PassiveTeX 1.19 My titlepage.xml file has within the , and the resulting articles include the portion of the data. So why is it that, although I have the tag within the for the recto and verso, neither one prints the address? Anyone know how I can get the email to show in the recto of the titlepage? Thanks. Dennis Grace Information Developer IBM Linux Technology Center (512) 838-3937 T/L 678-3937 cell: (512)-296-7830 [EMAIL PROTECTED] There are only 10 kinds of people in the world: those who understand binary and those who don't.
Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint
On Thu, Oct 03, 2002 at 11:36:59AM +0200, Peter Ring wrote: > Here's how we do it. > > First I'd like to lobby for keeping your local copies of DTDs and > stylesheets as a mirror or cache of the canonical URLs. This makes mapping > URL system identiers to local system identifiers trivial, and also makes > maintenance a no-brainer. BTW, the catalog.dtd that you get from > http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd is > version 1.7, while the one in the spec is version 1.9. So much for entity > resolution over the net ;) > > xml/ > catalog.xml # master catalog that delegates > # public, uri, and system identifiers > # to catalogs below > docbook.sourceforge.net/ > release/ > xsl/ > catalog.xml > 1.48/ > 1.55.0/ > www.magnus.dk/ > docbook/ > xml/ > catalog.xml > 1.0/ > 1.1/ > 1.3/ > xsl/ # put generally useful xsl ># customization here > www.oasis-open.org/ > committees/ > entity/ > release/ > 1.0/ > docbook/ > xml/ > catalog.xml > configerror.txt > ebnf/ > 1.0/ > 1.1CR1/ > htmlforms/ > 1.1/ > mathml/ > 1.0/ > simple/ > 1.0CR3/ > 4.1.2.5/ > svg/ > 1.0CR1/ > 4.1.2/ > 4.2/ > xmlcharent/ > catalog.xml > 0.3/ > www.w3.org/ > TR/ > html4/ > xhtml1/ > catalog.xml > DTD/ > MathML2/ > catalog.xml > dtd/ > > Our DocBook customization adds as a valid element in a number > of places. This was quite messy until DocBook XML 4.2. The general idea is > to add the element to to %local.whatever.class; so that > becomes valid in context. > > I've left out some additional customization that includes EBNF support; it's > still rather messy if you don't want to use the released wrapper DTDs. > Anyway, here we go: > > > > >(xi:fallback) > > >href CDATA #REQUIRED > parse (xml|text) "xml" > encoding CDATA #IMPLIED > xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"; > > >ANY > > >xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"; > > > > >"|xi:include" > > > > >"|xi:include" > > > > >"|xi:include" > > > > >"-//OASIS//DTD DocBook XML V4.2//EN" > "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"; > > > %DocBookDTD; Thanks for this great detail. One little item... I've noticed in your example and the XInclude Candidate Recommendation that the content model for xi:include is: Shouldn't there be a question mark to make xi:fallback optional? The spec [1] seems to permit this. Here is the relevant part: 4.4 Fallback Behavior XInclude processors must perform fallback behavior in the event of a resource error, as follows: If the [children] of the xi:include element information item in the source infoset contain exactly one xi:fallback element, the top-level included items consists of the information items corresponding to the result of performing XInclude processing on the [children] of the xi:fallback element. It is a fatal error if there is zero or more than one xi:fallback element. When I first read this, the final sentence suggested that xi:fallback is required. But that sentence is qualified by the first paragraph, which says fallback is invoked only when a resource error occurs (when the xinclude URI can't be resolved). I realize you may want to enforce having a fallback element using the DTD, and that's fine. But when you do that, you get no indication from the processor that your intended xinclude failed. You have to scan the output. Not having a fallback element produces a fatal error if the xinclude cannot be resolved. That may be desirable behavior, depending on the application: 1. In a web application, it is more important that the process complete, and fallback is better than failure. 2. In a publishing application where you are preparing final camera-ready copy, it is more important that the xincludes succeed, and any fallback is not acceptable. Then failure is better than fallback. Fix the problem and run it again until it is right. So in a publishing environment, I'd rather not have the fallback elements so that it is impossible to produce output with missing content. A nice combination might be to declare a stock fallback element with an entity, and insert that entity in each xinclude so that draft processing can proceed. Then for final processing declare the entity as empty so fallback is removed. So that's why I think in some situations the xi:fallback element needs to be declared optional in the DTD. [1] XML Inclusions (XInclude) Version 1.0 W3C Candidate Recommendation 17 September 2002 http://www.w3.org/TR/xinclude/#fallback Bob Stayton
DOCBOOK-APPS: Re: XInclude doesn't validate with xmllint
Peter Ring <[EMAIL PROTECTED]> writes: > First I'd like to lobby for keeping your local copies of DTDs and > stylesheets as a mirror or cache of the canonical URLs. There is no such thing like a canonical URL. Use a catalog and map PUBLIC identifiers to local resources. Note, PSGML implements a concept how to map PULIC identifiers to local resources and to read it from there without a catalog. -- [EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home): | http://www.suse.de/~ke/ | ,__o Free Translation Project:|_-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)
RE: DOCBOOK-APPS: XInclude doesn't validate with xmllint
Oops, correction to the explanation: -Original Message- From: Peter Ring [mailto:[EMAIL PROTECTED]] Sent: 3. oktober 2002 11:37 To: [EMAIL PROTECTED] Subject: RE: DOCBOOK-APPS: XInclude doesn't validate with xmllint Here's how we do it. Our DocBook customization adds as a valid element in a number of places. This was quite messy until DocBook XML 4.2. The general idea is to add the element to to %local.whatever.class; so that becomes valid in context. ^ should be: becomes valid wherever is valid.
RE: DOCBOOK-APPS: XInclude doesn't validate with xmllint
Here's how we do it. First I'd like to lobby for keeping your local copies of DTDs and stylesheets as a mirror or cache of the canonical URLs. This makes mapping URL system identiers to local system identifiers trivial, and also makes maintenance a no-brainer. BTW, the catalog.dtd that you get from http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd is version 1.7, while the one in the spec is version 1.9. So much for entity resolution over the net ;) xml/ catalog.xml # master catalog that delegates # public, uri, and system identifiers # to catalogs below docbook.sourceforge.net/ release/ xsl/ catalog.xml 1.48/ 1.55.0/ www.magnus.dk/ docbook/ xml/ catalog.xml 1.0/ 1.1/ 1.3/ xsl/ # put generally useful xsl # customization here www.oasis-open.org/ committees/ entity/ release/ 1.0/ docbook/ xml/ catalog.xml configerror.txt ebnf/ 1.0/ 1.1CR1/ htmlforms/ 1.1/ mathml/ 1.0/ simple/ 1.0CR3/ 4.1.2.5/ svg/ 1.0CR1/ 4.1.2/ 4.2/ xmlcharent/ catalog.xml 0.3/ www.w3.org/ TR/ html4/ xhtml1/ catalog.xml DTD/ MathML2/ catalog.xml dtd/ Our DocBook customization adds as a valid element in a number of places. This was quite messy until DocBook XML 4.2. The general idea is to add the element to to %local.whatever.class; so that becomes valid in context. I've left out some additional customization that includes EBNF support; it's still rather messy if you don't want to use the released wrapper DTDs. Anyway, here we go: http://www.w3.org/2001/XInclude"; > http://www.w3.org/2001/XInclude"; > http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"; > %DocBookDTD; --- kind regards Peter Ring -Original Message- From: Bob Stayton [mailto:[EMAIL PROTECTED]] Sent: 3. oktober 2002 06:49 To: John Himpel; [EMAIL PROTECTED] Subject: Re: DOCBOOK-APPS: XInclude doesn't validate with xmllint > On Tue, Oct 01, 2002 at 09:35:16PM -0500, John Himpel wrote: > > > > I am trying to validate two xml files using the modular document > > technique that Bob Stayton shows in www.sagehill.net. > From: [EMAIL PROTECTED] > Hi John > > We got XInclude to work as follows: > > 1) All of our DocBook documents which use XInclude (and > that's almost all of them) start like this: > > = > > [ > > %xinclude; > ] > > > > > CDL Step-By-Step Instructions > > ... > > > 4) Finally, here is our XInclude DTD, culled from the spec: > = > > > > xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude";; > href CDATA #REQUIRED > parse (xml|text) "xml" > encoding CDATA #IMPLIED > > > > xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude";; > > Well, I don't think your article will validate with just this extension to the DocBook DTD. It adds the xi:include element to the collection of elements, but it doesn't put it into any content models of the DocBook elements. In the example, the element is placed after the element. But the content model doesn't mention , so it won't validate. Only after the xi:include is replaced with its content will it validate. I started to extend the DocBook DTD to permit xi:include, but I think it is kind of impossible (except for maybe Norm 8^). The xi:include element can replace *any* element or group of elements, so the content models of every element would get hopelessly complex. 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]
