jontukontar

Updates:

• Modified anathemaTool.sh to allow in-place validation of files and fixed an issue with the find command.
• Added 90% of Lunar charm trees (less Wits and "Lunar Hero Style")
• Made various alterations to charms.dtd and charmreview-xmlns.xsl .
• Added more information about plugin-fragment.xml to plug-in documentation project.

In Progress:

• Lunar plug-in:
• Finishing up coding for remainder of Lunar charms.
• Read through Lunar charms and add "Coding" comments to charms when necessary.
• Alter plugin-fragment.xml to incorporate file and directory listings for Lunar charm files.
• Alter language property files for new charm tree.
• Add charm XML information to plug-in documentation project.

The first list is what I've been up to in the last couple of weeks. I've got quite a bit of XML coding done for the new plug-in. During this process, I've had to update various supporting files to allow things that are done with charms in the Lunars book. Charms.dtd was updated to allow for the use of "Attribute Excellencies" and I fixed a minor error with the default speed for charm based attacks. Charmreview-xmlns.xsl was updated to properly display "Excellencies", number of required "Excellencies" and I've added in proper support for the "dramatic action" and "long ticks" based charms. (Previously, neither of these were being displayed at all.)

All this coding has reminded me of a few things that I've added to my charms as a "safety net" that need to be properly documented when I describe charm XML on the documentation project. In specific, Anathema doesn't display the following in the charm viewer:

<charmtype type="Simple">
<special turntype="DramaticAction" />
</charmtype>

If you don't include both speed and defense numbers (these can be the default speed="6" defense="-1"). This is something that I'd forgotten about because my charms.dtd file was "shielding" me from this issue. Given this, I've went back through all my charms and have updated them so that they can be used without the DTD. I've also eliminated some <special /> tags from Simple charms that just listed the default values and nothing else (they were superfluous).

In the second list, both of the charm trees sould be fairly easy to convert to XML because they are both relatively small. The rest is going to take some time.

PS. Does anyone have any thoughts on what I've done thus far for plug-in documentation? See Anathema Development for link.

I'm still trawling through the various Unix binary paths in order to find some interesting goodies among the multitudes of programs available on OS X 10.5 Leopard.

Thus far, I've found that it includes the command line version of SVN, so you can use svnX without downloading anything else (just point it to '/usr/bin' for the SVN binary).

It apparently also includes a program 'xsltproc' which can apply a XSL style sheet to an XML document and it can help you debug your sheet.  This means that I can get rid of XALAN, which has been doing this for me up to this point.

Leopard also has 'xpath' which allows you to directly query an XML document for a given set of nodes (eg. '/charmlist/charm/cost/willpower/@permanent')

It also has 'sdiff' which does side by side comparison of files.  Which could be useful when paired with SVN.

Last, but not least, it also includes 'tidy' (aka. HTML Tidy) which attempts to make HTML/XML prettier to look at.

PS.  Doesn't anyone know if the included version of SVN is 64bit capable or if there is a way of testing that?

Thus far, I have been spending cash like water. Most of this is due to things that either have to be paid (bills) or things that need to be fixed (my car). I am fortunate that I have some savings and thus it is not going to hurt me too much in the long run. Regardless, I’m not happy with the necessity of spending so much.

On the subject of spending, I really need to spend more time working out. Typically, I run about 15 minutes every night but as of late illness and lack of time have been preventing me from doing so.

Does anyone know of a OS X compatible dice roller that uses conventions found in Storyteller games (i.e. no summation of the die results)? Has anyone seen (or preferably played) the Exalted board game War of the Throne?

XML Stuff:

In my reading of XML Primer Plus, I’ve come to some “conclusions” (subject to revision as I learn more). XML name spaces, can/are used to combine elements from different XML documents. This is particularly useful if you have to reuse elements (aka. <charm />).

For instance:

<data xmlns=”http://anathema.sourceforge.net/charms” 
      xmlns:srcy=”http://anathema.sourceforge.net/sorcery”  
      xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
      xsi:schemaLocation=
      “http://anathema.sourceforge.net/charms ../charms.xsd
      http://anathema.sourceforge.net/sorcery ../sorcery.xsd”>
  <charm>
    <id>solar.shadowstrike</id>
    <duration>instant</duration>
  </charm>
  <srcy:sorcery>
    <srcy:id>solar.celerityoftherisingsun</srcy:id>
    <srcy:target>one</srcy:target>
  </srcy:sorcery>
</data>

XML schema’s are fabulously complex and thus incredibly useful. You can make groups of various things: attributes, elements, value lists, etc. You can specify in much greater detail what contents are valid. Since it is hierarchical based, it deals better with repeated elements (aka. <charm />) that have different children or attributes.

You can combine XML Schema’s with name spaces to validate a document against two different schema’s. Which is particularly useful in the above example code. Sorcery has only 3 elements vs the minimum of 5 for most Charms.

I’ve also learned some interesting things about XSL. Apparently, there is an <xsl:transform xmlns:xsl=http://www.w3.org/1999/XSL/Transform" version="1.0" /> element. I didn’t realize that such an element existed, in part because none of my example documents used it, but according to the author of my book, it is being used more often now.

It also gives me a way to tinkering with the “Transformation” aspect of XSL. I would need to get a software called Xalan which would allow me to utilize this. All I need to do is type in (assuming I can get it “installed” correctly):

java org.apache.xalan.xslt.Process -IN (Some XML Document) -XSL (Some XSL Document) -OUT (Some Document)

OR

java -jar path/to/xalan.jar -IN (SOME XML DOCUMENT) -XSL (SOME XSL DOCUMENT) -OUT (SOME DOCUMENT)

It would make mass conversion of XML documents relatively easy, assuming you didn’t have another way of doing the same thing.

Aside:Now to pickup my car and spend $160 US.

PS. Learning is always good but being able use that knowledge is better. Yes, I’m being enigmatic but that’s my prerogative.

My books are currently in “Elsewhere” which is a tad annoying. I have been trying to get information on them for the past week but the usual sales representative is gone. Not only that but now the warehouse says that there are no copies available. I’m hoping that by next week we can at least get a shipping confirmation.

I’ve been writing some more XML for use in Anathema. As part of this process, I came to discover that the DTD that I’ve been including in with my plug-ins is getting used by Xerces (the XML parsing engine). It uses the DTD to supply the “default” values for a given element or attribute. You can test this if you have the DTD and then create an XML document, now forget to provide the cost attribute to the essence element. Two things that you’ll see is that Anathema doesn’t crash on you and you have an essence cost of 1.

In line with this, I’ve also been updating my XSL document to more accurately reflect the charm format that you see in the book. Which is turning out pretty well but the code is a mess of conditional statements. I’ve also begun to incorporate some more advanced XPath functionality into the XSL, which allows it to more accurately reflect the book and gives you some interesting details about a charm tree.

For instance:

* Using count() to enumerate the the <charm> elements. e.g. <value-of select=”count(charm)”/> You can also use simple math operators to get even more data (e.g. charm + genericCharm).
* Using boolean() to force a true/false judgement on a given piece of data. e.g. <xsl:if test="boolean(number(cost/temporary/essence/@cost))='true'"></xsl:if>
* Using concat() to string together several bits of data into a given string. (Admittedly, this has no real use in HTML but it is interesting nonetheless).