Date
Participants
Slides
Notes
Ongoing discussions
RK: Component discovery Gaps issue 23. For extension points within the schema. By adding them, other tools would accept them (and ignore). Please take a look. Can start adding extensions to the documentation and classify them.
EF: In Joachim’s request for issue 23, asking Maxim to draft a schema, what are you looking for?
JK: Way to identify a component and need flexibility in classifying. Have a keyword pair. Wanted to try to to “play through” one classification that would meet ST’s needs. Want to agree something - a predefined classification scheme, not free form text.
EF: We can have a deeper look and come back with feedback. Are we all aligned on the principle.
RK: Think it needs some more discussion.
EF: Interesting to have a way to split between identification and classification. One of the advantages of keyword proposal then we end up with something that’s easily backwards-compatible and can help processing by tools.
JK: Don’t necessarily have a clean hierarchy of classes.
RK: Classification - is a “USB driver” a “driver”?
MD: If you want to classify - have several information that we need to store at the same level. If we add a keyword list can all agree on.
RK: Question is how we extend it over time.
JK: Benefit I see is could look for components with keyword “USB” but don’t need to look through hierarchy. Happy to remove all reference to features and call it keywords.
DJ: Think this is related to “taxonomic rank shift” discussed previously - standard ranks. Up to us to choose appropriate number of levels. Could create another level to discriminate between stack, middlewares, drivers etc (see Taxonomic Rank page on Wikipedia)
EF: Identification is attached to existing taxonomy. It’s two different things.
DJ: Retain existing CMSIS taxonomy for identification and add a new taxonomy for classification?
EF: Yes. Means they can evolve separately.
DJ: