Loading ...
Sorry, an error occurred while loading the content.

On Namespaces

Expand Messages
  • Keith Davies
    Hi All, here s a document I wrote that describes the three namespaces I m using. I ll post more later on the data types involved... I had an idea the other
    Message 1 of 1 , Oct 15, 2002
    • 0 Attachment
      Hi All,

      here's a document I wrote that describes the three namespaces I'm using.
      I'll post more later on the data types involved... I had an idea the
      other night that removed some elements we'd all been expecting to use.

      Such as <class>. Don't worry, though, I think I've got something better
      (or at least, more flexible). More later.

      PCGen-XML Design: Namespaces
      last updated 2002/10/15


      This document describes the three namespaces used in PCGen-XML

      General Structure

      A PCGen-XML file consists primarily of elements from three namespaces
      (four if you include the XHTML information present in description
      fields, described below). The three namespaces are described below.

      For most important elements there will be elements with the same names
      in the meta and def namespaces - the meta element defines what the
      def element will contain. It will be possible to have more than one
      meta element of the same type, to indicate various ways or groups of
      game elements. Many of them will also have matching elements in the
      use namespace, where they actually apply or associate the entity
      being described with another described entity.

      Namespace meta

      Elements in the `meta' namespace specify the information required for
      various other aspects of the program. This is not the same as XML
      schema, though there are parallels. The meta namespace elements
      specify what pieces of information are used in a particular type of
      entity. For instance, there are several types of character in my

      PCs and major NPCs use the same, full (complete) character format,
      including stats, skill allocations, spell lists, equipment lists,
      and so on. Minor NPCs (the stableboy they deal with regularly,
      the bartender at the tavern, the half-deaf hedgewizard at the edge
      of town) generally consist of only a few description elements
      (appearance and personality, usually, perhaps with some notes about
      how the character has interacted with the party). Mooks are
      characters quickly drawn up for limited duration use (particularly
      in fights, where they don't last long... a little like the minions
      from kung fu movies who exist only to let the main characters show
      off, and are commonly referred to as mooks) and contain combat
      related information but not much else. The mook category contains
      characters such as `barroom brawler', `archer', and `city guard'.
      They may or may not have names (I like them to because it impresses
      my players when `nobodies' like these actually receive their orders
      by name) but otherwise have no real `character'.

      Each type of character would have a meta element type associated
      that describes the informationed needed to describe characters of
      that type.

      Character types are not the only thing described in the meta
      namespace, but are perhaps the clearest example.

      Note that it will not be possible for elements in this namespace
      to define new element types (something XML Schema can do). This
      namespace merely gives the user the ability to define how things
      are to be described, particularly if they are of similary nature
      but different type (for instance, the various character types
      described above).

      I expect that a meta definition will have a flag that will allow
      elements that do not strictly fit the definition to be used.
      Specifically, that the definition will state the elements that
      must be present and that the others will be ignorable. For
      instance, in a game that does not bother with spell components
      (such as Basic D&D) <meta:spell> might include the spell's
      name, casting time, and description, but ignore all other
      elements. It would then still be possible to use the standard
      /fireball/ description (<def:spell>) with this meta definition.

      { perhaps something like:
      <!ELEMENT meta:spell (&field-defs;)>
      <!ATTLIST meta:spell match "exact|loose|sloppy" "exact">

      where `exact' indicates that the data must match the meta
      definition exactly, `loose' indicates that all required
      fields must be present in the order defined but extra fields
      will be simply ignored, and `sloppy' indicates that as long
      as all fields are present, anything extra is ignored and
      order does not matter.

      Namespace def

      The def namespace contains elements that describe entities that
      have meaning at game-level. Where elements in the meta namespace
      describe what an entity's description will look like, elements
      in this namespace define entities that match the descriptions given
      in the meta namespace.

      Namespace use

      The use namespace contains primarily utility elements (such as
      <ref>, which makes a reference to an element from one of the other
      two namespaces) or descriptive elements (those that actually
      describe the entity being defined).

      Elements in this namespace generally have little to no meaning in
      and of themselves; only in context are they useful.

      It is expected that most of the data elements will be drawn from
      this namespace (given that each def element will require at least
      one use element, if only <name>, this is a reasonable conclusion).

      Because there will be more elements of this namespace than any
      other, it is expected that this will be the default namespace.


      (Note that this does not actually match the design, but does fit
      the structure described above, and that the examples below are
      heavily elided. All namespaces are shown explicitly, which does
      not meet expectations of actual use.)

      <prereqs reqd="opt"/>
      <description reqd="opt"><name>Normal</name></description>
      <description reqd="opt"><name>Special</name></description>
      <description reqd="opt"><name>Notes</name></description>

      specifies that a feat consists of a name, followed by an optional
      prerequisite list, followed by the effects of the feat, followed
      by three optional textual description fields.

      <def:feat id="feat.alertness">
      <use:bonus ref="skill.listen">+2</use:bonus>
      <use:bonus ref="skill.spot">+2</use:bonus>

      <def:progression id="class.rogue">

      <use:race ref="race.halfling">
      <!-- no decisions needed, so none logged -->
      <use:progression type="pt.level">
      <use:step rank="1">
      <use:add progression="class.rogue">
      <use:add score="char//score.hit-points">6</use:add>
      <use:add score="char//skill.listen">4</use:add>
      <use:add score="char//skill.spot">4</use:add>
      <use:add score="char//skill.search">4</use:add>
      <!-- etc. -->
      <use:feat ref="feat.alertness"/>
      <use:step rank="2">
      <use:add progression="class.rogue">
      <use:add score="char//score.hit-points">4</use:add>
      <!-- etc. -->
      <use:step rank="3">
      <use:add progression="class.rogue">
      <use:add score="char//score.hit-points">5</use:add>
      <!-- etc. -->
      <use:feat ref="feat.dodge"/>

      Keith Davies

      PCGen: <reaper/>, smartass
      "You just can't argue with a moron. It's like handling Nuclear
      waste. It's not good, it's not evil, but for Christ's sake, don't
      get any on you!!" -- Chuck, PCGen mailing list
    Your message has been successfully submitted and would be delivered to recipients shortly.