OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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


"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?

PGP signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]