Conference vaxuum::online_bookbuilding

    That would be a wonderful feature but unfortunately it's still a
    wishlist item. There are no links between words coded with 
    <newterm> and their glossary definitions. In a glossary section,
    you are presented with a list of terms, which are hot. Clicking
    on the term brings up the definition. Previously, there were
    problems with very long glossaries: that's what the note in the
    document referred to.
    
    Mary

I realise this is not a fresh subject, but....

Are there any plans to provide <GREF> hotspots in on-line glossaries. I realise
that a hotspot usually links to a DOCUMENT symbol specified via a <REFERENCE> 
tag and that <GTERM> tags do not allow for definition of such symbols. However,
since there is a <GREF> tag, I think it would be a nice feature if we could take
advantage of it.

Maybe there is some wish-list that this could be added to ?

John

    Agreed: I would love to do this. It would be a great feature (and one
    that was requested at DECUS Europe). I can think of a few tricky
    problems, however. Ideally, every time the term is used in the
    text, it should be hot. This would mean coding every instance of
    the term <gref>(term-symbol). Which adds coding complications enough,
    but you would probably also want variants on the term in the text.
    For example, a glossary term might be 'file' but you are using the
    plural form in the text, yet you still want it hot. (Maybe 2 args
    to <gref> -- <gref>(term-symbol\form-of-term-in-text)?) All of this
    is do-able -- I'm just pointing out that with our current authoring
    tools, there might be a lot of coding overhead. The question is, would
    it be too much overhead?
    
    This is a feature I've long thought would be useful and would welcome
    suggestions/ideas/comments from people.
    
    Thanks,
    
    Mary
    
    (The answer to your actual question is, no, no definite plans at the
    moment to provide glossary hotspots.)

Well it looks as though this idea leads into a wider subject. I was just 
thinking about hotspots within a stand-alone on-line glossary, not about 
links to the text where the terms are used. In this case the <GREF> would 
have to be an exact reference to a <GTERM>. Since glossary terms are always
defined as singular, there would be no pluralisation problem.

What you are talking about, is a much more engaging idea and would, I agree, 
demand a great deal more development. 

Thanks for the prompt replies.

John

    To clarify (in my mind, at least):
    
    Was .2 asking for <GREF> to work so that output wd look like this:
    
    "
    International Organization for Standardization
    
    	A group of national standards bodies blah blah blah...
    .
    .
    .
    ISO
    
    	See International Organization for Standardization
    "
    and the last four words in that example would be a hotspot for the
    first <GTERM>? 
    
    I've never used <GREF>, but if I did I'd expect it to do just this
    (mirroring the way See/See alsos work in an on-line index);
    and I imagine a user would expect as much too.
    
    Is there really a lot of coding needed to make this work in a
    stand-alone glossary?
    
    b

To clarify... Yes that is what reply 2 was asking about. To make things clearer,
the SDML source file would contain...

<GTERM>(International Organization for Standards)
<GDEF>(blah blah blah......)

<GTERM>(ISO)
<GDEF>(See <GREF>(International Organization for Standards).)

I was taken in by this and assumed that GREF checked for a GTERM with the 
appropriate text. Had this been true, the amount of code might have been
manageable. However, after experimenting, I am forced to conclude that GREF does
no checking, but simply italicizes (duplicating the EMPHASIS tag). This means
I am asking for more than just a bookreader-friendly version of an existing tag.
First the tag would need to work in the same way as the <REFERENCE> tag and this
might mean changing GTERM so that a symbolic name could be assigned.

I wouldn't like to say how much coding would be involved. In any case, this now
seems to be only the tip of a DOCUMENT referencing iceberg. Perhaps we really 
want complete control with a <HOTSPOT> tag of something similar?

