wrote:
I see two problems with that:
1. You might want two (or two hundred)
different contexts
to point to the same topic. You'd have to invent elements just to
attach
an ID to, which is what you'd be doing anyway if you were to use
<resourceid>
or some other element that is customarily used for hooks.
Even if I have two hundred different contexts that point to the same
topic, why would I need more than one "hook"? Can't multiple GUI
contexts reference the same ID? Even in conventional help authoring
tools, I would not create more than one MapID for any given topic.
2. The id attribute is used
for other purposes too
(such as the target for an <xref>). How would you distinguish
IDs-as-hooks from IDs-not-as-hooks? If it's by the content of the
attribute, then turning an existing non-hook ID into a hook-ID would
mean
changing the attribute value, which would break other links to that
element.
I don't see how this distinction is important. The ID is a label. It
can be used to associate cross-references with their targets, to
associate GUI contexts with topics, or both. I don't see how the role
of the ID affects its possible value.
Let me know what I'm missing. :-)
-Alan
Obviously there are technical solutions to
both of
those problems, but my opinion is that those solutions are more effort
than having a dedicated element.
--
Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne
