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

Re: XML Design Guidelines

Expand Messages
  • 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 1 of 13 , Feb 6, 2002
      ><weapon-list id="weapon-list.axes" name="Axes">
      > <ref refid="weapon.battleaxe"/>
      > <ref refid="weapon.handaxe"/>
      > <ref refid="weapon.greataxe"/>
      >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
      >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:

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

      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.

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