[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook-apps] Alternative to internal entities?
The problem is similar to that of named character references. You'd like to have a shorthand for small text snippets, but don't want the legacy of DOCTYPE declarations. Here's a semi-official W3C statement about the need for named character entities without DOCTYPEs: http://www.w3.org/XML/Core/2002/10/charents-20021023 Quite a heated debate followed http://lists.xml.org/archives/xml-dev/200210/threads.html#01795 http://lists.xml.org/archives/xml-dev/200211/threads.html#00000 Anyway, there's been a couple of proposals for DOCTYPE-less named character entity references, e.g.: http://lists.xml.org/archives/xml-dev/200310/threads.html#00424 http://lists.xml.org/archives/xml-dev/200310/threads.html#00566 I wonder if someone has managed to create a 'bestiary' of proposals for light-weight named entities? kind regards Peter Ring -----Original Message----- From: Michael Smith [mailto:smith@xml-doc.org] Sent: 28. april 2004 09:16 To: docbook-apps@lists.oasis-open.org 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]