… who do I think I’m kidding. ‘Quick’ does not describe my thoughts.
But it is convenient, for a ‘Q’ post title. :)
I feel like it’s time to pull together a few threads in this year’s posts.
Taxonomy Redefinition
This entire workflow grew out of publishing for d20-based games, specifically Pathfinder. Over time I’ve extended it to other game systems, and even other domains such as data dictionaries.
I’m going to try to refer to the thing defined in the domain taxonomy as ‘domain entities’. I would’ve gone with just ‘entities’, but around here that refers to my entity template.
Division of Duties
Today, my domain taxonomy is a mix of classification of domain entities and processing/rendering information.
With recent developments, I’ve concluded this makes my work more difficult.
I’m going to move away from this.
- Domain taxonomy will be entirely about classification of domain entities.
- Metadata such as index templates is probably still part of classification.
- Presentation information will be moved to style files.
- This will allow me to apply multiple styles to the same content.
- This should limit how much I need to edit my XSLT scripts.
- In fact, if I get this right I think I can reduce domain-specific transformation.
Game Entity Taxonomy
Fundamentally, I don’t see this changing. I might change some of the details, but the framework itself is sound.
I’m moving presentation details out of the taxonomy. Object definition in one file, object presentation rules in another seems a good change.
Style Definitions
I see two primary sets of style definitions.
- Document Styles These are document section headings (chapters, sections, subsections) and page decorations (page headers and footers. I expect this will include table styles as well.
- Domain Styles These are style definitions for domain entities: classes, spells, feats, and so on.
I want to have the two sets independent of each other so I can easily reuse them. I want the ability to mix and match them.
I’m pretty sure I’m going to add ‘document style’ and ‘domain style’ parameters to my scripts. I can instead give a single ‘style’ parameter that identifies a file that includes both, but that seems wasteful.
Processing and Transformation
Document structure is pretty static. I don’t know that I need to explicit declare it in a taxonomy-type file. A document has hierarchical structure, but document objects don’t. That is, a section is contained in a chapter, but is not a chapter.
Domain objects very much do have a taxonomy. The style sheets don’t need to, though. If I capture the styles in Word files I’ll use document headings to organize them to make them more navigable. I don’t need to build out — and more importantly, maintain — the taxonomy in the style file.
Regardless, this means I will take the prepared style file and merge it with the taxonomy file. I need settings to be inheritable: all class subfeatures use the same colors, so I want to define those once.
Closing Comments
It amuses me greatly that I titled this post ‘Quick Thoughts’. It took me almost two weeks to organize my scattered imaginings to make them as presentable as they are.
Still, getting them written down tells me my next steps.
- Create a file for document styles.
- Write a script to merge document styles with implied document taxonomy.
- Create a file for domain styles.
- Write a script to merge domain styles with domain taxonomy.
- Update formatting script that turns all this into LaTeX to use the style information.
Shouldn’t be too much work, surely.