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

Re: [pcgen-xml] Re: Keith's notes

Expand Messages
  • Keith Davies
    ... To be honest, I m not all that familiar with XSD, but what I ve seen has given me hives I m familiar with DTD, and apart from a lack of support for
    Message 1 of 6 , Mar 14, 2003
    • 0 Attachment
      On Fri, Mar 14, 2003 at 05:00:27PM +0000, Olivier Rolland wrote:
      > --- In pcgen-xml@yahoogroups.com, Keith Davies <keith.davies@k...>
      > wrote:
      > > Great. I'll point out, though, that you are referring to doco for
      > > stuff that is not being done at the moment. Look in the 20030302
      > > LST->XML folder. For now, we're doing a very direct translation,
      > > with minimal change to the tags themselves.
      >
      > That's what I understand when reading the previous posts. But I am
      > much more interested in the design of a d20 xml syntax. And if you
      > don't mind, I will start to look further on this problem.
      >
      > > However, for future reference I'll discuss the points below. They
      > > don't, by and large, apply to what we're doing right now, but I'll
      > > discuss them anyway.
      >
      > Thanks.
      >
      > > > - The meta tag: I don't understand why such a tag. It's very much
      > > > like XML schemas but much less powerfull. With schemas, you could
      > > > specify uniqueness or define keys to reference them later. Such
      > > > construction are very usefull for example in list entities to
      > > > verify that all items already exist.
      > >
      > > The intent is somewhat similar to XSD, but to make it simpler and
      > > more closely related to gaming -- more domain aware, if you will,
      > > and getting rid of stuff that we don't need.
      > >
      > > I know that we could probably get by with XSD, but I didn't want all
      > > the baggage it brings.
      >
      > Of course, XSD provides a lot of stuff and is designed to be generic
      > enough to be used in a wide variety of different frameworks. But it is
      > in its way to be a standard (much more than DTDs) and libraries
      > supporting it are already available in many languages (Java among
      > others, see Xerces-J).

      To be honest, I'm not all that familiar with XSD, but what I've seen has
      given me hives <g>

      I'm familiar with DTD, and apart from a lack of support for namespaces
      I've found it meets my needs. I'm not opposed to XSD, meta was just
      defined as a simpler subset of XSD, with a few 'extensions' that are
      gaming-specific. It may be that those same extensions can be done with
      XSD, but I don't know enough to say for sure. I am comfortable in
      saying that meta is simpler than XSD.

      >
      > > > - benefit/prereqs: I do like very much these two tags and I think
      > > > you could use them more often. For example, size provides bonuses
      > > > or maluses on attacks, AC and hide skill. Something like this can
      > > > be really handy:
      > > >
      > > > <def:size order="1" id="size.fine" name="Fine">
      > > > <benefit>
      > > > <add bonus="skill.hide" value="16"/>
      > > > <add bonus="attack.bab" value="8"/>
      > > > <add bonus="ac.full" value="8"/>
      > > > </benefit>
      > > > </def:size>
      > >
      > > Such is the intent, yes.
      > >
      > > > Further more, some benefits can be conditioned by a requirement.
      > > > A construction of imbricated prereqs and benefits could then be
      > > > considered. I do not have any immediate example, but I can find
      > > > one if you want.
      > >
      > > Well, I suppose there's
      > >
      > > <def:class id="class.rogue">
      > > <benefit>
      > > <add-weapon-proficiency refid="weapon.rapier">
      > > <presize min="size.medium" />
      > > </add-weapon-proficiency>
      > > </benefit>
      > > </def:class>
      >
      > Yes. And I think "progression" can be handled the same way.

      yep. That's the intent. The snippets below may not match what was
      originally described in that doco; I'm up to my elbows in the schema
      we'll actually be using in the short term and may be misremembering
      things, or applying them differently. That said;

      <def:class id="class.rogue">
      <prereqs />
      <ranks>
      <rank rank="1">
      <prereqs />
      <effects />
      </rank>
      <rank rank="4">
      <prereqs />
      <effects />
      </rank>
      </ranks>
      </def:class>

      Progressions also allow for definition of recurring effects, such as
      addition of hit dice, base attack bonus, etc. Fighter became really
      simple:

      <def:class id="class.fighter">
      <recur>
      <add-hit-die size="10" />
      </recur>
      <recur test="not($rank % 2)">
      <add-feat type="fighter" />
      </recur>
      <ranks>
      <rank rank="1">
      <add-feat type="fighter" />
      </rank>
      </ranks>
      </def:class>


      > > > - score tag: Why do you use the same tag for abilities, saves,
      > > > attacks and ac ? It prevents you to define the key ability of
      > > > saving throws or attack bonuses.
      > >
      > > The idea here was that, generally speaking, numeric scores (such as
      > > abilities, base saves, and base attacks) are just that -- numbers.
      > > They would be differentiated by type (for those processes that care)
      > > and rules around bonuses would apply (for instance, save.fort would
      > > be given a bonus based on the character's stat.con). They are not
      > > directly linked because not every game uses them[1]; they are
      > > bonuses from having high stats.
      > >
      > > [1] this schema was designed around being able to support multiple
      > > games from not only different genres but different rules
      > > systems.
      >
      > This will be quite hard to achieve, I guess...

      Actually, while developing it was suprised at the range of games it
      would be able to handle. Part of the reason I've been working on this
      so long is that I kept seeing further abstractions that not only made it
      easier to handle various rules (skills are progressions in d20, for
      example, because various types of skills do different things at each
      rank; in another game (HERO, say) they'd be just simple scores... but as
      long as we can track both progressions and scores, it shouldn't be
      terribly difficult to support (skills at least, under) both systems.

      Really flexible and powerful... but possibly a bit trick to set up the
      game modes. It doesn't particularly try to convert between games,
      either; if you define a weapon in HERO, it won't be directly convertable
      between systems. However, it may be possible, if rules for doing such
      are conversion are created and made available, that the data *could* be
      moved between them. Beyond the scope of what I'd come up with, though.


      Keith
      --
      Keith Davies
      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
    • Tir Gwaith
      I waiting to see an actual tag schema from Keith. Since he doesn t understand intricately how the current data model works, I ll be making some minor
      Message 2 of 6 , Mar 14, 2003
      • 0 Attachment
        I waiting to see an actual tag schema from Keith.  Since he doesn't understand intricately how the current data model works, I'll be making some minor modifications...
         
        And some Style points still need to be hashed out.  Expect an example fileset to chew on next week.
         
        refid statements will be out for the first pass at least, since PCGen's IDM doesn't have that globally.  We are making no IDM changes on the first passes.
         
        We might include the id statements in the first pass, but Eric and I need to discuss some more style points.
         
        Tir Gwaith
        PCGen BoD
        Data Silverback
      • Keith Davies
        ... IDs (id and refid attributes) will be allowed by the schema. They ll be ignored by the loader, for the moment, but they re the first change that ll be
        Message 3 of 6 , Mar 15, 2003
        • 0 Attachment
          On Fri, Mar 14, 2003 at 06:32:32PM -0600, Tir Gwaith wrote:
          >
          > refid statements will be out for the first pass at least, since
          > PCGen's IDM doesn't have that globally. We are making no IDM changes
          > on the first passes.
          >
          > We might include the id statements in the first pass, but Eric and I
          > need to discuss some more style points.

          IDs (id and refid attributes) will be allowed by the schema. They'll be
          ignored by the loader, for the moment, but they're the first change
          that'll be made.


          Keith
          --
          Keith Davies
          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.