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

Re: [pcgen] Re: Reducing Sources (a feature suggestion)

Expand Messages
  • Keith Davies
    ... Sorry, by XML internally I meant OO (presumably) model of XML . That is, with Element, Attribute, etc. (or more probably a tree structure of nodes,
    Message 1 of 5 , Oct 2, 2002
    • 0 Attachment
      On Wed, Oct 02, 2002 at 09:48:20PM +0000, Strom McLeod wrote:
      > --- In pcgen@y..., Keith Davies <keith.davies@k...> wrote:
      > > On Wed, Oct 02, 2002 at 04:24:52PM +0000, Strom McLeod wrote:
      > > Ah, see, I was assuming that internally we *don't* use XML.
      >
      > I don't believe any software design uses XML internally to store their
      > information. At some point, object oriented programming dictates that
      > you're going to use domain-specific objects. However, to parse
      > through the XML file (and later, write one out) you'd probably still
      > want to, at some point use SAX (at least)
      > For what it's worth, we currently do that in our e-commerce program to
      > store information.

      Sorry, by 'XML internally' I meant 'OO (presumably) model of XML'. That
      is, with Element, Attribute, etc. (or more probably a tree structure of
      nodes, like DOM) to model the data internally, not the raw XML text
      (that would be just, well, wrong).

      My expected solution -- the one I monkey with when I have time -- is to
      use SAX (Xerces-C++, myself) to parse the data. This is one of the
      reasons I require that references only be made to items already seen, so
      they can be resolved as they're found. They can be written out to XML
      using whatever technology we want.

      What I plan to have (and to propose to PCGen) is an internal data model
      (probably close to the XML model, to a certain extent), completely and
      utterly divorced from the loading mechanism. This will make it possible
      to change to a different model -- load everything from an Access
      (<shudder>) database, say -- without affecting the internal model.

      Damn. I just realized that the converse of that -- that the internal
      model provide an interface that abstracts the guts of engine -- could be
      difficult given some of the other comments I made. OTOH, if I hide the
      things that could get in the way of that (such as the fact that a
      spellbook, say, has hard references to the spells contained) it can
      still be done. Actually, I like that idea. If we can have a model
      similar to

      input engine +------+ data engine +------+ output engine
      +
      \
      + character generation engine

      where each of the engines simply conforms to an interface, we can:

      read everything from some arbitrary input engine and loading it into
      the data engine

      write everything to some arbitrary output engine (LST file? XML?)

      replace the data engine completely with a relational database (or
      whatever) if desired, possibly even dropping the input and output
      engines

      (note to self: clearly define the interfaces, make sure nothing
      absolutely implementational gets revealed. Let's make it easier to make
      these changes next time. I know this seems obvious, but I hadn't
      thought this far ahead -- I've been focusing on getting data into the
      system)

      > > For instance, actually having specific data types internally to
      > > represent information.
      >
      > That much should be obvious to anyone who does any work in Java or any
      > other OO language.

      Should be. OTOH, there's a lot of parsing and reparsing and parsing
      again of text data in PCGen, there are a huge number of conversions from
      string to number, and so on. Early on in the XML discussions there was
      talk of using JDOM internally, which would keep things in XML(ish)
      technology all through runtime.

      > > This is not an XML processor, it is a character generator that makes
      > > use of XML files. *Big* difference, IMO.
      >
      > In order to utilize XML, you will need to process XML at some point.
      > In this case, during the load and saving parts of the program. Even
      > if you write your own parser to go through the XML data. Using SAXP
      > saves you time. Using DOM is a little trickier. Write your own? Not
      > impossible, just clunky. Learning how to write parsers using
      > flex/bison is still part of the undergrad curriculum, right?

      As mentioned, I'm planning to use SAX (Xerces-C++) for the stuff I do.
      I don't do Java well... not enough patience. For runtime. For some
      reason, every program I run under Java is... unsatisfying. I'm not a
      speed freak, but I shouldn't be waiting for menus to pop up when I click
      them, either.

      > > list of... things'. When you do that, you end up having to have your
      > > algorithms ask 'is item one of these? Okay. Does it have *this*?
      >
      > You can somewhat rely on Java exception handling to avoid doing this.
      > This is probably not the right forum for debating coding style.

      Hmm... I hadn't considered exceptions here. By nature I'm a C++
      programmer; exceptions are used for *unexpected* things, such as running
      out of memory or a file suddenly being unwritable (these things can be
      anticipated, but aren't expected). Parsing errors, especially when
      dealing with human-keyed text, are to be expected and handled more
      gracefully. IMO, exceptions are not intended to be used for things that
      are expected to go wrong. It's one of the things that drives me nuts
      about Java, actually, is how exceptions are used for things like parse
      errors.

      On the one hand, they *do* force you to check for errors. OTOH,
      sometimes I... just don't care. There's no way I know of to say t'hell
      with it and let it go. Java may try to enforce better engineering, but
      I prefer to do it myself.

      Style and language issue. I can do OO in Java and write Java code, but
      I don't like the way some things are done in Java. I don't like the way
      some things are done in C++ either, but I'm more accustomed to it, I
      find it faster, and I have templates!

      Ah well, language debate is definitely OT <g>

      > > Frankly, I like the idea of requiring a programmer to add features or
      > > data extensions to the system. While allowing the program to handle
      > > arbitrary data sounds nice, I find that requiring someone to modify code
      > > sets things up so that some thought is required. Plus, I find it a lot
      > > easier to prove a program if I don't need to worry about handling
      > > *anything* that gets thrown at it; limiting what the users can actually
      > > do greatly reduces the chances of them doing something that borks the
      > > system.
      >
      > You're definitely allowed your opinion on that. On the other hand,
      > one of the strong points of J2EE and the Model-View-Controller
      > architecture was to hopefully go past that and allow web-developers
      > with minimal coding knowledge to create wonderful GUIs. :) Obviously,
      > our development experience aren't the same. I switched from working
      > on NORAD in ADA and C to building the backend of an e-commerce site in
      > Java.

      That could cause different outlooks, yes.

      I think I mentioned a system that was deliberately made hard to use, to
      avoid borking the data. What I'm suggesting is similar. I certain
      intend that the software be flexible. What I don't want is to have to
      design the software so that it can successfully cope with whatever *any*
      user comes up with. IME, leaving extensions like that in the hands of
      programmers (FWIW, IMO someone who can't do analysis isn't a programmer;
      he might be an excellent code monkey, who can implement whatever he's
      told, but not a programmer... elitist bastard, I am) means that they
      tend to be thought through a little better.

      Plus, a certain degree of limitations makes it much easier to create the
      software.

      > > why should we make it easy to build and load bogus data files?
      >
      > Philosophically speaking? To enable/encourage the masses to
      > contribute. To move software development out of our traditional ivory
      > towers. To stop obfuscating our code and instead allow others to
      > contribute. To work as a team instead of individuals.
      > Of course, your philosophy may vary. :)

      To encourage masses to contribute, I think it is better to give them
      clearly-defined structures for the data. It can be frustrating to have
      data files fail because they have errors, but it's *infuriating* to have
      them load but not work correctly because of something the computer could
      have caught.

      I'm not worried about ivory towers (I'm a bazaar type of guy). What I
      have problems with is people who don't know better adding a second,
      buggy way of doing something when a better way is already present. For
      instance, hacking an arbitrary data construct into the files and working
      around it rather than finding the right way to do it. If making a
      change requires the help of a programmer, there's a chance that either
      the right way exists and the programmer will point it out, or that it
      doesn't exist and can be added in a sane fashion.

      Bitter about user-induced hosages? Me? Just because I've had to spend
      hours at a time fixing the damn things?

      I find that limiting the users' choices can make software much easier to
      write and a whole bunch easier to prove correct. (Which, with my
      clients, is really, really important because the software much correctly
      support legislation, provably.)

      I plan to make the system very flexible. Variables (and to a certain
      extent types) will be user-definable, but the structure of the data
      files will be fixed. Flexible, but fixed.


      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
    • David
      New to the list...hello everyone. Just got in off the watching wagon and would like to participate in the XML work if possible. I (and I know most of you may
      Message 2 of 5 , Oct 3, 2002
      • 0 Attachment
        New to the list...hello everyone. Just got in off the watching wagon
        and would like to participate in the XML work if possible. I (and I
        know most of you may cringe) am a VB'er and have been for a long,
        long time. However, I do have a decent amount of experience with OOP
        so no worries there. I have learned XML and how to use the MSXMLDOM
        in several web applications from work.

        So...introduction over, I do have a few comments on some stuff and
        would like to ask a couple of questions.


        --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
        > My expected solution -- the one I monkey with when I have time --
        is to
        > use SAX (Xerces-C++, myself) to parse the data. This is one of the
        > reasons I require that references only be made to items already
        seen, so
        > they can be resolved as they're found. They can be written out to
        XML
        > using whatever technology we want.

        **
        I am somewhat familiar with differences between MSXMLDOM and SAX, but
        not real deep in the differences. Any further comparisons? I do
        know that in contrast to most other 'drivers' (for lack of a better
        term) MSXMLDOM loads the entire document into memory. I know that
        slows things down initially when loading. But once you find what you
        want, an internal database can be loaded and the XML document
        dumped. I have one example of an XML document getting loaded over
        the web that is about a 2000 line document and it loads fairly
        quickly and then is manipulated without any noticeable lag in
        operation. Client side scripting is all done in JavaScript.
        **

        > What I plan to have (and to propose to PCGen) is an internal data
        model
        > (probably close to the XML model, to a certain extent), completely
        and
        > utterly divorced from the loading mechanism. This will make it
        possible
        > to change to a different model -- load everything from an Access
        > (<shudder>) database, say -- without affecting the internal model.

        **
        Kind of goes along with what I said above about finding the data you
        want in the XML document, loading that into an internal db.
        **

        > these changes next time. I know this seems obvious, but I hadn't
        > thought this far ahead -- I've been focusing on getting data into
        the
        > system)

        **
        How are you going about getting the data into the system? Are you
        actually converting LST files to an XML format?
        **

        > > > For instance, actually having specific data types internally to
        > > > represent information.
        > > That much should be obvious to anyone who does any work in Java
        or any
        > > other OO language.
        > Should be. OTOH, there's a lot of parsing and reparsing and parsing
        > again of text data in PCGen, there are a huge number of conversions
        from
        > string to number, and so on. Early on in the XML discussions there
        was
        > talk of using JDOM internally, which would keep things in XML(ish)
        > technology all through runtime.

        **
        Keeping things in an XML object model throughout runtime can make for
        a lot of upfront work...especially in error trapping. This isn't a
        bad thing, but certainly worth taking into consideration.

        A. Do we load data to a custom 'data engine' and make conversions
        later when saved out to XML?

        OR

        B. Do we maintain a tight process whereby nothing slips by without
        proper conversions and not assume anything is cast to a new datatype
        arbitrarily?
        **

        > > > This is not an XML processor, it is a character generator that
        makes
        > > > use of XML files. *Big* difference, IMO.
        > >

        **
        I believe you are right. While it is possible to make pcgen an XML
        processor, it shouldn't be. According to the diagram you drew out,
        the input and output processors should take care of all the XML
        stuff. Once the datamodel is derived, then the rest takes care of
        itself (somewhat). It's the character generation model that ends up
        being most complicated (from what I can tell) in the long run.
        **

        > every program I run under Java is... unsatisfying. I'm not a
        > speed freak, but I shouldn't be waiting for menus to pop up when I
        click
        > them, either.
        >

        **
        My thoughts exactly. I have quite a few issues with Java that I just
        can't take anymore...
        **

        > Hmm... I hadn't considered exceptions here. By nature I'm a C++
        > programmer; exceptions are used for *unexpected* things, such as
        running
        > out of memory or a file suddenly being unwritable (these things can
        be
        > anticipated, but aren't expected). Parsing errors, especially when
        > dealing with human-keyed text, are to be expected and handled more
        > gracefully. IMO, exceptions are not intended to be used for things
        that
        > are expected to go wrong. It's one of the things that drives me
        nuts
        > about Java, actually, is how exceptions are used for things like
        parse
        > errors.

        **
        Ack...parsing doesn't become much of an issue with a good XML model
        and driver.
        **

        > On the one hand, they *do* force you to check for errors. OTOH,
        > sometimes I... just don't care. There's no way I know of to say
        t'hell
        > with it and let it go. Java may try to enforce better engineering,
        but
        > I prefer to do it myself.

        **
        XML forces a strict standard as well. And, anyone can write an XML
        document and run it through Internet Explorer to check the basic
        document for errors before ever submitting it.
        **


        > Style and language issue. I can do OO in Java and write Java code,
        but
        > I don't like the way some things are done in Java. I don't like
        the way
        > some things are done in C++ either, but I'm more accustomed to it, I
        > find it faster, and I have templates!
        >
        > Ah well, language debate is definitely OT <g>

        **
        I don't think the language debate is that far off topic really. It's
        easy enough to know why this isn't being written in VB. However, I
        think that there are other options that using Java. C++ is an
        excellent option...but that kind of puts me on the outside of the
        loop. I have more book knowledge of C++ than practical experience.
        But, that doesn't mean I couldn't help.

        Has anyone considered writing for a browser instead? I am *very*
        knowledgeable with JavaScript. It is easy enough to write the script
        in a manner that is portable across navigator, IE and opera.
        **


        > To encourage masses to contribute, I think it is better to give them
        > clearly-defined structures for the data. It can be frustrating to
        have
        > data files fail because they have errors, but it's *infuriating* to
        have
        > them load but not work correctly because of something the computer
        could
        > have caught.

        **
        What has promoted Army Builder so well is a tool that helps users
        build datafiles without the need for a programmer to ensure the data
        conforms to the standard.

        While the tool itself is very difficult to manage in the beginning,
        once a user has a basic understanding of it's mechanism and process
        it's fairly easy to use...but tedious as h3!!.

        Just a thought, then. If you want users to be able to create
        datafiles for PCGen then a structure is enough. A structure may be
        fine for analysists or 'real' programmers <g>, but for the general
        public it isn't.
        **


        Anyway...there's my $.00002 cents worth.
        dB
      • Keith Davies
        ... Hi David, ... The primary difference here is that DOM (whether MS or otherwise) loads the entire structure and maintains it in an XML-ish format. That is,
        Message 3 of 5 , Oct 3, 2002
        • 0 Attachment
          On Thu, Oct 03, 2002 at 01:59:55PM +0000, David wrote:
          > New to the list...hello everyone.

          Hi David,

          > **
          > I am somewhat familiar with differences between MSXMLDOM and SAX, but
          > not real deep in the differences. Any further comparisons? I do
          > know that in contrast to most other 'drivers' (for lack of a better
          > term) MSXMLDOM loads the entire document into memory. I know that
          > slows things down initially when loading. But once you find what you
          > want, an internal database can be loaded and the XML document
          > dumped. I have one example of an XML document getting loaded over
          > the web that is about a 2000 line document and it loads fairly
          > quickly and then is manipulated without any noticeable lag in
          > operation. Client side scripting is all done in JavaScript.
          > **

          The primary difference here is that DOM (whether MS or otherwise) loads
          the entire structure and maintains it in an XML-ish format. That is, as
          nodes containing attributes, subnodes (children, such as other elements
          and text strings), and so on. The structure is the same as when it was
          loaded. SAX runs through the entire structure once and tells the client
          code what it finds, as it finds it, and lets the client code decide what
          to do about it. When SAX reaches the end of the file, it's done. If
          you want to remember anything about what you read, you have to manage
          that yourself.

          In the tests and examples I've seen, SAX always outperforms DOM *if* you
          can process the document in a single pass. If you have to be able to
          search the data or make more than one pass, it becomes more efficient to
          use DOM than SAX as long as you're limiting yourself to XML technology
          (not storing it inside your program yourself, that is).

          DOM can be useful. For our purposes, though, I don't think it would be
          sufficient because in most cases we don't really care how the data is
          structured. That is, I don't care what file it came out of or about the
          implementation within the file.

          Picture the master spell list. All the spells you use in the game. Do
          you really care that:

          <file>
          <spells>
          <spell id="">
          <name/>
          <components>
          <verbal/>
          <somatic/>
          <material/>
          </components>
          </spell>
          <spell id="">
          <name/>
          <components>
          <verbal/>
          <somatic/>
          <material/>
          </components>
          </spell>
          <spell id="">
          <name/>
          <components>
          <verbal/>
          <somatic/>
          <material/>
          </components>
          </spell>
          </spells>
          </file>
          <file>
          <spells>
          <spell id="">
          <name/>
          <components>
          <verbal/>
          <somatic/>
          <material/>
          </components>
          </spell>
          </spells>
          <!-- ... -->
          </file>

          Or, after everything is loaded, would you prefer to see something like:

          class Datastore {
          private:
          Map<string, Feat > feats;
          Map<string, Skill> skills;
          Map<string, Spell> spells;
          public:
          const &Feat feat ( const string &id);
          const &Skill skill( const string &id);
          const &Spell spell( const string &id);
          };

          In the former case, to retrieve a particular spell you would have to do
          (using XPath in Java) something like

          Node s = DOM.find_node( "spell[@id='" + id + "']");

          Then construct the spell information from there. It is necessary for
          the person looking for the information to know that name will come from
          a subelement, as will the component list, but that the id and... I
          dunno, perhaps that the spell is affected by spell resistance (I didn't
          pick the best example here -- skill might've been better) is identified
          by an attribute. Assuming you don't go to the trouble of writing a
          wrapper class such as

          class Skill {
          Skill( string id) {
          Node s = DOM.find_node( "skill[@id='" + id + "']");
          /*technically, I suppose you might do "id(" + id + ")" rather than
          the example above. I'm not awake yet*/
          // construct skill object from node found
          }
          string name();
          // ...
          }

          it would be necessary to do this every time you want to look at a
          spell.

          OTOH, if the object is specifically coded in the program (class Spell)
          and built during load as the SAX events are handled, you get an
          efficient in-memory structure, you do it once, and you can do it
          quickly. The context present can save you a lot of hassle, too -- the
          load might look like:

          find a new element (a spell)
          create Spell object, applying attributes as needed
          while subelements found (I'm simplifying here)
          look at subelement type and add to Spell as appropriate; find a
          <name>, set Spell.name(), etc.
          spells[ spell.id()] = spell

          Then when you need it you go a single place and have a very efficient
          way to find it. It loads pretty quickly, and you don't have to process
          everything as XML after it's loaded -- it divorces the file
          representation from the internal.

          > > What I plan to have (and to propose to PCGen) is an internal data
          > model
          > > (probably close to the XML model, to a certain extent), completely
          > and
          > > utterly divorced from the loading mechanism. This will make it
          > possible
          > > to change to a different model -- load everything from an Access
          > > (<shudder>) database, say -- without affecting the internal model.
          >
          > **
          > Kind of goes along with what I said above about finding the data you
          > want in the XML document, loading that into an internal db.
          > **

          Pretty much.

          > > these changes next time. I know this seems obvious, but I hadn't
          > > thought this far ahead -- I've been focusing on getting data into
          > the
          > > system)
          >
          > **
          > How are you going about getting the data into the system? Are you
          > actually converting LST files to an XML format?
          > **

          Ideally, yes, we'll have a tool (built directly into PCGen or not) that
          can do batch conversion of LST to XML.

          > > > > For instance, actually having specific data types internally to
          > > > > represent information.
          > > > That much should be obvious to anyone who does any work in Java
          > or any
          > > > other OO language.
          > > Should be. OTOH, there's a lot of parsing and reparsing and parsing
          > > again of text data in PCGen, there are a huge number of conversions
          > from
          > > string to number, and so on. Early on in the XML discussions there
          > was
          > > talk of using JDOM internally, which would keep things in XML(ish)
          > > technology all through runtime.
          >
          > **
          > Keeping things in an XML object model throughout runtime can make for
          > a lot of upfront work...especially in error trapping. This isn't a
          > bad thing, but certainly worth taking into consideration.

          We're already looking at a lot of work. I'm not looking forward to
          having to ensure, every time I look into the data, that it's sane. I
          know a validating parser can handle this ("hey! There's no name here!")
          but, unless it uses XML Schema (or similar) and can examine text string
          formats (looking for numbers, say) there's no way to confirm that the
          text found is correctly formatted. DOM just sucks the whole thing up in
          one shot.

          With the model I'm looking at, we use SAX, and as each element is loaded
          the loader knows what it's supposed to look like, etc., and does
          something intelligent with it. For instance, numerical ratings get
          parsed into integer members (which is where we'll need them, of course)
          of the appropriate object class. If the conversion fails, we can stop
          immediately or otherwise flag the error.

          > A. Do we load data to a custom 'data engine' and make conversions
          > later when saved out to XML?

          That's what I plan and expect to do.

          > OR
          >
          > B. Do we maintain a tight process whereby nothing slips by without
          > proper conversions and not assume anything is cast to a new datatype
          > arbitrarily?

          The two options are not exclusive. The design I'm looking at is pretty
          strict in interpretation and checks as much as possible as soon as
          possible. I don't want to be in the middle of processing a character
          and suddenly find that the data I need is incorrectly formatted (for
          instance, the weight of an item is '1 0' pounds rather than '10' -- the
          former isn't parseable as an integer, but it is a string).

          > **
          >
          > > > > This is not an XML processor, it is a character generator that
          > makes
          > > > > use of XML files. *Big* difference, IMO.
          > > >
          >
          > **
          > I believe you are right. While it is possible to make pcgen an XML
          > processor, it shouldn't be. According to the diagram you drew out,
          > the input and output processors should take care of all the XML
          > stuff. Once the datamodel is derived, then the rest takes care of
          > itself (somewhat). It's the character generation model that ends up
          > being most complicated (from what I can tell) in the long run.
          > **

          It doesn't have to be, actually. All it has to know is how to make
          certain changes to the character. The data engine has to handle what
          those changes actually mean. For instance, we might see:

          Character Engine (CE): add level(rogue) to character(a)
          Data Engine (DE): okay, that means
          ... bump Ref save by 1
          ... add d6 hp
          ... add 8 + modifier( Int) skill points
          ... increase sneak attack by d6
          CE: I change my mind. Take it back off
          DE:
          ... reduce sneak attack by d6
          ... remove skill points and assigned ranks, if any
          ... remove added hit points (no, don't roll, remove the amount
          rolled before
          ... reduce Ref save by 1

          The character engine just needs to know what kinds of transformations
          can be made (which comes from the data files, of course); what those
          transformations *mean* is dependent on the data, and therefore handled
          by the data engine.

          I suppose I chose a poor word for it. The character generation engine
          is what allows transformations to be done on the data, or rather,
          specification of the transformations allowed. This is where the user
          identifies classes to add, skill rank allocation, and so on. The
          internal representation is hidden from him, though, which greatly
          simplifies things.

          Actually, I guess there could be three layers. The first holds the
          data, the second performs the transformations (and passes back requests
          for further information to the front end) and the front end gathers
          instructions from the user. For instance,

          GUI: add a level of rogue
          Transformation Engine (TE): (make changes described above)
          TE: added skill points, skill ranks must be purchased; tell GUI
          GUI: oh! Okay. Display 'add skill ranks' form
          GUI: add 4 ranks Gather Information
          TE: okay
          GUI: add 4 ranks Tumble
          TE: okay
          GUI: add 2 ranks Perform( Juggle)
          TE: okay

          or something like that. This may be a better way to go.

          > **
          > Ack...parsing doesn't become much of an issue with a good XML model
          > and driver.
          > **

          Not true. In some senses it becomes easier (certain error conditions
          are easier to catch, such as mismatched element tags) but it's still
          necessary to confirm that what is present is what is supposed to be
          present (see number formatting, above). Validation ensures that the
          file is well-formed and meets the XML (and DTD/Schema) specification, it
          doesn't alone ensure that the data present is sane.

          > **
          > XML forces a strict standard as well. And, anyone can write an XML
          > document and run it through Internet Explorer to check the basic
          > document for errors before ever submitting it.
          > **

          A standard for formatting, not content. That something is valid XML and
          even complies to a DTD or Schema does not necessarily mean that it's a
          good file. Knowledge of the problem domain is necessary to prove that.

          For instance, I've got a validation script I run at work. It ensures
          that the data files being transferred between systems are valid -- that
          they are properly formatted and, when possible, does some sanity checks.
          However, I can't prove that the data file is correct -- the data itself
          is bogus -- because the script doesn't know enough to say so. It does
          know enough to say whether it looks okay. The programs that load the
          files can take it on faith that it is correctly formatted, but still
          have to do their sanity checks. Specific case: the validation script
          doesn't know all the address IDs in the system (places where people can
          live). It can't -- it would be impossible to maintain the list. So,
          when a data file comes in the script can look at it and say 'ten digits,
          leading 0s if needed, yep, it *looks like* an ID'. The program loading
          the file can still fail if that ID doesn't exist -- 'he lives *where*?
          You're only supposed to send me good IDs; this one isn't, so something's
          wrong' (in this case two IDs were swapped (road ID and address ID, IIRC)
          so the fields contained the wrong data).

          I can rely on XML valiation to pick up some errors, but not everything.

          > **
          > I don't think the language debate is that far off topic really. It's
          > easy enough to know why this isn't being written in VB. However, I
          > think that there are other options that using Java. C++ is an
          > excellent option...but that kind of puts me on the outside of the
          > loop. I have more book knowledge of C++ than practical experience.
          > But, that doesn't mean I couldn't help.

          C++ isn't a bad one. However, the current bunch of programmers are
          using Java and it's doing an adequate job. It is also sufficiently
          multiplatform that switching to something else would be problematic --
          it has been decided that we aren't going to stop supporting any of the
          current platforms, and while there are crossplatform libraries that work
          on the main platforms we support, switching to them would entail not
          just changing languags but toolkits. The learning curve would be brutal
          and, frankly, probably not worth it.

          For PCGen. The code I'm writing for myself that'll use the data will
          likely be C++ because it *does* meet my needs.

          > Has anyone considered writing for a browser instead? I am *very*
          > knowledgeable with JavaScript. It is easy enough to write the script
          > in a manner that is portable across navigator, IE and opera.

          I don't know that JS can handle the amounts of data we're talking about.
          I'd rather stick with what we have -- we *know* that it works, and will
          only get better as we improve the internal structures.

          > **
          > What has promoted Army Builder so well is a tool that helps users
          > build datafiles without the need for a programmer to ensure the data
          > conforms to the standard.

          We're planning to create editors for the various things; I don't want to
          *have* to key XML to use the software. I don't care if users do use
          text editors to create and change files. What I don't want is users to
          be able to simply, blindly add 'features' to the system that the system
          isn't yet prepared to handle -- IME, it's usually done wrong.

          Any time I create a domain-specific editor, I try to ensure that the
          business rules are enforced (somewhere along the line). If I don't
          allow bogus data in, I don't have to worry about dealing bogus data
          while I'm working.

          > Just a thought, then. If you want users to be able to create
          > datafiles for PCGen then a structure is enough. A structure may be
          > fine for analysists or 'real' programmers <g>, but for the general
          > public it isn't.

          I'm sorry, this doesn't parse. You seem to contradict yourself above.


          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
        • David
          A typo...should have read... If you want users to be able to create datafiles for PCGen then a structure *isn t* enough. Basically, if a utility is provided
          Message 4 of 5 , Oct 3, 2002
          • 0 Attachment
            A typo...should have read...
            "If you want users to be able to create datafiles for PCGen then a
            structure *isn't* enough."

            Basically, if a utility is provided for the public to be able to add
            features (ie, their own game systems, characters, prestige classes,
            etc) you can validate the formats and the data for it is released
            into pcgen. Then, verifying that the data isn't bogus becomes a
            function of the input utility.

            That make more sense?

            dB



            --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
            > > Just a thought, then. If you want users to be able to create
            > > datafiles for PCGen then a structure is enough. A structure may
            be
            > > fine for analysists or 'real' programmers <g>, but for the
            general
            > > public it isn't.
            >
            > I'm sorry, this doesn't parse. You seem to contradict yourself
            above.
          • Keith Davies
            ... Yep. It s what I was planning to do. Keith -- Keith Davies keith.davies@kjdavies.org PCGen: , smartass You just can t argue with a moron. It s
            Message 5 of 5 , Oct 3, 2002
            • 0 Attachment
              On Thu, Oct 03, 2002 at 03:26:00PM +0000, David wrote:
              > A typo...should have read...
              > "If you want users to be able to create datafiles for PCGen then a
              > structure *isn't* enough."
              >
              > Basically, if a utility is provided for the public to be able to add
              > features (ie, their own game systems, characters, prestige classes,
              > etc) you can validate the formats and the data for it is released
              > into pcgen. Then, verifying that the data isn't bogus becomes a
              > function of the input utility.
              >
              > That make more sense?

              Yep. It's what I was planning to do.


              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.