Re: [docbook-apps] Alternative to internal entities?

[Michael Smith <smith@xml-doc.org>]

Bob Stayton <bobs@sagehill.net> writes:

> Another approach is to let the stylesheet resolve a special element,
> something like this:
> 
> <phrase role="entity">wrkngName</phrase>

[...]

> The nice thing about this approach is that you don't have to mess with the
> DTD to get such text expansion.  You define the expansion by the stylesheet
> at processing time.

I wonder whether it might be better to use a processing instruction
instead. That way, you wouldn't have to worry about whether whatever
element name you chose happened to valid at the point in the document
where you wanted to include the entity.

Also, I wonder if it could be abstracted a little further by not
including the actual element content in the stylesheet, but just having
the stylesheets provide a general mechanism for resolving these
"entities" based on there names and on a URI.

What I mean is, the PI would look something like this:

  <?entity name='wrkngName' uri='http://foo.com/entities.xml'?>

And then the corresponding content for that "entity" in the file
referenced by the URI would look like this:

 <entity name='wrkngName'>My Real Product Name</entity>

   or

 <entity name='wrkngName'
   ><application>My Real Product Name</application></entity>

Doing it that way, the stylesheets could then just have a general
mechanism that says:

  If you find a PI with the target 'entity':
  
  1. Find the file referenced by the value of the 'uri' attribute for
     that PI.

  2. Look through that file for an 'entity' element having a 'name'
     attribute whose value is the same as the value of the 'name'
     attribute for that PI.

  3. Replace the PI with whatever you find.

Does that sound doable?

If it'd be possible to have the stylesheets process the URI in a PI in
the same way that they process URIs in <xsl:include> and <xsl:import>
elements, then doing it that way would ensure that (1) you wouldn't need
to distribute the 'entities' file along with your doc instances (you
could just use a remote http or ftp address), and (2) you could, if you
wanted to, set up your catalogs so that if you use a remote URI, it'll
get resolved to a local resource.

>  Validation is another issue, of course.

Yeah, but you could always do two-pass processing: First, process the
doc instance to resolve the 'entities', then validate that, then run it
through the normal XSLT stylesheets.

  --Mike

> ----- Original Message ----- 
> From: "Paul A. Hoadley" <paulh@logicsquad.net>
> To: <docbook-apps@lists.oasis-open.org>
> Sent: Tuesday, April 27, 2004 1:21 AM
> Subject: [docbook-apps] Alternative to internal entities?
> 
> 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