forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Citations and Glossary (Re: Release Manager - RM)
Date Fri, 21 Apr 2006 19:22:11 GMT
Gav.... wrote:
> 
>>-----Original Message-----
>>From: Ross Gardler [mailto:rgardler@apache.org]
>>Sent: Friday, 21 April 2006 5:37 PM
>>To: dev@forrest.apache.org
>>Subject: Re: Release Manager - RM
>>

...

>>Actually, this creates a dependency between the glossary and citations
>>plugin and the current plugin architectures does not support such
>>dependencies. The dispatcher work has such dependencies, but since
>>dispatcher is likely to end up in core that has not been considered a
>>problem.
>>
>>Here it is a problem. We will need to add dependencies to plugins to
>>support the citation from glossaries. This is he first real use case for
>>such a thing. Perhaps you could add an issue.
>>
>>I'll look into this in more detail with you when I have the time next
>>week.
> 
> 
> Ok ,thanks. 
> 
> For cite to work, we need the citations plugin, so we know that
> The Glossary Plugin relies on Citations Plugin if we use cite. But how
> dependent is Citations on the Glossary, I mean, how useful is Citations
> Plugin without Glossary anyway ? 

First, please understand that I wrote this code about two and a half 
years ago and have not used it since delivering that project. 
Consequently, my memory may not be accurate. I'll look over the code as 
soon as I can, but for now I'm going from memory, so go with care.

As far as I recall there is no dependency from citations to glossary 
entries. I can see no reason why a citation would reference a glossary 
entry.

> We would have to broaden the horizon
> And alter a document-vxx.mod schema to add cite perhaps to make it available
> forrest-wide. Otherwise, citations is also dependent on glossary.

No. See earlier discussions. We need to get rid of @cite and use 
@class="cite". This will be compatible with the current DTD and with the 
proposed XHTML2 subset.

> If the latter, then is it viable that the two plugins are bundled, or we
> Make sure that one plugin installs the other also.

When we implement dependencies in plugins it will be a case of defining 
one plugin as being dependant on another and the install mechanism will 
ensure that both are available. It's pretty easy to do, we just need to 
define a way of describing the dependencies - that is that hardest part 
because we need to do version management on dependencies as well.

We'll come to this when the two plugins are working.

Ross

Mime
View raw message