docbook-apps

Hello Everyone,

I am creating a three-level index using default primary/secondary/tertiary
elements. Several items are synomyms so I use the 'see' element for the
topic redirection. But in few cases I'd like to point the user to the second
level topic instead to the primary as that primary doesn't exist (and I
don't plan to include it, see details below).

But now I see if it is necessary to distinguish the level of the see element
content, I have to use some system. What do you think, is something like
'primary, secondary' feasible?

Here is an example:
scripting API
- arrays
- - one dimensional, see scripting API, lists
- - two dimensional, see scripting API, tables
- lists, 10, 12-16
- tables, 18

My effort to use the secondary element as the target is to keep the user in
the place where he currently is. My index is quite huge and I think it
wouldn't be very convenient to point the user to the primary several pages
back.
And because of complexity of the current index I don't want to add another
primaries there.

I am even thinking to support something like this in the DocBook schema -
add some linkend attribute to the see element and place there, optionally id
of needed index entry. This link would be automatically (in XSLT) resolved
to the appropriate text, according to the used level:
See primary
See primary, secondary
See primary, secondary, tertiary

But I don't know if somebody else need something like this ;-)

Regards,
Jan

The DocBook 5 web page that describes (CALS) tables
(http://www.docbook.org/tdg5/en/html/cals.table.html) says:
This table element identifies a formal table (one without a title).
Isn't that a typo? Shouldn't it say "one with a title"? (The "synopsis"
and "children" both mention a

honyk [mailto:j.tosovsky@email.cz] wrote:

> I am even thinking to support something like this in the DocBook schema -
> add some linkend attribute to the see element and place there, optionally
> id
> of needed index entry. This link would be automatically (in XSLT) resolved
> to the appropriate text, according to the used level:
> See primary
> See primary, secondary
> See primary, secondary, tertiary


This seems like quite a reasonable request to me. In fact, I had never before looked closely at the content model of <see>, but it genuinely surprises me that it uses text instead of an ID as the target. That seems very non-structured-authoring-like.


*************************
Rob Cavicchio
Principal Technical Writer
EMC Captiva
EMC Corporation
10145 Pacific Heights Boulevard, 6th Floor
San Diego, CA 92121-4234

P: (858) 320-1208
F: (858) 320-1010
E: cavicchio_rob@emc.com

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.
 

Cavicchio_Rob@emc.com wrote:
> honyk [mailto:j.tosovsky@email.cz] wrote:
>
>> I am even thinking to support something like this in the DocBook schema -
>> add some linkend attribute to the see element and place there, optionally
>> id
>> of needed index entry. This link would be automatically (in XSLT) resolved
>> to the appropriate text, according to the used level:
>> See primary
>> See primary, secondary
>> See primary, secondary, tertiary
>
>
> This seems like quite a reasonable request to me. In fact, I had never before looked closely at the content model of <see>, but it genuinely surprises me that it uses text instead of an ID as the target. That seems very non-structured-authoring-like.

But to what should such ID link? If you would like to link to indexterms
in document you will have to add IDs to indexterms, but such ID should
be given only to one occurrence of particular indexterm. Then you will
have to manage mapping to IDs of anchors generated in index.

Of course this can be done, but I think that matching done on actual
index terms much be simpler from authoring point of view than managing
all those IDs.

But anyway you can use <xref/> inside <see> element and customize
stylesheets to do something sensible with it.

Jirka

--
------------------------------------------------------------------
Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
------------------------------------------------------------------
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Jirka Kosek [mailto:jirka@kosek.cz] wrote:

> Cavicchio_Rob@emc.com wrote:
> > honyk [mailto:j.tosovsky@email.cz] wrote:
> >
> >> I am even thinking to support something like this in the DocBook schema
> -
> >> add some linkend attribute to the see element and place there,
> optionally
> >> id
> >> of needed index entry. This link would be automatically (in XSLT)
> resolved
> >> to the appropriate text, according to the used level:
> >> See primary
> >> See primary, secondary
> >> See primary, secondary, tertiary
> >
> >
> > This seems like quite a reasonable request to me. In fact, I had never
> before looked closely at the content model of <see>, but it genuinely
> surprises me that it uses text instead of an ID as the target. That seems
> very non-structured-authoring-like.
>
> But to what should such ID link? If you would like to link to indexterms
> in document you will have to add IDs to indexterms, but such ID should
> be given only to one occurrence of particular indexterm. Then you will
> have to manage mapping to IDs of anchors generated in index.

This would not be so different from the way <footnote> and <footnoteref> work, which seem fine to me.


> But anyway you can use <xref/> inside <see> element and customize
> stylesheets to do something sensible with it.

I like that idea.


*************************
Rob Cavicchio
Principal Technical Writer
EMC Captiva
EMC Corporation
10145 Pacific Heights Boulevard, 6th Floor
San Diego, CA 92121-4234

P: (858) 320-1208
F: (858) 320-1010
E: cavicchio_rob@emc.com

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.