John

    .5: I think I introduced the confusion. John is right about the <gref>
    tag -- all it does is italicize. To make cross refs in an index hot,
    we would have to change <gterm> to take a symbol name. (We could not
    use the term itself as the symbol name because the term (or phrase)
    may use characters that are not legal in symbol names.)
    
    I went off and proposed something far more complex for <gref> (or
    a tag by some other name) -- to link the glossary term when it
    appears in the *text* to the glossary definition. 
    
    Not sure what John wants when he suggests a <hotspot> tag. How
    would it differ from the <reference> tag? 
    
    Mary

    Right, Mary. I don't think it would me an intolerable overhead for
    writers to have to add a symbol name to a <GTERM>, if in return the
    user would get See/See also references in a stand-alone glossary
    behaving the same way the behave in indexes (don't they - I haven't
    tried V2 yet, but isn't this a new feature?).
    
    Of course, I have little to go on when it comes to estimating how
    much coding this would take; to me, <reference> `just' (hey presto)
    works the way I want it to, and I don't know how much internal
    business lies behind it. But if a new style <GTERM> that makes
    See/See also references hot in a stand-alone glossary wouldn't cost
    too much coding time, it'd be good to have it as soon as possible.
    There is a risk, it seems to me, that we'll be overwhelmed by the
    prospect of a future all-singing all-dancing <GREF>; so much so
    that we won't, in the shorter term, get a basic hotspot that
    users expect and would find very useful.
    
    b

    	I was wrong about See/See also cross-references in indexes. Shame.
    
    b

    .8: OK, I'll add hot <gref>s to the list and see what we can do for
    some future release of the online tools. (It shouldn't be hard, but
    then again, we have a long list...)
    
    Thanks,
    
    Mary

I just caught up with the last four replies. Like I said after Mary's first 
reply, I think the GREF wish touches on the much wider subject of hotspots in 
general and I appreciate that this will take time to action. Since I would like 
to provide input, I wondered if there were other notes in other conferences that 
I could be pointed to.

Also, Mary, I must admit that I'm not sure what use a <HOTSPOT> tag would do. 
Its only a half-baked suggestion. I wouldn't like to bake it any more without
knowing what is already cooking elsewhere. I already have some three-quarter 
baked ideas about the way DOCUMENT referencing could be improved and a <HOTSPOT>
tag could, perhaps, be produced in the same batch !

John 

    John-
    
    I think this is the best place for any input you have about tags,
    such as <hotspot> that affect online books. Please feel free to
    post you inputs here, half-baked or otherwise.
    
    There is, in addition, the DOCUMENT notes conference on CLOSET,
    for general VAX DOCUMENT stuff.
    
    There is the BOOKREADER notes conf on BULOVA for comments/problems/
    wishlist items for the Bookreader.
    
    There is  the 3JK_ODP notes conf on ONLYME that also deals with
    online issues.
    
    Thanks,
    
    Mary

Well, here I go again. Trying to write reply 35.13. The last time I tried this, 
our system disk filled up and I was forced to log out and log in again. No-one
was quite sure where note 35.13 had gone..."Isn't it marvellous what we can do 
these days..."

So the <HOTSPOT> Tag. The idea really comes from wanting to reference a list 
element in a hard copy document. Of course, there is no way to do this with
the existing DOCUMENT tags and, in hard copy, it would be very awkward due to 
the need for some cumbersome written references. I am assuming here that, due
to the nature of DOCUMENT, it is not possible to have automatic page-number 
referencing.

With on-line documents, however, hotspot links are transparent to the user. All
that is required is some indication that the text is a hotspot. Italics, for 
instance. The basic idea is to that any word, phrase or paragraph could
be designated as a hotspot and given a symbolic name. This symbolic name could 
be referenced in the ordinary Bookreader way.

Does that make any sense ?

John 

    Yes, I think this does make sense (at least, I've also thought that it
    would be useful to be able to reference lists). I'll put this note on
    the wishlist (no promises for when it might be implemented).
    
    Thanks,
    
    Mary

    Thamks for putting it on the wishlist Mary. But I think that, to do
    justice to John's idea (having hotspots anywhere you like in the text,
    pointing to any chunk) - as the objections to such a tag are so easy to
    find for hardcopy - the wishlist item should in some way emphasize
    `<HOTSPOT> tag -  _for_on-line_only_' [or is the `on-line' bit implicit
    in the nature of the wishlist anyway?]

    b

    Good point, the name 'hotspot' does tend to imply online only: 
    the implementation will require Some Thought. I'm putting
    it under the general category of 'cross reference things to
    fix/improve', such as cross refs to templates.
    
    Thanks,
    
    Mary

    Somewhere, (I think in the DOCUMENT) conference, one of the gurus
    agreed that there was a need for more tags to take symbol-names. I
    argued there, and would do the same here, that providing symbol-name
    capability for *every* tag is perhaps the way to go. Without using Deep
    Thought, I would suggest that references to these symbol-names would be
    resolved by using the caption/text information if provided, and/or/if
    not, page/section number.

    Other than the specific issue of how bookreader might make it easier to
    *see* these references, how far would this go to resolving John's problem?
    It would certainly make it easier to be accurate: referencing the <P>
    tag instead of the <HEAD*> ought to eliminate the "what you're looking
    for is around here somewhere, but unfortunately isn't actually on the
    screen at the moment" syndrome.

    Regards

    Richard

    ps John: did you ever receive my reply to your mail? 

Having just returned from a two-week break...

I think symbolic names for every tag could help. However, the writer's problem
of creating unique names and then remembering them would be exacerbated. I have
often though that a utility might be provided, wherein all the exsiting symbolic
names in a book could be listed. With DECwindows technology the presentation of
such a list would be easy.

P.S. Richard. No I didn't receive the reply to my mail

John

    Yes, that's one of the problems with lots of symbols. Part of the
    wishlist  item is the ability to generate table(s) of symbols
    writers could use for exactly this purpose.
    
    Mary