dita — archive

[Dana Spradley]

 MHonArc v2.5.0b2 -->

















dita message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Re: [dita] Keywords in DITA (example)




From: Dana Spradley <dana.spradley@oracle.com>
To: "Esrig, Bruce (Bruce)" <esrig@lucent.com>
Date: Wed, 09 Mar 2005 16:43:45 -0800










I agree wholeheartedly, Bruce.


As here: we've fallen into ambiguity on several fronts that resulted in
some confusion.


I think we need to restrict <keyword> to the DocBook sense: a
word that, if you searched on it, you'd be happy to find this topic. To
be used either inline if you like - and subclassed if you like that -
or as metadata in the <keywords> element.


As for indicating that something is a keyword in the technical sense in
a programming language - and not a keyword of this topic itself - so
that it can be formatted differently on output or otherwise processed
semantically for some reason, <kwd> would seem to be the
likeliest condidate - with "Compare" references between it and
<keyword> a necessity.


--Dana




Esrig, Bruce (Bruce) wrote:


  
  
  
  
1. Yes, just so. We have wider and wider
scopes of application for the markup language.
  
 
  
Syntax diagrams;
  
language that appears in programs;
  
language, controls, and other screen
phenomena that appear in user interfaces;
  
and conceptual language that governs how
our audiences think about the work that they perform.
  
 
  

  
2. We
have many ways of marking up
identifiers and other expressions.
  
There are significant differences in
purpose among them,
  
and in
some places, those purposes interact. So we need to discuss those different purposes explicitly
  
and define
and organize the markup in
a way that reflects those different purposes.
  
 
  
If we do not explicitly design
around the purposes, we instead reason about the effect that we can
achieve with each element.
  
The clashes among various
combinations of effects are leading to the clashes about how to use the
markup,
  
and what to allow and disallow.
  
 
  
3. As a result of the
examination done in item 2, we would have specific elements,
  
as we do now, plus a design that
explains why those elements cover our needs,
  
and that systematizes any future
structural specializations and any proposals for similar new elements.
  
 
  
Best wishes,
  
 
  
Bruce