Heres the list. I had it on disk.
Joachim
> > would it not be better to wait with the entyattribute stuff until the
> > sword api is redesigned (2.x -- not talking of BibleCS)?
>
> No, the redesign will not alter the EntryAttributes concept or the
> 'meat' of any functionality in 1.5.x. The redesign will simply change
> the programming interface to be consistent, and many of the concepts
> that I've wanted to add at redesign time have already been started in
> the 1.5.x branch.
>
> > IMHO a unsound mix of filtering and direct acess would be created if we
> > would start using this thouroughly now, because those are very different
> > approaches to access the text.
>
> ? Not sure what you mean. The filters produce the EntryAttributes
> entries. There is no direct access. The filters are still involved in
> formatting the EntryAttributes entries the way your frontend requires
> them (or should, when they are actually written/complete).
>
> > Before doing this, we should probably switch to OSIS
> > internally, and then redesign the api to give it a more consistent and
> > flexible approach.
>
> Actually, you, as a client of the API should never have to know that any
> text you use is in OSIS, or ThML, or GBF, or whatever. Only as an API
> extender (filter writer, etc.) or hacker should you have to know about it.
>
> > The entryattribute stuff seems to be much similar to the
> > ontag mechanism you planned for sword 2.x.
> >
> > Please correct me if I am wrong here, I might be misinformed.
>
> Well, actually, the onTag mechanism was intended for filter writers to
> more easily write filters by responding to tag instances with an onTag
> event. The design will also allow us to consolidate cases where we
> currently have mutliple passes of the text by multiple filters into a
> single pass, hopefully speeding up things considerably.
>
> > Btw, do we have the list of sword "module.conf" keys online? I would like
> > to submit it to the wiki.
>
> Yeah, I think Chris posted the current list a few months back. I'd
> check the archives (I'm assuming you mean valid .conf entries, and NOT
> the CipherKey's :) ).
>
> Thanks for the feedback. I hope this clears things up a little. Value
> your comments.
>
> -Troy.
>
> > Martin
Title: Untitled Document
|
Element
|
Values (type or enumerated)
|
Default Value
|
|
required elements
|
|
DataPath
|
<relative system path> |
|
|
Description
|
<string> |
|
|
ModDrv
|
RawText, zText, RawCom, zCom, HREFCom, RawFiles, RawLD, RawLD4,
zLD, RawGenBook |
|
|
elements required for proper module
access
|
|
CipherKey
|
<string> (typically in a format matching the pattern
/[0-9]{4}[A-Za-z]{4}[0-9]{4}[A-Za-z]{4}/ |
|
|
BlockType
|
BOOK, CHAPTER, VERSE |
CHAPTER |
|
CompressType
|
ZIP, LZSS |
LZSS |
| BlockCount |
<integer> |
200 |
|
elements required for proper rendering
|
|
GlobalOptionFilter
|
GBFStrongs, GBFFootnotes, GBFScripref, GBFMorph, GBFHeadings,
ThMLStrongs, ThMLFootnotes, ThMLScripref, ThMLMorph, ThMLHeadings, ThMLVariants,
ThMLLemma, UTF8Cantillation, UTF8GreekAccents, UTF8HebrewVowels |
|
|
Direction
|
RtoL, LtoR |
LtoR |
|
SourceType
|
Plaintext, GBF, ThML, OSIS |
Plaintext |
|
Encoding
|
UTF-8, Latin-1 |
Latin-1 |
| DisplayLevel |
<integer> |
1 |
|
Font
|
<string> |
|
|
elements to indicate features
|
|
Feature
|
StrongsNumbers, GreekDef, HebrewDef, GreekParse, HebrewParse,
DailyDevotion, Glossary |
|
|
LexiconFrom
|
<OSIS:Lang identifier> |
|
|
LexiconTo
|
<OSIS:Lang identifier> |
|
|
general informatic and installer elements
|
|
About
|
<string> |
|
|
Version
|
<version string> |
1.0 |
|
History_x.x
|
<string> |
|
|
MinimumVersion
|
<version string> |
1.5.1a |
|
Category
|
<string> |
|
|
LCSH
|
<tree/string> |
|
|
Lang
|
<OSIS:Lang identifier> |
en |
|
< |
|
