[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Entities references vs. XRef as a way to manage changing glossary
On Tue, Jul 29, 2003 at 03:28:44PM -0400, Taro Ikai wrote: > > I'm not clear on why entity references don't work here. > > In general, you want the entity references to resolve > > in the output. So I presume you are doing an initial > > transformation of the XML to XML, in which you want to leave > > the entity references unresolved. Is that correct? > > > > If so, perhaps you could code the original entity references > > as "&entityname;". This would transform to "&entityname;" > > after the first stage, and be available downstream. > > But perhaps I'm not understanding what you want to do. > > > > I want to defer the resolution of entity references (or > other comparable means of text parameterization) until > I am ready to run it through one of the docbook-xsl stylesheets > for rendering. > > There are several reasons. Among which: > > 1) I want to use my own XSL stylesheets to transform the > document structure, before I run one of the docbook-xsl > stylesheets. > > At this point, I might check the document into CVS. > I don't want to check in a document where the entity > references are already resolves. > > 2) Likewise, I sometimes want to import the document > into FrameMaker. If the references are resolved, then > FrameMaker will not be able to import the references as > FrameMaker variable references, and consequently, I > cannot export the references back as entity references > in DocBook. > > 3) I want to use XSL or xmllint to canonicalize the document > before I check it into CVS. Here again, I don't want to > lose the text parameterization in my document. > > > Xref will only connect to id values in the current document. > > You would have to use olink to link to an external document. > > But in either case, you will end up with an active > > link associated with the text. I'm not sure that is > > what you want. > > I am aware of that olink produces an active link. I don't quite > understand the full scope of goals associated with olink. I do > not want to get the active link, but I can't think of another > way to parameterize the text references that survives XSLT > transformation. > > From my brief experiment with : > > <olink targetdocent="...">text</olink> > > and htmlhelp.xsl, I got something like: > > <a href="/cgi-bin/olink?sysid=">text</a> > > Why do I get this? I don't think HTML Help project can > run cgi programs. That is the original olink mechanism. There is a new olink mechanism that doesn't use entities. See this reference for a full description. http://www.sagehill.net/docbookxsl/Olinking.html The new olink can work for your purposes. If a target datafile has a matching entry (targetdoc and targetptr) for an olink, and the @href attribute on the entry exists but is empty, then you will get the olink text with no hot link. You could generate the target datafile for the glossary entries using the DocBook stylesheet, then do an identity transform on it that just changes the href attributes to be blank. Olinks should survive all of your transformations, since only the DocBook XSL stylesheets know how to resolve them. -- 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: bobs@sco.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]