dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Last call for top DITA issues
- From: "Jennifer Linton" <jennifer.linton@comtech-serv.com>
- To: "Erik Hennum" <ehennum@us.ibm.com>
- Date: Mon, 20 Feb 2006 10:20:59 -0700
Yes, that sounds good. But wouldn't we get the same amount
of reuse if we did it this way:
<glossentry>
<glossterm>AC</glossterm>
<glossdef
id="ac-air">Air conditioning</glossdef>
<glossdef id="ac-electric">Air
conditioning</glossdef>
</glossentry>
This way people don't have to go through
multiple glossary entries for the same term to figure out which one they want to
produce.
Jen
Jen
Linton
Comtech Services,
Inc.
Senior Consultant and
Web Manager
710 Kipling St. Suite
400
Denver, CO
80215
P:
303-232-7586
F:
303-232-0659
skype:
jenlinton
Hi, Jen:
I think it's a reuse issue. Some information deliverables
might use both ac-air and ac-electric. Others might use one or the other alone.
So, we're better off letting the process collate and format the selected
definitions rather than having writers manually assemble each glossary
entry.
Down the road, one could imagine a process that
1. Builds
a list of terms based on occurrences of <term> within the content
2.
Pulls the definitions for those terms from a pool of available glossary
definitions
3. Collates the definitions by term
4. Formats the definitions
for publication
Thanks,
Erik
Hennum
ehennum@us.ibm.com
"Jennifer Linton"
<jennifer.linton@comtech-serv.com>
"Jennifer Linton"
<jennifer.linton@comtech-serv.com>
02/20/2006 08:54 AM |
|
I may have missed this, but why would we not just have
both definitions in the same entry as the term and apply ids or other clarifying
metadata to each definition?
Jen
Jen Linton
Comtech Services, Inc.
Senior Consultant and Web Manager
710 Kipling St. Suite 400
Denver, CO 80215
P: 303-232-7586
F: 303-232-0659
skype: jenlinton
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Monday, February 20, 2006
9:43 AM
To: Esrig,
Bruce (Bruce)
Cc:
dita@lists.oasis-open.org; Paul Prescod
Subject: RE: [dita] Last call for
top DITA issues
Hi, Bruce:
My apologies for neglecting to clarify the
term concerns -- I think the existing glossary proposal already handles both the
case where the same term has multiple senses:
<glossentry
id="ac-air">
<glossterm>AC</glossterm>
<glossdef>Air
conditioning</glossdef>
</glossentry>
...
<glossentry
id="ac-electric">
<glossterm>AC</glossterm>
<glossdef>Alternating
current</glossdef>
</glossentry>
It would be up to the
processing to collate by term and format definitions on output.
The
proposal also includes a <glsynonym> element to specify synonym terms with
the same meaning.
If one of the themes of DITA 1.1 / DITA 1.0.5 is
enabling books, I'm wondering whether the shortdesc enhancements would be
important for the narrative glue.
Hoping that's
interesting,
Erik Hennum
ehennum@us.ibm.com
"Esrig, Bruce (Bruce)"
<esrig@lucent.com>
"Esrig, Bruce (Bruce)" <esrig@lucent.com>
02/20/2006 03:49 AM |
|
1. How about a simple generalization of task to allow
tables and graphics in parallel with steps.
That would leave the following
compatible extensions for the future:
- the div elements
- nested
steps
2.
For glossary, I'd still like to close on the issue of terms with multiple
senses. This was raised privately with Erik Hennum earlier, but I'd be glad to
discuss it more broadly in case it could easily cause incompatible changes if we
decided to tackle it after a simple glossary mechanism was already
fielded.
Specifically, we have cases where a project uses the same term in
multiple senses, and being able to gloss the correct sense would be really
helpful. For example: AC := i. Air Conditioning, ii. Alternating Current. It's
just an abbreviation, but I can imagine it happening with terms as well. Quick,
define "interface" in a way that is specific enough to indicate how you mean it
in three interesting contexts and yet not ambiguous when glossed. Fun challenge,
right?
The opposite also happens: multiple terms for a single sense. This
might be easy for DITA to handle because of conref.
Best
wishes,
Bruce
====
To merge the threads ... JoAnn Hackos wrote:
Which index-related issues would you prioritize?
- #44 Keep indextermref (or redefine its function)
- #45 Add See, See Also indexing elements
- #45a Add sort order indexing elements
- #45b Add page range indexing elements
I wouldn't leave the others out if we can manage it.
-----Original Message-----
From: Erik
Hennum [mailto:ehennum@us.ibm.com]
Sent: Friday, February
17, 2006 6:39 PM
To: Paul
Prescod
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Last
call for top DITA issues
Hi, Paul:
As Don was pointing out to me today,
the <data> element presumably rides in on the coat tails of
bookmap because the book metadata depends on it, but that should be okay
because <data> is good to go (unless anyone has thought of ways to
improve it while it has been sitting on ice).
Does glossary also
ride in with bookmap as a requirement for having a complete book
story?
Any other hangers on?
Thanks,
Erik
Hennum
ehennum@us.ibm.com
"Paul Prescod"
<paul.prescod@blastradius.com>
"Paul Prescod"
<paul.prescod@blastradius.com>
02/17/2006 03:22
PM |
|
So the current list of proposals is:
#20 Extensible
metadata attributes
* customers ask for it and the current situation
is just not
workable for many
#38 Bookmap / bkinfo
revision
* in widespread quasi-standard use already
* often
requested by customers
#35 Support foreign content vocabularies
such as MathML and SVG
* MathML in particular is very popular, and
has been hacked by
XMetaL customers
* graphic (image) scaling
improvements (no issue number?)
Now is the time to jump in with
any other DITA 1.1 issue that you
consider absolutely urgent and
therefore a candidate for "early
release".
And then SOME
STILL-TO-BE-RANKED SUBSET of indexing requirements:
- #44 Keep
indextermref (or redefine its function)
- #45 Add See, See Also
indexing elements
- #45a Add sort order indexing elements
- #45b
Add page range indexing elements
I'll send another email about
ranking the indexing requirements.
Paul Prescod
[attachment "graycol.gif" deleted by Erik Hennum/Oakland/IBM]
[attachment "ecblank.gif" deleted by Erik Hennum/Oakland/IBM]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
