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

Re: [pcgen-xml] Feat Question

Expand Messages
  • Keith Davies
    ... Same here. I haven t broken down to buy an XSD book because the stuff I ve been doing flies just fine using DTDs. ... A bit of both. This is pretty close
    Message 1 of 15 , Nov 6, 2003
    • 0 Attachment
      On Thu, Nov 06, 2003 at 02:34:16PM +0000, Frugal wrote:
      >
      > <quote who="Keith Davies">
      > > As a general rule, anything 'metalevel' (such as ID and other control
      > > information) should be an attribute. As far as I'm concerned, anything
      > > with a constrained value probably should be as well, though XSD does, if
      > > I understand it, allow constraints on element text (I'm old-fashioned
      > > and still think in terms of DTDs).
      >
      > Cool, I was not aware that Schemas let you constrain on a text element. I
      > really do need to get a decent Schema book, all of my books have DTD and
      > Sax as cutting edge new stuff ;O)

      Same here. I haven't broken down to buy an XSD book because the stuff
      I've been doing flies just fine using DTDs.

      > > <class id='class.fighter'>
      > > <name abbrev='Ftr' legal:isogl='Y' legal:isd20='N'>Fighter</name>
      > > </class>
      > >
      > > <feat id='feat.cleave'>
      > > <name>Cleave</name>
      > > <desc>When you drop one opponent, you can attack another.</desc>
      > > <pre>
      > > <pre stat='str' min='13' />
      > > <pre feat='feat.power-attack' />
      > > </pre>
      > > <description class='benefit'>
      > > <p>When you drop an opponent in melee, you may immediately take
      > > another attack at the same attack bonus against another threatened
      > > opponent.</p>
      > > <p>You may make only one additional attack using Cleave per
      > > iterative attack. Take <ref refid='feat.great-cleave' /> to get
      > > more attacks this way.</p>
      > > </description>
      > > </feat>
      > >
      > > This isn't *exactly* what I have in mind, but fairly close. And I may
      > > have misremembered the rule for number of Cleave attacks per round, let
      > > it slide.
      >
      > Is this syntax off the top of your head, or is this the direction you
      > would like it to go?

      A bit of both. This is pretty close to where I want it to go, and is
      fairly close to something I'm doing for another bit of software I'm
      working on.

      > It looks very different to the current syntax (xml-20030317.zip).

      Ah, so it does. The file you're looking at was automatically converted
      via a Perl script. I just wanted to get something I could open and
      browse (hopefully), quickly, and following the 'each tag has an element'
      guideline. Mostly.

      > Is there an actual schema or DTD in existance ?

      No. There is a set of pages describing (to some extent) the elements
      that have been defined.

      > I spent lunchtime re-writing my SAX hack to load skills and replaced it
      > with a JDOM hack ;O)
      >
      > It will now load a complete set of SRD3.0 skills and they all work
      > (synergy bonuses included).
      >
      > I used a schema based on the xml-20030317.zip details so I had to modify
      > your sample srdskills.xml file a bit to make it validate.

      Yeah, it might not be quite right. It was the work of moments, and it
      shows.

      > I still have a couple of queries regarding <effects>.

      Ask away.


      Keith
      --
      Keith Davies "Your ability to bang your head against
      keith.davies@... reality in the hope that reality will
      crack first is impressive, but futile"
      -- Geoffrey Brent, rec.games.frp.dnd
    • S Woodside
      ... No, disagree! :-) Elements are so much more human readable. They should be preferred over attributes. Attributes should be limited to machine-processing
      Message 2 of 15 , Nov 18, 2003
      • 0 Attachment
        On Thursday, November 6, 2003, at 09:08 AM, Keith Davies wrote:

        > On Thu, Nov 06, 2003 at 10:38:23AM +0000, Frugal wrote:
        >> Like the skills, should the 'stack' and 'mult' tags be boolean
        >> attributes?
        >
        > Probably.
        >
        > As a general rule, anything 'metalevel' (such as ID and other control
        > information) should be an attribute. As far as I'm concerned, anything
        > with a constrained value probably should be as well, though XSD does,
        > if
        > I understand it, allow constraints on element text (I'm old-fashioned
        > and still think in terms of DTDs). Also, anything particularly bound
        > to
        > a single value should be an attribute of the element containing that
        > value. For instance,
        >
        > <class id='class.fighter'>
        > <name abbrev='Ftr' legal:isogl='Y' legal:isd20='N'>Fighter</name>
        > </class>

        No, disagree! :-)

        Elements are so much more human readable. They should be preferred over
        attributes. Attributes should be limited to machine-processing sections
        (such as id="class.fighter"). Constraining elements to certain values
        is easily possible.

        On boolean values ... For boolean values, you can, for example, simply
        key on the presence of the element. For example,

        <class id="class.fighter">
        <name>Fighter</name>
        <abbrev>Ftr</abbrev>
        <legal:isogl>Yes</legal>
        <!-- doesn't matter what the contents are, since the element -->
        <!-- legal:isogl is present and has a content, it's boolean TRUE -->
        </class>

        Since legal:isd20 is NOT present, it's assumed by the processor to be
        false.

        simon

        >
        > <feat id='feat.cleave'>
        > <name>Cleave</name>
        > <desc>When you drop one opponent, you can attack another.</desc>
        > <pre>
        > <pre stat='str' min='13' />
        > <pre feat='feat.power-attack' />
        > </pre>
        > <description class='benefit'>
        > <p>When you drop an opponent in melee, you may immediately take
        > another attack at the same attack bonus against another
        > threatened
        > opponent.</p>
        > <p>You may make only one additional attack using Cleave per
        > iterative attack. Take <ref refid='feat.great-cleave' /> to get
        > more attacks this way.</p>
        > </description>
        > </feat>
        >
        > This isn't *exactly* what I have in mind, but fairly close. And I may
        > have misremembered the rule for number of Cleave attacks per round, let
        > it slide.
        >
        > There are a number of attributes I plan to allow at many levels. For
        > instance, 'isogl' can apply to almost anything. I'll dig up my list.
        >
        >
        > Keith
        > --
        > Keith Davies "Your ability to bang your head against
        > keith.davies@... reality in the hope that reality will
        > crack first is impressive, but futile"
        > -- Geoffrey Brent, rec.games.frp.dnd
        >
        > ------------------------ Yahoo! Groups Sponsor
        > ---------------------~-->
        > Rent DVDs Online - Over 14,500 titles.
        > No Late Fees & Free Shipping.
        > Try Netflix for FREE!
        > http://us.click.yahoo.com/xlw.sC/XP.FAA/3jkFAA/2U_rlB/TM
        > ---------------------------------------------------------------------
        > ~->
        >
        > 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/
        >
        >

        --
        www.simonwoodside.com :: www.openict.net :: www.semacode.org
        99% Devil, 1% Angel
      • S Woodside
        ... Have you considered doing the schema in Relax NG? simon -- www.simonwoodside.com :: www.openict.net :: www.semacode.org 99% Devil, 1% Angel
        Message 3 of 15 , Nov 18, 2003
        • 0 Attachment
          On Thursday, November 6, 2003, at 10:15 AM, Keith Davies wrote:

          >> Cool, I was not aware that Schemas let you constrain on a text
          >> element. I
          >> really do need to get a decent Schema book, all of my books have DTD
          >> and
          >> Sax as cutting edge new stuff ;O)
          >
          > Same here. I haven't broken down to buy an XSD book because the stuff
          > I've been doing flies just fine using DTDs.

          Have you considered doing the schema in Relax NG?

          simon


          --
          www.simonwoodside.com :: www.openict.net :: www.semacode.org
          99% Devil, 1% Angel
        • Keith Davies
          ... Heard of it, seem to recall looking at it briefly, don t remember a thing about how it works To be honest I ve been considering rolling my own so I can
          Message 4 of 15 , Nov 18, 2003
          • 0 Attachment
            On Tue, Nov 18, 2003 at 03:19:56PM -0500, S Woodside wrote:
            >
            > On Thursday, November 6, 2003, at 10:15 AM, Keith Davies wrote:
            >
            > >> Cool, I was not aware that Schemas let you constrain on a text
            > >> element. I
            > >> really do need to get a decent Schema book, all of my books have DTD
            > >> and
            > >> Sax as cutting edge new stuff ;O)
            > >
            > > Same here. I haven't broken down to buy an XSD book because the stuff
            > > I've been doing flies just fine using DTDs.
            >
            > Have you considered doing the schema in Relax NG?

            Heard of it, seem to recall looking at it briefly, don't remember a
            thing about how it works <g>

            To be honest I've been considering rolling my own so I can integrate it
            into the loader more easily -- a definition like

            <meta:entity name='spell' java:class='Spell'>
            <!-- more information, including how to interpret children and what to
            do with them; don't feel like looking it up right now -->
            </meta:entity>

            and a reasonably intelligent loading engine would go a long way to
            increasing flexibility and reducing code maintenance. Once it's
            complete, of course.


            Keith
            --
            Keith Davies "Your ability to bang your head against
            keith.davies@... reality in the hope that reality will
            crack first is impressive, but futile"
            -- Geoffrey Brent, rec.games.frp.dnd
          • Keith Davies
            ... I ve never found them to be, particularly. I ve spent too long doing data processing, perhaps, but having scads of elements means having more to track and
            Message 5 of 15 , Nov 18, 2003
            • 0 Attachment
              On Tue, Nov 18, 2003 at 03:18:37PM -0500, S Woodside wrote:
              >
              > On Thursday, November 6, 2003, at 09:08 AM, Keith Davies wrote:
              >
              > > On Thu, Nov 06, 2003 at 10:38:23AM +0000, Frugal wrote:
              > >> Like the skills, should the 'stack' and 'mult' tags be boolean
              > >> attributes?
              > >
              > > Probably.
              > >
              > > As a general rule, anything 'metalevel' (such as ID and other
              > > control information) should be an attribute. As far as I'm
              > > concerned, anything with a constrained value probably should be as
              > > well, though XSD does, if I understand it, allow constraints on
              > > element text (I'm old-fashioned and still think in terms of DTDs).
              > > Also, anything particularly bound to a single value should be an
              > > attribute of the element containing that value. For instance,
              > >
              > > <class id='class.fighter'>
              > > <name abbrev='Ftr' legal:isogl='Y' legal:isd20='N'>Fighter</name>
              > > </class>
              >
              > No, disagree! :-)
              >
              > Elements are so much more human readable.

              I've never found them to be, particularly. I've spent too long doing
              data processing, perhaps, but having scads of elements means having more
              to track and more relationships to worry about.

              Note that I didn't advocate moving everything to attributes that could
              possibly be made attributes, just certain items.

              > They should be preferred over attributes. Attributes should be
              > limited to machine-processing sections (such as id="class.fighter").
              > Constraining elements to certain values is easily possible.

              Depends on the schema description language. I was brought up on DTDs,
              not this new-fangled stuff <g> While I know that element text can be
              constrained, it's fairly deeply ingrained in me that constraining
              attributes is easier. Especially since I can cut DTDs in my sleep.

              > On boolean values ... For boolean values, you can, for example, simply
              > key on the presence of the element. For example,
              >
              > <class id="class.fighter">
              > <name>Fighter</name>
              > <abbrev>Ftr</abbrev>
              > <legal:isogl>Yes</legal>
              > <!-- doesn't matter what the contents are, since the element -->
              > <!-- legal:isogl is present and has a content, it's boolean TRUE -->
              > </class>
              >
              > Since legal:isd20 is NOT present, it's assumed by the processor to be
              > false.

              This is not entirely unreasonable, but falls down in a couple of places.
              Specifically, the legal stuff isn't limited to just the entity level,
              but the elements describing the entity. That's why my earlier example
              had isogl and isd20 on the <name>, not the <class>. The two can have
              different flags (there are books out there that say 'everything rules
              based is OGL, but all names are not' -- given that they don't qualify
              that with 'proper nouns' or 'personal names' or the like suggests that
              they're willing to share the rules stuff but not the names (which is
              what they said)... or their legal slipped. Either way, there are things
              that we want to associate with child elements.

              Following on that, it is not unlikely that someone will change the
              <name> of an entity (which you will now be able to do without breaking
              things!). The abbreviation of a name is necessarily and intrinsically
              linked to that name, and as such belongs to the same element, hence it
              became an attribute.

              One of my goals is to reduce the number of elements that must be known
              or understood. The following has seven different elements that must be
              known to use it:

              <equipment id='equip.longsword'>
              <physical>
              <weight value='4' unit='pound' />
              <size sizeref='medium' />
              </physical>
              <weaponinfo>
              <damage roll='1d8' critrange='2' critmult='2' />
              <type>Piercing</type>
              </weaponinfo>
              </equipment>

              This has 11 -- 50% more.

              <equipment id='equip.longsword'>
              <physical>
              <weight>
              <value>4</value>
              <unit>pound</unit>
              </weight>
              </physical>
              <weaponinfo>
              <damage>
              <roll>1d8</roll>
              <critrange>2</critrange>
              <critmult>2</critmult>
              </damage>
              <type>Piercing</type>
              </equipment>

              It is inherently more complex to understand and use; a system with 300
              different elements will be harder to learn than 200, especially when you
              get things that are subtly different or unclear.

              In designing this schema, I prefer to have elements be reasonably
              significant chunks, actually meaningful in themselves. Attributes are
              best used for:

              1. meta-level information, used by the program to manage the data
              2. values intrinsically linked to their parent
              3. values that have little meaning on their own and exist only once in
              their parent

              I'm trying to create a simple schema with a reasonably small symbol set
              to learn. Using elements for everything makes that much harder.

              Keith
              --
              Keith Davies "Your ability to bang your head against
              keith.davies@... reality in the hope that reality will
              crack first is impressive, but futile"
              -- Geoffrey Brent, rec.games.frp.dnd
            • S Woodside
              ... It s the bete noire of xml schema languages. Everyone who tries it, loves it :-) But since it came out slightly later than W3C XML schemas, it s not got
              Message 6 of 15 , Nov 18, 2003
              • 0 Attachment
                On Tuesday, November 18, 2003, at 03:41 PM, Keith Davies wrote:

                >> Have you considered doing the schema in Relax NG?
                >
                > Heard of it, seem to recall looking at it briefly, don't remember a
                > thing about how it works <g>

                It's the bete noire of xml schema languages. Everyone who tries it,
                loves it :-) But since it came out slightly later than W3C XML schemas,
                it's not got the support.

                RNG has a MAJOR advantage over WXS that you've already discussed ... it
                supports

                # has unrestricted support for unordered content
                # has unrestricted support for mixed content

                ( http://www.relaxng.org/ )

                do check it out ... it's mucho more human readable and writable.

                I'll try to give take some of the WXS / XSD fragments I see on this
                list and demo an equivalent RNG grammar.

                simon


                --
                www.simonwoodside.com :: www.openict.net :: www.semacode.org
                99% Devil, 1% Angel
              • Keith Davies
                ... Heh. First in the field is always an advantage to these things. ... I don t want mixed content! Whether it s easy to describe or not, it can be a bitch
                Message 7 of 15 , Nov 18, 2003
                • 0 Attachment
                  On Tue, Nov 18, 2003 at 04:17:42PM -0500, S Woodside wrote:
                  >
                  > On Tuesday, November 18, 2003, at 03:41 PM, Keith Davies wrote:
                  >
                  > >> Have you considered doing the schema in Relax NG?
                  > >
                  > > Heard of it, seem to recall looking at it briefly, don't remember a
                  > > thing about how it works <g>
                  >
                  > It's the bete noire of xml schema languages. Everyone who tries it,
                  > loves it :-) But since it came out slightly later than W3C XML
                  > schemas, it's not got the support.

                  Heh. First in the field is always an advantage to these things.

                  > RNG has a MAJOR advantage over WXS that you've already discussed ... it
                  > supports
                  >
                  > # has unrestricted support for unordered content
                  > # has unrestricted support for mixed content

                  I don't want mixed content! Whether it's easy to describe or not, it
                  can be a bitch to process. I'm limiting it to things that can't really
                  avoid it (like text -- as opposed to string values).

                  > ( http://www.relaxng.org/ )
                  >
                  > do check it out ... it's mucho more human readable and writable.
                  >
                  > I'll try to give take some of the WXS / XSD fragments I see on this
                  > list and demo an equivalent RNG grammar.

                  That'd be good to see. I know that XSD is an immensely verbose
                  monstrosity, I've looked at it that much <g>


                  Keith
                  --
                  Keith Davies "Your ability to bang your head against
                  keith.davies@... reality in the hope that reality will
                  crack first is impressive, but futile"
                  -- Geoffrey Brent, rec.games.frp.dnd
                • S Woodside
                  ... I understand better now. Hmm. It could also be Fighter (to avoid having attributes that simply contain Yes ) ... I think to a
                  Message 8 of 15 , Nov 19, 2003
                  • 0 Attachment
                    On Tuesday, November 18, 2003, at 03:57 PM, Keith Davies wrote:

                    >> On boolean values ... For boolean values, you can, for example, simply
                    >> key on the presence of the element. For example,
                    >>
                    >> <class id="class.fighter">
                    >> <name>Fighter</name>
                    >> <abbrev>Ftr</abbrev>
                    >> <legal:isogl>Yes</legal>
                    >> <!-- doesn't matter what the contents are, since the element -->
                    >> <!-- legal:isogl is present and has a content, it's boolean TRUE
                    >> -->
                    >> </class>
                    >>
                    >> Since legal:isd20 is NOT present, it's assumed by the processor to be
                    >> false.
                    >
                    > This is not entirely unreasonable, but falls down in a couple of
                    > places.
                    > Specifically, the legal stuff isn't limited to just the entity level,
                    > but the elements describing the entity. That's why my earlier example
                    > had isogl and isd20 on the <name>, not the <class>. The two can have
                    > different flags (there are books out there that say 'everything rules
                    > based is OGL, but all names are not' -- given that they don't qualify
                    > that with 'proper nouns' or 'personal names' or the like suggests that
                    > they're willing to share the rules stuff but not the names (which is
                    > what they said)... or their legal slipped. Either way, there are
                    > things
                    > that we want to associate with child elements.

                    I understand better now. Hmm. It could also be <name
                    legal="ogl">Fighter</name> (to avoid having attributes that simply
                    contain "Yes")

                    > One of my goals is to reduce the number of elements that must be known
                    > or understood. The following has seven different elements that must be
                    > known to use it:
                    >
                    > <equipment id='equip.longsword'>
                    > <physical>
                    > <weight value='4' unit='pound' />
                    > <size sizeref='medium' />
                    > </physical>
                    > <weaponinfo>
                    > <damage roll='1d8' critrange='2' critmult='2' />
                    > <type>Piercing</type>
                    > </weaponinfo>
                    > </equipment>
                    >
                    > This has 11 -- 50% more.
                    >
                    > <equipment id='equip.longsword'>
                    > <physical>
                    > <weight>
                    > <value>4</value>
                    > <unit>pound</unit>
                    > </weight>
                    > </physical>
                    > <weaponinfo>
                    > <damage>
                    > <roll>1d8</roll>
                    > <critrange>2</critrange>
                    > <critmult>2</critmult>
                    > </damage>
                    > <type>Piercing</type>
                    > </equipment>
                    >
                    > It is inherently more complex to understand and use; a system with 300
                    > different elements will be harder to learn than 200, especially when
                    > you
                    > get things that are subtly different or unclear.

                    I think to a certain extent that's a matter of aesthetics. That said, I
                    think it's very wrong to to empty elements unless absolutely necessary.
                    So I really don't like
                    <damage roll='1d8' critrange='2' critmult='2' />
                    to me a better compromise would be
                    <damage critrange='2' critmult='2'>1d8</damage>

                    Also an empty element with only one attribute really makes no sense?
                    <size sizeref='medium' />
                    vs.
                    <size>medium</size>

                    Also, the first example has 13 "names" to remember (element + attribute
                    names) so by some measure (and I think that's the best measure) the
                    second is actually easier to remember!

                    > In designing this schema, I prefer to have elements be reasonably
                    > significant chunks, actually meaningful in themselves. Attributes are
                    > best used for:
                    >
                    > 1. meta-level information, used by the program to manage the data
                    > 2. values intrinsically linked to their parent

                    ? you mean to the element

                    > 3. values that have little meaning on their own and exist only once in
                    > their parent

                    I think that information that is inherited would perhaps be appropriate
                    as attributes.

                    simon

                    --
                    www.simonwoodside.com :: www.openict.net :: www.semacode.org
                    99% Devil, 1% Angel
                  • S Woodside
                    ... OK :-) But the support for unordered content (all elements though) is very useful IMO) simon ... -- www.simonwoodside.com :: www.openict.net ::
                    Message 9 of 15 , Nov 19, 2003
                    • 0 Attachment
                      On Tuesday, November 18, 2003, at 04:25 PM, Keith Davies wrote:

                      >> RNG has a MAJOR advantage over WXS that you've already discussed ...
                      >> it
                      >> supports
                      >>
                      >> # has unrestricted support for unordered content
                      >> # has unrestricted support for mixed content
                      >
                      > I don't want mixed content! Whether it's easy to describe or not, it
                      > can be a bitch to process. I'm limiting it to things that can't really
                      > avoid it (like text -- as opposed to string values).

                      OK :-) But the support for unordered content (all elements though) is
                      very useful IMO)

                      simon

                      >

                      --
                      www.simonwoodside.com :: www.openict.net :: www.semacode.org
                      99% Devil, 1% Angel
                    • Keith Davies
                      ... Except that there are several legal flags -- OGL, PI, D20 -- and potentially more. ... Oh, it is. I have strong preferences based on my usage over the
                      Message 10 of 15 , Nov 19, 2003
                      • 0 Attachment
                        On Wed, Nov 19, 2003 at 08:35:43PM -0500, S Woodside wrote:
                        >
                        > I understand better now. Hmm. It could also be <name
                        > legal="ogl">Fighter</name> (to avoid having attributes that simply
                        > contain "Yes")

                        Except that there are several legal flags -- OGL, PI, D20 -- and
                        potentially more.

                        > I think to a certain extent that's a matter of aesthetics.

                        Oh, it is. I have strong preferences based on my usage over the last
                        few years.

                        > That said, I think it's very wrong to to empty elements unless
                        > absolutely necessary.

                        To be honest, I prefer them. I find that they're easier to process
                        overall (in code that manipulates the data).

                        > So I really don't like
                        > <damage roll='1d8' critrange='2' critmult='2' />
                        > to me a better compromise would be
                        > <damage critrange='2' critmult='2'>1d8</damage>

                        Gah. I don't see a need for compromise, to be honest. Either way
                        (attribute-based or element-based) is reasonable, mixing them like this
                        is ugly.

                        > Also an empty element with only one attribute really makes no sense?
                        > <size sizeref='medium' />
                        > vs.
                        > <size>medium</size>

                        Given that -- according to DTD at least -- references are enforceable
                        only in attributes, it makes sense to keep them in attributes. I am
                        fully aware that we can institute measures to constrain element text in
                        XSD, but I want the option of extending lists as needed. Schema
                        definition is a meta-level thing, the range of allowable values is
                        generally -- in this setting -- a data issue.

                        In your example above, size may well be tracked using an IDREF attribute
                        in whatever it is you pulled your example from.

                        > Also, the first example has 13 "names" to remember (element + attribute
                        > names) so by some measure (and I think that's the best measure) the
                        > second is actually easier to remember!

                        In a manner of speaking. The way you've proposed means having a larger
                        number of elements. Elements are more complex than attributes because
                        they may contain text, attributes, and other elements.

                        Using attributes, OTOH, lends itself to more cohesive elements -- taking
                        data components that belong together and using them together as I've
                        been doing makes it easier to understand how to represent the thing
                        described by the element.

                        > > In designing this schema, I prefer to have elements be reasonably
                        > > significant chunks, actually meaningful in themselves. Attributes are
                        > > best used for:
                        > >
                        > > 1. meta-level information, used by the program to manage the data
                        > > 2. values intrinsically linked to their parent
                        >
                        > ? you mean to the element

                        To the element to which they belong, yes. When measuring weight, 'unit'
                        has no meaning without the parent element. It may be implemented as an
                        element, but I'm sure other things (such as lengths) would want to use
                        'unit' as well.

                        So, you end up with a single element (admittedly serving the same
                        purpose) having two different sets of allowable values. This may be set
                        up in XSD, but it's a pain to maintain and makes the documentation of
                        <unit> more complex. OTOH, if you have unit as an attribute of <weight>,
                        and as an attribute of <length>, in both cases they have greater meaning
                        in context. The two elements are a little richer and the data in them
                        more cohesive.

                        Now, with those two I could see going to a mixed attribute/value
                        presentation. Especially if the unit has an implicit value. With
                        <weight> the unit will almost always be 'pound' or 'kilogram' depending
                        on the game or game mode, so using the implied unit makes sense.
                        Something like

                        <weight>4</weight>

                        I don't have a particular problem with.

                        > > 3. values that have little meaning on their own and exist only once in
                        > > their parent
                        >
                        > I think that information that is inherited would perhaps be appropriate
                        > as attributes.

                        Such as values tracked in the source namespace, aye.


                        Keith
                        --
                        Keith Davies "Your ability to bang your head against
                        keith.davies@... reality in the hope that reality will
                        crack first is impressive, but futile"
                        -- Geoffrey Brent, rec.games.frp.dnd
                      • Keith Davies
                        ... I don t care much about ordered versus unordered, though I would strongly recommend an ordering convention if the data may be unordered (such as always
                        Message 11 of 15 , Nov 19, 2003
                        • 0 Attachment
                          On Wed, Nov 19, 2003 at 08:36:31PM -0500, S Woodside wrote:
                          >
                          > On Tuesday, November 18, 2003, at 04:25 PM, Keith Davies wrote:
                          >
                          > >> RNG has a MAJOR advantage over WXS that you've already discussed ...
                          > >> it
                          > >> supports
                          > >>
                          > >> # has unrestricted support for unordered content
                          > >> # has unrestricted support for mixed content
                          > >
                          > > I don't want mixed content! Whether it's easy to describe or not, it
                          > > can be a bitch to process. I'm limiting it to things that can't really
                          > > avoid it (like text -- as opposed to string values).
                          >
                          > OK :-) But the support for unordered content (all elements though) is
                          > very useful IMO)

                          I don't care much about ordered versus unordered, though I would
                          strongly recommend an ordering convention if the data may be unordered
                          (such as 'always put the <name> first') if only because if people stick
                          to convention it's much easier to read.


                          Keith
                          --
                          Keith Davies "Your ability to bang your head against
                          keith.davies@... reality in the hope that reality will
                          crack first is impressive, but futile"
                          -- Geoffrey Brent, rec.games.frp.dnd
                        • S Woodside
                          ... Can a single element have multiple legal flags? Hmm... could separate by space, I think they do that in xsl:exclude-result-prefixes ... if it were an
                          Message 12 of 15 , Nov 20, 2003
                          • 0 Attachment
                            On Wednesday, November 19, 2003, at 10:39 PM, Keith Davies wrote:

                            > On Wed, Nov 19, 2003 at 08:35:43PM -0500, S Woodside wrote:
                            >>
                            >> I understand better now. Hmm. It could also be <name
                            >> legal="ogl">Fighter</name> (to avoid having attributes that simply
                            >> contain "Yes")
                            >
                            > Except that there are several legal flags -- OGL, PI, D20 -- and
                            > potentially more.

                            Can a single element have multiple legal flags? Hmm... could separate
                            by space, I think they do that in xsl:exclude-result-prefixes ... if it
                            were an element you could simply allow multiple <legal> elements ;-)
                            (and have them inherit as well)

                            >> So I really don't like
                            >> <damage roll='1d8' critrange='2' critmult='2' />
                            >> to me a better compromise would be
                            >> <damage critrange='2' critmult='2'>1d8</damage>
                            >
                            > Gah. I don't see a need for compromise, to be honest. Either way
                            > (attribute-based or element-based) is reasonable, mixing them like this
                            > is ugly.

                            Looks like you're assuming d20 system right ? (critrange /critmult
                            wouldn't make sense in a different system).

                            Consider: every <damage> element MUST have a dice roll content. Since
                            it's a single required content, then it makes sense to have it be an
                            element value. <damage> elements may optionally have critrange,
                            critmult, but those would have default values (1 and 2 respectively
                            IIRC) so if they were left out, the software would assume defaults.

                            So the distinction between element value and attribute value in this
                            case, is between required and optional data.

                            BTW, in Relax NG you would specify:

                            <element name="damage">
                            <optional>
                            <attribute name="critrange"><text/></attribute>
                            </optional>
                            <optional>
                            <attribute name="critmult"><text/></attribute>
                            </optional>
                            <text/>
                            </element>

                            This would specify that the element contents of damage can only be
                            plain text so no worries about people inserting element contents
                            accidentally.

                            >> Also an empty element with only one attribute really makes no sense?
                            >> <size sizeref='medium' />
                            >> vs.
                            >> <size>medium</size>
                            >
                            > Given that -- according to DTD at least -- references are enforceable
                            > only in attributes, it makes sense to keep them in attributes. I am
                            > fully aware that we can institute measures to constrain element text in
                            > XSD,

                            (and in Relax NG as well, enumerations can be applied to attributes or
                            elements, and by reference, e.g.
                            <size>
                            <ref name="sizeref"/>
                            </size>
                            <define name="sizeref">
                            <choice>
                            <value>small</value>
                            <value>medium</value>
                            <value>large</value>
                            </choice>
                            </define>
                            )

                            > but I want the option of extending lists as needed. Schema
                            > definition is a meta-level thing, the range of allowable values is
                            > generally -- in this setting -- a data issue.

                            I don't understand that part.

                            >> Also, the first example has 13 "names" to remember (element +
                            >> attribute
                            >> names) so by some measure (and I think that's the best measure) the
                            >> second is actually easier to remember!
                            >
                            > In a manner of speaking. The way you've proposed means having a larger
                            > number of elements. Elements are more complex than attributes because
                            > they may contain text, attributes, and other elements.

                            They "may" but you are defining a schema. The schema can specify that
                            any given element may only contain text contents.

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