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:
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.
@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?
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.
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.
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?
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. <