Update, code is on the SVN
I don't think I saw this in your examples - How are you planning on handling places where for example, you're editing an entity's armors and the list of armors would come from a look-up of all of the item_armors defined in the mod?EDIT: I've written an article about id/ref and the formathttp://code.google.com/p/dfraweditor/wiki/XMLFormat
- about the format in general - very messy, it will need revisions to make it more understandablehttp://code.google.com/p/dfraweditor/wiki/IdRefDraft
- about the id/ref and some problems caused by RAW inconsistencies
original part of the post follows vv
In the XML spec, you define the ITEM_ARMOR entity to have an argument of type "string/id". Say the ID is ITEM_SUB_ID.
and the definition
<a type="string" id="ITEM_SUB_ID"/>
ITEM_ARMOR_BREASTPLATE is now ITEM_SUB_ID. This tells the parser to append whaveter string found on that argument to the list of ARMOR IDs (it knows it's armor because we're in armor container tag)
This line from entity definition
will look like this in the xml definition
<a type="string" ref="ITEM_SUB_ID"/>
Now, when editing, it will look at the 'ref' attribute and load up the list of ITEM_SUB_ID associated with "ARMOR" ITEM_ID (ITEM_ID is kind of supercategory of "ARMOR", "WEAPON", "TOY"..., while ITEM_SUB_ID is placeholder for item's logic names).
There is a slight inconsistency in naming. When defining item, it's called ITEM_XYZ, while the references are simply XYZ. So far this will be handled in the program code. It will probably be moved to the xml somehow. Probably in the form of lists of containers and their sub IDs and sub REFs. (ie ITEM_ARMOR ID map to ARMOR ref)
However, this feature is not yet implemented. But I'm confident it won't be hard (stuff might get complicated when handling creatures, but from the brief look it should be the same... I haven't found any nested references. Anyway, more research needed).
Now, I have to figure out how to map elements in the Document (or TextPane) defined by their offset and length to the abstract document tree (heck, I'll just keep calling it DOM). I've finished some bruteforce lookup but I feel it's not the right approach. And I'm to scared of hacking javax.swing.text.Document model