Advertisement
Motenten

Spellcast XML Schema validation

Sep 22nd, 2012
1,083
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 5.26 KB | None | 0 0
  1. Using XML Schema validation.
  2.  
  3. NOTE: This is not official material for Spellcast. This is something I wrote up for my own use, and I'm sharing in case anyone is interested.
  4.  
  5.  
  6. This is a means of refining the validation of the XML you write, beyond mere well-formedness. Well-formedness can tell you whether you closed all your tags correctly, and can be tested by just opening the XML in Firefox. It cannot, however, tell you that you left off the opening <if></if> before a set of <elseif></elseif> blocks. It also can't tell you that "preecast" isn't a valid value for the 'when' attribute. That's where schema validation comes in.
  7.  
  8. I'm using this by editing in Visual Studio (should work with the free Express version too, which you can download from Microsoft). Other validators may also work, but I haven't tested them, so YMMV.
  9.  
  10. You need to do the following two things in order to make this work:
  11.  
  12. 1) Copy the following files to the directory you store your Spellcast XMLs: spellcast.xsd (the one I wrote) and XInclude.xsd (this file is from w3.org, and copied locally so that it doesn't cause your computer to do network lookups every time you change something). They are available from my pastebin page.
  13.  
  14. ~~Edit:
  15. I've broken the schema into 7 files. You'll want all of them to make use of the schema validation. The reason for so many files is that a lot of the code was redundant across several of them, and this makes maintenance easier.
  16.  
  17. The xsd's are:
  18.  
  19. spellcast.xsd -- Refer to this one for any primary spellcast files.
  20.  
  21. spellcastIncludeRules.xsd -- Use this for any Include files that only provide rules.
  22.  
  23. spellcastIncludeVars.xsd -- Use this for any Include files that only provide vars/sets/groups.
  24.  
  25.  
  26. They are supported by:
  27.  
  28. baseSpellcastRules.xsd -- most of the code for handling rules (used by spellcast.xsd and spellcastIncludeRules.xsd)
  29.  
  30. baseSpellcastVars.xsd -- most of the code for handling vars/sets/groups (used by spellcast.xsd and spellcastIncludeVars.xsd)
  31.  
  32. baseSpellcastCommon.xsd -- a couple elements that are common to both paths
  33.  
  34. XInclude.xsd -- The official W3 schema for xinclude.
  35.  
  36. ~~End Edit
  37.  
  38.  
  39. 2) Change the opening <spellcast> element of any given .xml from the typical:
  40.  
  41. <spellcast xmlns:xi="http://www.w3.org/2001/XInclude">
  42.  
  43. to
  44.  
  45. <spellcast xmlns="http://www.windower.net/spellcast/"
  46. xmlns:xi="http://www.w3.org/2001/XInclude"
  47. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  48. xsi:schemaLocation="http://www.windower.net/spellcast/ spellcast.xsd">
  49.  
  50.  
  51. When you open your spellcast XML (eg: mnk.xml) in Visual Studio, it will map to the identified schema by default. You can change this mapping, but generally there shouldn't be a need to.
  52.  
  53. Visual Studio will then provide a list of warnings for any errors it finds. The schema also provides info for IntelliSense to use, which means it will automatically pop up valid elements and attributes as you write your code.
  54.  
  55. The primary limitation is that XML Schema validation is case-sensitive. That means that the <config> element is different from the <Config> element is different from the <CONFIG> element. Unfortunately the only way to get around this is far too cumbersome with as many elements and attributes as are available in Spellcast (along with the varying casing options for each value). Because of that, I just went with full lower case for everything (eg: spelltargetraw instead of SpellTargetRaw), despite personal preferences, as having multiple options felt like it would just be confusing.
  56.  
  57. Edit: I've added in tons of duplicated elements to allow for capitalized forms. This causes the Intellisense to be more messy, but seems like a better approach for verifying currently valid xml's.
  58.  
  59. I did, however, put in the work to allow some case-insensitivity for most attribute values that have specifically defined lists. As such, you can use element="fire", element="Fire", or element="FIRE", and they're all considered valid. You just can't use Element="Fire".
  60.  
  61. In addition to the standard Spellcast game values that are allowed in <if> checks, I also included the new RadSources Trigger-type values. So things like type="Trigger" or spell="ClassTrigger" are valid.
  62.  
  63.  
  64. I've also built a validation scheme for Include files, though there are some restrictions due to ambiguity in the language definition.
  65.  
  66. 1) The include file must be one of two types: Either one that only includes includes for vars, groups and sets sections, or one that only includes includes for rules sections.
  67.  
  68. An include that contains vars/sets/groups should have the following top-level element:
  69.  
  70. <includes xmlns="http://www.windower.net/spellcast/"
  71. xmlns:xi="http://www.w3.org/2001/XInclude"
  72. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  73. xsi:schemaLocation="http://www.windower.net/spellcast/ spellcastIncludeVars.xsd">
  74.  
  75.  
  76. An include that contains rules should have the following top-level element:
  77.  
  78. <includes xmlns="http://www.windower.net/spellcast/"
  79. xmlns:xi="http://www.w3.org/2001/XInclude"
  80. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  81. xsi:schemaLocation="http://www.windower.net/spellcast/ spellcastIncludeRules.xsd">
  82.  
  83. They're identical aside from the xsd file being referenced. Those files need to be saved in the same directory as the spellcast files.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement