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?


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]