On Mon, 2010-09-06 at 16:55 -0500, Martin Holste wrote:
What I'm thinking right now is to create the possibility to create a "tagdb", independently from the patterndb database (although they must play hand-in-hand).
This tagdb would define the tag hierarch (tags in bunches basically) and could perhaps also associate type with the tags.
That would be really nice, but it sounds like a lot of effort will be required on your part. Still, sounds good if you're up for the maintenance.
I'd think that maintaining the set of tags would be needed for patterndb as well. I wouldn't go beyond what is needed there, even though I'd like to make it possible to extend the tag cloud from user-supplied configuration.
<tagdb> <bunch name="security"> <tag type="object" name="flowevt"/> <tag type="action" name="secevt"/> </bunch> <bunch name="storage"> <tag type="object" name="file"/> <tag type="object" name="database"/> </bunch> <tag type="class" name="violation"/> <tag type="class" name="security"/> <tag type="class" name="system"/> <tag type="class" name="unknown"/> <tag name="just-a-simple-tag-without-type"/> </tagdb>
This seems workable, but to me, all that is required is a standard list of classes and tags to use as a guide for contributions. People can pick the most important tag to be the class name, and then just apply the rest as tags. A worthwhile discussion could take place on whether the most general or most specific tag should be used for the class. This format would still comply with the CEE requirements as long as all of the tags needed are present. So, it would look more like:
.classifier.class="security" <tags> <tag>flowevt</tag> <!--object--> <tag>deny</tag> <!--action--> <tag>success</tag> <!--status--> </tags>
Or, you could be explicity with the CEE values: <tag>object.flowevt</tag>
For some reason I rather like type tags, even though it is somewhat more bureaucratic: users/pattern authors should be free to create their tags without limitation.
Opinions?
I agree.
Meanwhile I've talked with Marton (the original author behind tags and patterndb) and his opinion was that the "type" field is difficult to define semantically, and also difficult to handle situations when the same tag would have multiple types, while the original tags/bunches would nicely handle N:M relationships between tags. So at the end of this (in-person) discussion we agreed that we don't need a type field, just a set of predefined "root" bunches. -- Bazsi