Should we keep Category Sections in Attribute Resource Files?

Simulation Modeling Toolkit (SMTK) Design
1

When I designed the original attribute XML file format, I wanted to provide the template designer the ability to define information categories for filtering and then use those categories to define analyses. Below is an example:

  <Categories Default="Mechanics">
    <Cat>Time</Cat>
    <Cat>Mechanics</Cat>
  </Categories>
  <Analyses>
    <Analysis Type="Solid Mechanics">
      <Cat>Mechanics</Cat>
      <Cat>Time</Cat>
    </Analysis>
  </Analyses>

In addition, after the file is read in, the reader would compare the list of categories defined in the categories section with all of the categories defined in attribute resource. If the attribute resource contained additional categories, the reader would report an error.

Since the first version of the attribute file, I had added the ability to reuse existing attribute files via the Includes Section. Though this has been a great feature, it did have an unexpected side-effect w/r to the Categories Section. When including a file with a Categories section, if the consuming file needed to add Categories, it would first need to duplicate the Categories Section of all previously included files. This can result in errors due to potential typos.

I was wondering if we should remove the Category Section from the next version (Version 3) of the attribute resource file. The Default Category could then be moved to the resource’s root node. The new check would be to compare the categories assigned to the different Analyses and if any were not being used by the attribute resource, those missing categories would be reported as warning.

Any comments?

Summary

This text will be hidden

2

@tj.corona @johnt @dcthomp It seems that default notification settings would not send you an email about a new topic. I changed it from Normal to Watching hoping to fix the problem. I guess you guys do not see a notification about Bob’s post as well?

3

Since Solid Mechanics is a subset of Mechanics, may I ask why it needs to duplicate the Mechanics and Time again? Shouldn’t SMTK automatically populate these two entries?

4

If you are referring to the Analyses section where Solid Mechanics is being defined - Time and Mechanics Categories are not being duplicated - it is saying that a Solid Mechanics Analysis uses information belonging to either the Time or Mechanics categories.

5

I was wondering if we should remove the Category Section from the next version (Version 3) of the attribute resource file.

Sure. Will there be another filtering mechanism to replace categories? Or are you suggesting that categories will hereafter be scoped to analyses and not resources?

6

Thats sort of the issue - In the currently categories are assigned to attribute items independently of the Categories Section. So an item can be assigned category “foo” without “foo” being specified in the Category section - in that case you would get an error. However, if you omitted the Category section all together you would get no such error. So actually the section is already sort of optional.

7

I’m good with making <Categories> optional, but I’m not sure I’m ready to drop the section completely.

I use the <Category> section as a reference, which I can copy & paste from into other parts of the template. But I guess I could list the categories in an xml comment…

8

If its in an XML comment then it would not be retained during I/O so using comments probably won’t work. We could keep the section optionally (which is today). What about validation ? Should we still report errors if categories are missing and/or add the new check that would warn you that an Analysis is referring to categories that are not associated with any item/attribute?

9

FWIW – Regarding the comments not being retained by I/O, that doesn’t apply to my current use case, which is authoring template files manually. If/when we migrate to a template editor app, I would lobby for that to present a list of categories, rendering the point moot.

In terms of validation – My use case might be too narrow, but I would be interested in knowing about any categories applied to items that aren’t in the <Categories> section. But I would not make this a fatal error, just a warning.

Side note: I have to use xml entity syntax to get the brackets to display correctly in discourse, e.g. &lt;

10

When I was referring to I/O - I was think specifically if you wanted to update a template from V2 to V3 - in that case the Categories would have disappeared if you were using a comment.

In terms of validation I can have it report both set of issues.