docbook: Thread: Element aliasing?

I know this is a bit off-topic, but I'm running out of avenues to
explore. It's rare that Google fails me, but my ignorance of XML
terminology is likely the real culprit.

I'd like to create new elements that are aliases to existing ones in
DocBook. As an example, let's say that I'm referencing protocols such
as TFTP, and I'm not certain how I want to mark those up. <acronym> is
a possibility, although I'd like to leave the option of creating my
own <protocol> element at a later date.

So I'd like to create a protocol element which starts out as an alias
to acronym, so that if I find another element that exists in DocBook
already which meets my needs, I can switch the alias over to it, and
if I don't, I can define protocol as a real element if and when
desired.

I've been trying to fake it with constructs like this:

   <!ENTITY % protostart "<acronym>">
   <!ENTITY % protoend   "</acronym>">

   <!ENTITY % tftp "%protostart;TFTP%protoend;">

But besides its inherent ugliness, that doesn't seem to fly well with
my current parsers.

Is there a suggested way to handle this type of situation? Is one of
my fundamental assumptions awry? Or is there another list where I
should take this up?

Thanks.

-John Daily
####@####.####

On 11 Jan 2001 09:50:11 -0500, John R. Daily wrote:
> I know this is a bit off-topic, but I'm running out of avenues to
> explore. It's rare that Google fails me, but my ignorance of XML
> terminology is likely the real culprit.
> 
> I'd like to create new elements that are aliases to existing ones in
> DocBook. As an example, let's say that I'm referencing protocols such
> as TFTP, and I'm not certain how I want to mark those up. <acronym> is
> a possibility, although I'd like to leave the option of creating my
> own <protocol> element at a later date.

ok, I snipped the rest of this mail.  We had a similar discussion on the
GNOME list in March of this year.  The last couple of lines in this mail
are the start of the thread.
http://mail.gnome.org./archives/gnome-doc-list/2000-March/msg00042.html
No conclusions, really, but some good ideas.  Enjoy,

    Greg