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

Re: [pcgen-xml] XML plan summary

Expand Messages
  • Keith Davies
    ... Ah. Right. Damn. Okay. This ll complicate the loader a bit -- I was hoping for a fairly simple process as found -- but I think we can deal with it.
    Message 1 of 21 , Mar 6, 2003
    • 0 Attachment
      On Thu, Mar 06, 2003 at 01:24:44AM -0500, Eric Beaudoin wrote:
      > At 11:00 2003.03.05, Keith Davies wrote:
      >
      > >I need to examine how loading works now, before I go any further. I
      > >think that, unless I find something different, we'll continue with the
      > >existing load semantics. They seem awkward, though.
      >
      > The RANK is usefull to see which .MOD gets apply before which other
      > .MOD. It also (I beleive) help resolve if a .COPY copy the .MOD object
      > or the original.

      Ah. Right. Damn. Okay. This'll complicate the loader a bit -- I was
      hoping for a fairly simple 'process as found' -- but I think we can deal
      with it.

      > >I still believe that we need unique ID values for all items loaded;
      > >regardless of it being LST, XML, or RDBMS, this *is* a database, and
      > >having unique IDs makes things much easier to work with.
      >
      > I'd like use the name and use it as unique key (and forget the ID altogether).

      <shrug> call it 'name', call it 'id', doesn't matter as long as there is
      one and it conforms to XML ID specification. It's customary to call it
      'id', though, and I think that when people see 'name' they're going to
      be prone to put in exactly what it says in the book.

      > I beleive many are .MOD and even .COPY so they reference an item and
      > make little modification to it (e.g. adding the DESC: tag to feats or
      > the page number with SOURCEPAGE: ).

      If we put in an interim file that maps the current NAME values to ids we
      should be able to minimize the impact here. Good point, though.

      > We must also think that this XML definition might becaume a de-facto
      > standard.

      I hope not, at least not this one. This schema is a little too rough
      yet.

      > We should make sure that application outside of the PCGEN
      > project can work with the data (basicaly, we should not think only of
      > ourselves). So, with that in mind, I wonder how we would convert a
      > Jamis Buck's NPC to our format? It won't have IDs. The only option I
      > see if we really needs the IDs is to generate them from other
      > arguments that are mandantory. That way, when we import data from
      > somewhere else, we'll be able to produce the ID.

      That would work okay. Or, if interoperability is needed, have the
      third-party software generate IDs. While we want to make it easy for
      others to interact with and use the data, the primary focus is to make
      it work for ourselves.

      > >Schema's a pain in the ass, though.
      >
      > I never thought we wanted to use DTD since you've been talking about
      > schemas all along. I thought we wanted to stay away of it because it's
      > not very flexible and do not allow to do much data type validation.

      By schema I was referring to file data model; schema is a pretty common
      term (I thought) for data models in general.

      > Since you don't like XML Schema, did you look into the alternatives:
      > RELAX-NG or Schematron ?

      Actually, as I said elsewhere, I think we'll end up going with something
      we build ourselves that is more tuned to gaming information. We don't
      need the full power of XSD; I think we can (later) build a data language
      that will suffice for describing types of gaming information. Matter of
      fact, we might want to hammer that out because it gets rid of lots of
      the concerns I have about validation.

      > >I've never used XHTML. I understood that it is simply HTML made
      > >XML-compliant.
      >
      > More or less yes. One thing for sure, there are no enforce order with it.

      Largely because it's a document/presentation mechanism that has to be
      able to handle arbitrary text and formatting. This schema is used to
      handle d20 (in the future, more or less general) gaming information.
      Two significantly different purposes. There are rules about data
      required and the like for various data types, and for the cost of a bit
      of discipline we can make it easier to validate and enforce these rules.

      > >> Moding and Subclassing do not do the same thing. Mod change the
      > >> original element and do not add new elements. Every Wizards are
      > >> differents from then on. SUBCLASS was made with specialist in mind.
      > >> You chose wizard but you can/have to chose a particular flavor of
      > >> wizard.
      > >
      > >It can be used for other purposes, though. I can see subraces (various
      > >flavors of elf or dwarf, subskills (like Knowledge, for instance), and
      > >so on. What say we have a namespace 'sub' that creates a subordinate
      > >copy of an identified element then applies changes to it? It will
      > >behave much like copy but more accurately describes what is happening
      > >and, incidentally, makes it easier to identify and change later on if we
      > >decide to?
      >
      > Yea, there is another thing with subclassing though, you narmally have
      > a chooser that pop to let you select which sub-class you use. In the
      > case of the Specialist Wizard, you can choose the Wizard or one of the
      > specialist and then a second chooser appear (if you chosed the a
      > specialist) to let you choose the schools you won't get. In the case
      > of the Psionics, you need to choose a speciality (there is no base
      > psy). So, right now SUBCLASS most internaly be very deeply link to the
      > CLASS. We need a code monkey to tell us for sure I guess.

      It's not terribly difficult to key these relationships back from the
      sub<item> to the parent. During load we can even build a list in the
      parent that has links back to the children/subs.

      > The race are done with template right now. Sub for race is a good idea
      > but it will need to happen after phase 1 or it would change internal.

      We can convert from our schema to the internal model, as long as we
      don't lost any information during the conversion to XML.

      > >So, the example above would be
      > >
      > > <sub:class ref="class.wizard"
      > > id="class.illusionist"
      > > master="class.wizard">
      > > <name>Illusionist</name>
      > > <!-- identify barred schools; I don't know this yet -->
      > > </sub:class>
      > >
      > >Makes it clear that it is closely related to the parent, gives us the
      > >ability to sub... um, create a subelement of more things and provides an
      > >interface consistent with the thing being subbed.
      > >
      > >> COPY right now really copy the object in memory whereas SUBCLASS just
      > >> add to the existhing object. Francly, I don't care about this diffence
      > >> but I thought I'd mentionned it in case it make a difference for you.
      > >
      > >So... what use is COPY, then? I don't think I see the benefit to just
      > >duplicating something in memory.
      >
      > New Name.COPY=Original Name NEWTAG:newvalue ...
      >
      > The .COPY create a new object that you then modify. The original
      > object stays in and can also be accessed. .MOD modify the original
      > object.

      Ah, okay, so it's pretty much like I described above:

      <copy:class id="class.new-wizard" ref="class.wizard">
      <!-- make changes -->
      </copy:class>

      It keeps everything inherited from the referenced item, gives it a new
      ID, and allows changes of the inherited data.

      > The is also a syntax to remove an object (.REMOVE I think).

      <mod:class ref="class.sorcerer" action="remove" />

      > >> The columns will be large enough as they are, no need to get them
      > >> larger if we need to. Vertical formatting might not be possible
      > >> anyway so it's not a big point. That's actually one bad thing about
      > >> the XML format, we will have to look at the data one record at a
      > >> time instead of looking at tables like we used to.
      > >
      > >Inside the program it'll still be loaded into tables. We don't have
      > >time to make changes of the kind of scope needed to change that.
      >
      > I'm talking about the human looking at the data files. He looks at the
      > books and see tables. Right now, he looks at the files and also see
      > tables. It would have been nice to find a way to format our XML in
      > table.

      Ah, okay, I see now. Yep, nothing for it. XML is verbose, and they way
      we're talking about supporting it (especially with the ordinality stuff
      we were talking about the other day) we're stuck with that.

      > It will a long time before having an editor that his good enough to
      > convince the main data monkeys to move away from their favorite text
      > editor. We should try to make a format that will be workable. If you
      > are not convince about this, just check the number of Code Monkeys
      > that still prefer using a standard text editor for Java (starting with
      > Bryan) even though the Java EDI have become quite mature and well
      > supported.

      Hey, I cut C/C++ code using vi/vim. I know what you mean.

      > >> >I've always considered prereqs, for example, to be closely enough
      > >> >related that we want them in one place. I don't want to be
      > >> >looking through the entire object to find all the prereqs. So,
      > >> >while XML does not technically require it and we could do without,
      > >> >I think it's a good idea for style reasons.
      > >>
      > >> Let's not impose style in the language. They can be grouped
      > >> togetter without adding the extra element.
      > >
      > >I think there are sufficient benefits to include the parent element.
      >
      > I guess we agree to disagree. Since there is no grouping of family of
      > tags right now with the .lst files, I suggest we pospone this debate
      > for phase 3.

      Trade you -- give you this (though I think it's useful) for IDs (which I
      think will be necessary).

      > >I saw NAMEISPI and DESCISPI somewhere (the tag doco, I think), but I
      > >didn't notice them in the line/tag doco you sent me the other day.
      > >It may be that they are not present in the data, in which case we
      > >might consider their removal and just put a 'ispi' attribute at the
      > >top of the game data description. The entire object or nothing,
      > >simple.
      >
      > When we roll out the new OGL compliant sources, you will see a lot
      > more of those. You will also see them in the CMP files. They need to
      > stay there.
      >
      > You might be right though, a single ispi might be all we need. You
      > would have to check with Paul King for this one.

      Will do. I think that CMP files and PCGen files will be separate
      distros and this won't be a particular problem, but I'll ask.


      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
    • Keith Davies
      ... It will. It won t be as elegant as I d been planning (you still have to mod the spell :/) but it ll be there. Keith -- Keith Davies
      Message 2 of 21 , Mar 6, 2003
      • 0 Attachment
        On Thu, Mar 06, 2003 at 01:31:22AM -0500, Eric Beaudoin wrote:
        >
        > Have you tried DOMAINS:.CLEAR[tab]DOMAINS:new domain
        >
        > If this do not already work, make a FREQ for it. That's the official
        > way to do it with the .lst files.
        >
        > Same type of functionnality will have to be provided by the XML
        > syntax.

        It will. It won't be as elegant as I'd been planning (you still have to
        mod the spell :/) but it'll be there.


        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
      • Keith Davies
        ... dunno. See, we can have the same name for different data types; IDs make that irrelevant. ... I would think that if an item is MODed the ID stays the same
        Message 3 of 21 , Mar 6, 2003
        • 0 Attachment
          On Thu, Mar 06, 2003 at 09:52:53AM -0500, CC Americas 1 Carstensen James wrote:
          > Eric wrote:
          > >>That would, of course, do it. Make all the names unique, at least
          > >>within a single data type, then create the ID as above. That makes
          > >>sense.
          > >>
          > >>I still believe that we need unique ID values for all items loaded;
          > >>regardless of it being LST, XML, or RDBMS, this *is* a database, and
          > >>having unique IDs makes things much easier to work with.
          > >
          > >I'd like use the name and use it as unique key (and forget the ID
          > > altogether).
          >
          > Two questions:
          >
          > 1. With a name, how do we ensure it is unique?

          dunno. See, we can have the same name for different data types; IDs
          make that irrelevant.

          > 2. From an end result side, if the name of an object (class, race,
          > eq, feat, spell, etc) gets .MODded, should that change the unique key
          > or not?

          I would think that if an item is MODed the ID stays the same because
          that identifies the item and it's still the same item. If an item gets
          COPYed the new item would need a new ID assigned.

          Of course, it may be desirable to MOD the ID of an item, but I don't
          even like to think about the semantics and behavior of that. I think
          this case might be handled better by

          <copy:item ref="item.id" id="item.new-id" />
          <mod:item ref="item.id" action="delete" />

          because we could probably expect this to be handled properly by the
          program anyway. Still thinking on this.


          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
        • Keith Davies
          ... I don t know about this fine-grained dependency stuff; as it stands if you want to load an XML file you get everything that s in it. While we *could*
          Message 4 of 21 , Mar 6, 2003
          • 0 Attachment
            On Wed, Mar 05, 2003 at 10:41:06AM -0700, Devon Jones wrote:
            > Keith Davies wrote:
            >
            > >On Mon, Mar 03, 2003 at 10:10:48AM -0800, Keith Davies wrote:
            > >
            > > It will be allowable for two files to be mutually dependent
            > > (though it's a good idea to avoid that when possible). The
            > > loader will be able to successfully deal with this.
            > >
            > This opens up one fantastic thing. I'm sick and tired of my players
            > loading up something like oriental adventures, and as a result, all
            > characters modified in that session now depend on OA *Rolls Eyes*.
            > Even if we don't export all the data with every .pcg, we have the
            > capability with this and the finer grained dependancy stuff you talk
            > about in later messages to be accurate about what sources a character
            > *really* depends on - not just a list of what files were loaded when
            > the character was created.

            I don't know about this 'fine-grained dependency' stuff; as it stands if
            you want to load an XML file you get everything that's in it. While we
            *could* load (or at least, keep) just the bits we're interested in, it
            makes for an awkward file-handling model.

            Now, one possibility I was considering is that PCGen maintains a central
            store of data, and when people want to add new data files they get
            'loaded' -- the items read, pulled apart, the 'index files' you were
            talking about created, and the items written out to files containing
            minimal information each. Identify a minimal subset of information
            needed for all items and load that so that at all times so it's
            available and points at the files that contain the rest of the data.
            Defer loading of the rest of the information until it's needed (such as,
            when displaying a list of equipment, only the name and cost are present
            and descriptions get loaded as and when needed).

            This is *not* even considered for this phase. It makes things more
            complex than they are now and doesn't do a lot to make things better.
            Also, having that many files would be prohibitive in system space
            (though if we could JAR them all or something it might be worthwhile.

            Later...

            > > So, some specific examples:
            > >
            > > fireball => spell.fireball
            > > delayed blast fireball => spell.delayed-blast-fireball
            > > Melf's acid arrow => spell.melfs-acid-arrow
            > >
            > > Ranger => class.ranger
            > > Monte's Ranger => class.ranger.monte-cook
            > >
            > I know this is a detail that will be not be important for some time,
            > but I think it's important to at least point it out - with things like
            > Melf's Acid Arrow, we should use the SRD name (Acid Arrow), and let
            > the CMP datasets .MOD Acid Arrow to add the PI.

            For SRD files, I agree. However, eventually non-OGL files will be
            available, and I needed an example that had punctuation in it. Melf's
            Acid Arrow (as opposed to Acid Arrow) was chosen deliberately for the
            purpose of discussion and example.

            For PCGen files, of course we'll stick to the SRD name.

            > Basically what I intend from this is that none of the IDs should have
            > PI in them - so that we don't get sued ;)

            If the item being described is PI, it makes sense to keep it in the
            ID... we're not going to get busted for the ID if the data is
            acceptable.

            > This is fantastic, as it can eventually lead to much more sophesticated
            > loading and parsing - such as that mentioned in a different message
            > relating to OR with prerequisites.
            >
            > This should probably be used for most elements. Prereqs, Bonuses,
            > etc. this will IMHO make things *WAY* more supportable.

            I think it should be as well, but we might not do it right now.

            One thing I'd *really* like to see is breaking the various dot-, comma-,
            and pipe-lists into proper lists so they don't need to be parsed and
            examined so often.


            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.