[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Alternative to internal entities?
I've also moved to using nXML and facing the same problem. Having to include a DOCTYPE declaration & internal DTD subset kind of defeats the purpose of using nXML and RELAX NG to begin with. RELAX NG is intended to be purely about validation. Resolution of entities seems to me to be something more appropriately handled during the processing stage. Seems like we need a better, standard, way of referencing "entity" content in a doc instance (one that doesn't rely on having an internal DTD subset in the doc), and for resolving the references during processing. But unless/until the community can come up with a standard for it, using PIs and processing those with XSLT seems like a possible alternative. The XSLT stylesheet for processing the 'entities' could be included in the standard DocBook XSLT stylesheet distro but wouldn't need to be tied to DocBook or any specific vocabulary; it'd just be designed to look for PIs in a certain form; for example: <?entity name='wrkngName' uri='http://foo.com/entities.xml'?> Of course it's a lot more verbose than &wrkngName; , but anybody working with XML and DocBook ought to already be accustomed to verbosity of the markup. --Mike "Paul A. Hoadley" <paulh@logicsquad.net> writes: > Hello, > > Obviously this is not a DocBook-specific question, but are there any > alternatives to internal entities for macro-like text substitution? I > have pretty much completely moved from PSGML to nxml-mode for DocBook > editing, and I would like to try and eliminate use of DOCTYPEs. > However, I quite like declaring entities in the internal subset for > simple text substitution. Is there a lighter-weight alternative to > XInclude? For one application, I used an entity to refer to the > working name for a software package in case it changed. It seems a > bit excessive to XInclude a separate file to expand what would be, > say, a two character entity to the name of a software package. Is > there an alternative?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]