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

Re: [pcgen-xml] Re: XML Design Guidelines

Expand Messages
  • Peter Kahle
    ... Fair enough. ... Um... wouldn t matching on list[@type= weapon ] be more or less the same as matching on weapon-list? I mean, probably a little more
    Message 1 of 13 , Feb 5, 2002
    • 0 Attachment
      On Tue, Feb 05, 2002 at 12:40:43PM -0800, Keith Davies wrote:
      >
      > I'm trying to keep them down, but not to a minimum. When it really
      > does describe something different (such as a reference to a list rather
      > than an object) I'd rather have a different element.
      >

      Fair enough.

      > For instance, at one point I was tempted to just make the classification
      > objects <list>s -- regardless of what they were listing. Makes it nice,
      > simple, and consistent. All good things. However, the ability to find
      > lists of certain things (such as of weapons, or spells, and so on) made
      > that a poor decision, so I decided not to go that way.

      Um... wouldn't matching on list[@type='weapon'] be more or less the same
      as matching on weapon-list? I mean, probably a little more processing
      needed, but functionally pretty mucht he same, right?

      > I'm still trying to figure out a nice way of doing spell assignments --
      > getting them into the right list is easy, but specifying the levels in
      > a useful manner is annoying. The list assignment will work much like
      > above, and for the same reasons (the assignment is separate from the
      > reference and classification objects to reduce the impact of adding
      > new reference or classification objects).
      >
      > I could do something like

      Option 1

      > <spell-list id="spell-list.abjuration" />
      > <list-entries list-id="spell-list.abjuration">
      > <list-ref refid="spells-list.abjuration.0" />
      > <list-ref refid="spells-list.abjuration.1" />
      > <list-ref refid="spells-list.abjuration.2" />
      > <list-ref refid="spells-list.abjuration.3" />
      > <list-ref refid="spells-list.abjuration.4" />
      > <list-ref refid="spells-list.abjuration.5" />
      > <list-ref refid="spells-list.abjuration.6" />
      > <list-ref refid="spells-list.abjuration.7" />
      > <list-ref refid="spells-list.abjuration.8" />
      > <list-ref refid="spells-list.abjuration.9" />
      > </list-entries>
      >
      > <spell-list id="spell-list.abjuration.0" level="0"/>
      > <list-entries list-id="spell-list.abjuration.0">
      > <ref />
      > <ref />
      > <ref />
      > </list-entries>
      >
      > Which does have the happy effect of breaking the lists down by level as
      > well... it seems disatisfying, though. I could do

      Option 2

      > <spell-list id="spell-list.abjuration" />
      > <list-entries list-id="spell-list.abjuration">
      > <spell-ref refid="spell.shield" level="1"/>
      > <!-- ... -->
      > </list-entries>
      >
      > but that would get *really* old, *really* fast, and doesn't necessarily
      > gain us anything. I suppose I could do something like

      Option 3

      > <spell-list id="spell-list.abjuration">
      > <level-list id="spell-list.abjuration.0" level="0" />
      > <level-list id="spell-list.abjuration.1" level="1" />
      > <level-list id="spell-list.abjuration.2" level="2" />
      > <level-list id="spell-list.abjuration.3" level="3" />
      > <level-list id="spell-list.abjuration.4" level="4" />
      > <level-list id="spell-list.abjuration.5" level="5" />
      > <level-list id="spell-list.abjuration.6" level="6" />
      > <level-list id="spell-list.abjuration.7" level="7" />
      > <level-list id="spell-list.abjuration.8" level="8" />
      > <level-list id="spell-list.abjuration.9" level="9" />
      > </spell-list>
      >
      > <list-entries list-id="spell-list.abjuration.1">
      > <ref refid="spell.shield" />
      > </list-entries>
      >
      > Which, to some extent, introduces a higher degree of structure and
      > reduces the number of lists running around. The <level-list>s (or
      > I could even make them <spell-list>s... there're benefits to that)
      > are thereby locked within the master list, as they should be, and
      > easily isolated so they don't appear when searching for top-level
      > lists. It also maintains a little more consistency with the other
      > <*-list> types.
      >
      > 'course, the above is a little annoying for <domain>s, because each
      > domain refers to a <spell-list>, and there will (usually) be only
      > a single spell for each level in the domain. The SSS books add spells
      > to the domain lists, though, so we'll have to support it, and this is an
      > easy way of doing so... okay, never mind the complaint. It's not *that*
      > much of a hardship.

      I agree with you that Option 2 is pretty ugly, but by combining it with
      Option 3, you may be able to simplify domains, and those cases where you
      would have a very few spells in a level. For example:

      <spell-list id="spell-list.abjuration" />
      <spell-list id="spell-list.abjuration.1" />
      <list-entries list-id="spell-list.abjuration.1">
      <spell-ref refid="spell.shield" level="1"/>
      </list-entries>
      <list-entries list-id="spell-list.abjuration">
      <spell-list id="spell-list.abjuration.1" />
      <spell-list id="spell-list.abjuration.2" level="2" />
      <spell-list id="spell-list.abjuration.3" level="3" />
      <spell-list id="spell-list.abjuration.4" level="4" />
      <spell-list id="spell-list.abjuration.5" level="5" />
      <spell-list id="spell-list.abjuration.6" level="6" />
      <spell-list id="spell-list.abjuration.7" level="7" />
      <spell-list id="spell-list.abjuration.8" level="8" />
      <spell-list id="spell-list.abjuration.9" level="9" />
      </list-entries>

      Basically, use spell-list-ref and spell-ref and allow you to define the
      level for either. if you have a defined level for a spell in a list that
      you're re-defining the level as you make a composite list, then use the
      spell-list-ref's level instead of the spell-ref's. It's not perfect, but
      it seems like it might be the best of the available options. Then again,
      it might leave too much flexibility, at the expense of the ease of
      processing. Let me know what you think.

      > > But in general, you seem to have more experience with this stuff than I
      > > do, so I'll defer to your decisions. (and keep offering suggestions when
      > > they strike me.)
      >
      > Well, you've raised some good points and made me think of things that
      > I hadn't yet (and perhaps wouldn't have), so it's been beneficial. If
      > I seem to ignore what you suggest, don't worry -- I do read and think
      > about suggestions, but I have a pretty good idea where I'm going <g>

      Heh.

      > Thanks for the feedback.

      No problem.
      P

      > Keith
      > --
      > Keith Davies
      > kjdavies@...
      >
      > Logan: "I don't think it's a good idea."
      > Raven: "The vote is three to one against you -- me, the crystal ball,
      > and the little voices in your head."
      >
      >
      > To unsubscribe from this group, send an email to:
      > pcgen-xml-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >

      --

      Those who would give up essential Liberty to purchase a little temporary
      safety, deserve neither Liberty nor safety.
      -- Ben Franklin

      || Peter M Kahle Jr || PGP Public Key on Keyservers ||
      || pkahle@... || http://pops.dyndns.com/~pkahle/ ||
      ##===============================##======================================##
    • Keith Davies
      ... It would, actually... and the classification and assignment elements are meant to be fairly simple, as their only purpose is to allow me to group things in
      Message 2 of 13 , Feb 5, 2002
      • 0 Attachment
        Peter Kahle wrote on Tue Feb 5 13:04:04 2002:
        >
        > On Tue, Feb 05, 2002 at 12:40:43PM -0800, Keith Davies wrote:
        > >
        > > I'm trying to keep them down, but not to a minimum. When it really
        > > does describe something different (such as a reference to a list rather
        > > than an object) I'd rather have a different element.
        > >
        >
        > Fair enough.
        >
        > > For instance, at one point I was tempted to just make the classification
        > > objects <list>s -- regardless of what they were listing. Makes it nice,
        > > simple, and consistent. All good things. However, the ability to find
        > > lists of certain things (such as of weapons, or spells, and so on) made
        > > that a poor decision, so I decided not to go that way.
        >
        > Um... wouldn't matching on list[@type='weapon'] be more or less the same
        > as matching on weapon-list? I mean, probably a little more processing
        > needed, but functionally pretty mucht he same, right?

        It would, actually... and the classification and assignment elements are
        meant to be fairly simple, as their only purpose is to allow me to group
        things in multiple ways. Hmm... it might be nice to have only a single
        <list> element; this could simplify many things for me.

        > > I'm still trying to figure out a nice way of doing spell assignments --
        > > getting them into the right list is easy, but specifying the levels in
        > > a useful manner is annoying. The list assignment will work much like
        > > above, and for the same reasons (the assignment is separate from the
        > > reference and classification objects to reduce the impact of adding
        > > new reference or classification objects).

        <bigsnip />

        > I agree with you that Option 2 is pretty ugly, but by combining it with
        > Option 3, you may be able to simplify domains, and those cases where you
        > would have a very few spells in a level. For example:
        >
        > <spell-list id="spell-list.abjuration" />
        > <spell-list id="spell-list.abjuration.1" />
        > <list-entries list-id="spell-list.abjuration.1">
        > <spell-ref refid="spell.shield" level="1"/>
        > </list-entries>
        > <list-entries list-id="spell-list.abjuration">
        > <spell-list id="spell-list.abjuration.1" />
        > <spell-list id="spell-list.abjuration.2" level="2" />
        > <spell-list id="spell-list.abjuration.3" level="3" />
        > <spell-list id="spell-list.abjuration.4" level="4" />
        > <spell-list id="spell-list.abjuration.5" level="5" />
        > <spell-list id="spell-list.abjuration.6" level="6" />
        > <spell-list id="spell-list.abjuration.7" level="7" />
        > <spell-list id="spell-list.abjuration.8" level="8" />
        > <spell-list id="spell-list.abjuration.9" level="9" />
        > </list-entries>
        >
        > Basically, use spell-list-ref and spell-ref and allow you to define the
        > level for either. if you have a defined level for a spell in a list that
        > you're re-defining the level as you make a composite list, then use the
        > spell-list-ref's level instead of the spell-ref's. It's not perfect, but
        > it seems like it might be the best of the available options. Then again,
        > it might leave too much flexibility, at the expense of the ease of
        > processing. Let me know what you think.

        I considered allowing the level to be set in either <spell-list> or in
        <spell-ref>, but I don't like the possible ambiguity that introduces. If
        someone sets <spell-ref level="2"/> and then does <spell-list level="3"/>,
        even though the program may act consistently it could confuse the user.

        The simplest, perhaps, would be to include @level as an attribute of
        <spell-list>, then have the master <spell-list> contain references to
        the internal lists... that would be the most consistent with the other
        classifications. However, given that the level-based sublists really
        *are* sublists of the master list, and can't be used by other lists,
        I think it may be best to declare them as such. That makes it easy
        to identify the top-level <spell-lists>, but still allow assignments
        to them. At this point, I think

        <spell-list id="spell-list.abjuration" name="Abjuration">
        <spell-list id="spell-list.abjuration.0" name="Abjuration 0" level="0" />
        <spell-list id="spell-list.abjuration.1" name="Abjuration 1" level="1" />
        <spell-list id="spell-list.abjuration.2" name="Abjuration 2" level="2" />
        <spell-list id="spell-list.abjuration.3" name="Abjuration 3" level="3" />
        <spell-list id="spell-list.abjuration.4" name="Abjuration 4" level="4" />
        </spell-list>

        may actually be the way to go. I'm not entirely happy about it yet,
        though.


        Keith
        --
        Keith Davies
        kjdavies@...

        Logan: "I don't think it's a good idea."
        Raven: "The vote is three to one against you -- me, the crystal ball,
        and the little voices in your head."
      • giliath01
        ... useful ... Regretably, that transformation will be rather difficult to do because there is no way to identify the type that a particular list applies to.
        Message 3 of 13 , Feb 6, 2002
        • 0 Attachment
          ><weapon-list id="weapon-list.axes" name="Axes">
          > <ref refid="weapon.battleaxe"/>
          > <ref refid="weapon.handaxe"/>
          > <ref refid="weapon.greataxe"/>
          ></weapon-list>
          >
          >and so on. However, this is (theoretically) beyond the scope of this
          >project... it's up to the front-end folks to figure out what they
          >want to do -- we just have to be able to represent the data in a
          useful
          >way. I do expect to make recommendations to them, though.

          Regretably, that transformation will be rather difficult to do
          because there is no way to identify the type that a particular list
          applies to. If you have just a generic list-entries assignment,
          without inspection into the actual data that the reference ids have
          inside the gui group will not be able to determine that the list is a
          <weapon-list>. I am not sure, but I don't think the XSLT
          transformation engines can do that type of manipulation without a lot
          of work.

          Now you could add some outer wrappers to get types of information
          together like this:

          <races>
          <specifications />
          <classifications />
          <assignments />
          </races>

          This would give it a more explicit grouping and make it easier to do
          an XSLT transformation like you described above. If you don't have
          an explicit mapping that allows you to group all of the <list-
          entries> that are races together you have no way of knowing that a
          list contains races without doing inspection into what it contains.

          >I considered something like this once, for another schema. Frankly,
          >it was a pain in the ass to use. <ref> (or <entry>, above) tend to
          >be fairly obvious in context. That it is a reference to a race can
          >be inferred by the ID (<entry refid="race.elf"/>, f'rex) and context.
          >Having to use specifical <*-ref> types got to be annoying, especially
          >when they're all doing the same thing. I could see some small gain
          >in that it describes the data in higher detail, but -- at this
          point --
          >I don't think it's gains enough to be worth the trouble.

          While I understand how it is a pain in the ass to use <ref> entries,
          this approach give a more explicit definition for both the XML editor
          and more importantly for the java developer doing the data loading.
          When creating lists inside the java you want to be able to explicitly
          know that every reference object inside this list is of an
          appropriate type, but there is no typing at all on the lists.

          Both of these suggestions come back to the same problem. If we
          genericize the data too much, it is much more difficult to display a
          list of races. With the assignments you are proposing, without
          hardcoding IDs into the java, how do you identify that a particular
          list is a list of races? what is a list of classes? The java
          developer that is loading this data shouldn't have to do
          validation to make sure that lists contain appropriate groups, that
          should be taken care of in the XML definition.

          ~David
        Your message has been successfully submitted and would be delivered to recipients shortly.