[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Abbreviation or aliases
Mike, Dave, This seems like a sensible way to go, but what if you have more than 200 or so entities? I'm working on a document that uses at least this many, and they are re-generated from a database extract (along with the entity driver files)... I have been happy with this approach to date but now I'm working in a .NET environment, and I'll have to move from DTD to schema and/or schema + internal DTD subset... Any other thoughts on this? Chris Chris Johnson Web Developer Capilano College North Vancouver, Canada 604.986.1911 ext. 3455 cjohnson@capcollege.bc.ca >>> Michael Smith <smith@xml-doc.org> 05/05/2005 5:59:30 pm >>> Dave Pawson < davep@dpawson.co.uk > writes: > On Thu, 2005-05-05 at 16:21 +0200, Jacques Foucry wrote: > > Is it possible to use abbreviation or kind of aliases in docbook. [...] > Yes. If using xml > > <!DOCTYPE book SYSTEM "path/to/dtd"[ > <!ENTITY ME2PP " Microsoft Excel 2005 for Palm Pilot"> > > ]> > > later > > <para> > Working with &ME2PP; we do ...... It's also possible to use processing instructions as pseudo-entities, like this: <article> <title>PI pseudo-entity test</title> <simpara>This is test of expanding a "ME2PP" pseudo-entity into "<?e ME2PP ?>" using XSLT. The example XSLT stylesheet imports the <filename>chunk.xsl</filename> driver from the <?e DBXSL ?> package, but you can have it import the <filename>docbook.xsl</filename> driver or some other driver instead. The XSLT stylesheet will output a warning about any pseudo-entity it doesn't recognize -- such as this one: <?e HOGE-MOGE ?></simpara> </article> and then, to expand those pseudo-entities, process your doc instances with an XSLT stylesheet like this: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl"/> <xsl:template match="processing-instruction('e')[normalize-space() = 'ME2PP']"> <xsl:text>Microsoft Excel 2005 for Palm Pilot</xsl:text> </xsl:template> <xsl:template match="processing-instruction('e')[normalize-space() = 'DBXSL']"> <xsl:text>DocBook XSL Stylesheets</xsl:text> </xsl:template> <xsl:template match="processing-instruction('e')"> <xsl:message>Warning: Unrecognized pseudo-entity: <xsl:value-of select="normalize-space()"/></xsl:message> <xsl:text>[Unrecognized pseudo-entity: </xsl:text><xsl:value-of select="normalize-space()"/><xsl:text>]</xsl:text> </xsl:template> </xsl:stylesheet> Yeah, I know it's a lot more verbose than using real entities. But not wanting to have to put a doctype declaration/internal DTD subset in every doc instance (don't otherwise need that if you use RELAX NG-driven tools for authoring a validation), and lacking any standard for the equivalent of entities in the post-DTD world, I've not found any better way to do it. --Mike -- Michael Smith http://logopoeia.com/ http://www.oreillynet.com/pub/au/890
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]