Visions of Aestia

This post is in response to Open Source d20 API/Engine thread on ENWorld, where I was asked to give an example.

Here’s an example of how I would model the “+1 vs goblinoids” so it can be resolved by an engine. This is off the top of my head and probably won’t withstand closer analysis.
First, we’ll need to define a goblinoid. Note that this could actually be an anonymous class defined as part of the bonus rather than a named class as in the example.
If something has creature subtype goblin and is a humanoid, we’re calling it a goblinoid. A more accurate definition would use oneOf to enumerate the full list of subtypes IIRC.

<owl:Class rdf:ID="http://example.org/srd#goblinoid">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="http://example.org/srd#humanoid">
    <owl:Restriction>
      <owl:onProperty rdf:resource="http://example.org/core#creatureSubtype" />
      <owl:hasValue rdf:resource="http://example.org/srd#goblin" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

Now, let’s define the bonus. It’s anonymous as it will typically be defined as part of some other rule, such as a racial trait.

<core:Bonus>
        <core:appliesTo resource="http://example.org/core#attack" />
        <core:type resource="http://example.org/srd#racial" />
        <core:Condition>
                <rdfs:label>vs goblinoids</rdfs:label>
                <core:conditionType rdf:resource="http://example.org/core#runtime" />
                <srd:goblinoid>
                        <runtime:Role rdf:about="http://example.org/core#target" />
                </srd:goblinoid>
        </core:Condition>
        <core:formula>1</core:formula>
</core:Bonus>

So, at runtime, when a creature of subtype goblinoid is assigned the “target” role relative to the character, the formula is evaulated and applied to the attack roll subject to stacking rules for bonus types.
Here, I’m telling the processor this condition can be checked at runtime. If, at that time, there is a goblinoid with the ‘target’ role, apply this bonus.
Some conditions can realistically only be evaluated by a DM (see the preqs for assassins, for example). For those I would stick with a simple text description like my original example.
Now, this is a lot of work, so I’m sticking to a small, well-defined ontology to begin with (stuff in the “core” namespace, above), and building tools to extend the ontologies on top of that. So all the stuff in the SRD namespace would be the result of using my BookBuilder application. Definitions like goblinoid can be built by example rather than typed out (I haven’t even thought about the book builder UI yet).

GnomePrint is poorly documented, has incomplete Python bindings, isn’t considered part of the core API and has different rendering model than the rest of GTK.

Thankfully, it’s slated for removal in a few months. It’s going to be replaced by Cairo, the hot new graphics API - which already has Python bindings. I’ll be able to throw a Pango paragraph of unicode text at cairo.show_text( ) and have wonderful things happen.

Ideally, I’d future-proof now by using Cairo to render a temporary PDF or PostScript file, then use printcontext.set_file(filename) to submit the print (or print preview) job.

Unfortunately, I can’t do that! The GnomePrint python bindings do not include the set_file API, and Cairo has not actually rolled a release yet. And no timeline/release information can be found, so short of browsing CVS I have no idea if or when I will be able to do that.

I will be so happy when I can write a tutorial on printing in gnome from python. But that’s months away.

I’ve been making decent progress in my implementation of VTD-XML.

Currently I can do the following:

• Auto-detect UTF-8 and UTF-16, switch encoding when declaration found.
• Parse all entity types except PIs.
• Match elements on name and/or namespace.
• Navigate through elements: go to root, parent, first child, next sibling. That’s enough to evaluate 9 of 13 XPath axes.
• Correctly execute two of the four examples included in the Java package.
• Get the first text or CDATA child of an element.

Major pieces still missing:

• Can’t enumerate attributes or their values (they’re parsed, just not available through API yet).
• Can’t handle mixed content gracefully.
• Not yet correctly enforcing well-formedness.
• No pythonic interfaces yet - this will be needed for the “real” API.
• No performance metrics yet - this is really needed to determine if the implementation is compelling.

The code also needs actual unit tests instead of relying on the examples, and I need to look at Uche’s Python and XML torture tests for more useful examples and API idioms.