This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]