[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
I have a hard time with the Categories. If I understand the main
argument against "categories are just tags" it is that a publisher
should be able to control what is in a particular category. And I
assume that the reason behind that is an issue of trust - if you find
something in the "Eclipse Platform" category the user trust that it is
supposed to be there.
If the user interface merges Categories that have the same name (even
if they technically are in categories with different ID) - how is that
different than simply tagging things that are supposed to show up
under a category?
Also, there is nothing preventing a publisher to spoof an official
category in their repository (with a higher version number - thus
causing an update of the definition) - thereby making something look
like it is part of someone else's category.
The other point I took away from todays call was that it is important
that the categorization can be performed outside of the immutable IU's.
Maybe there is more to consider that I don't understand, but right now
the construct seems like an elaborate way to set a tag, and that this
mechanism has several issues (my assumptions are):
- Categories need to have unique ID - they are immutable
- existing sites use non unique category names - hence the Category
needs to have a unique UUID of some sort, and the "user defined
category" (i.e. "tools", "optional" etc. that are in common use today)
becomes the name.
- a change of version of the Category means that this category has
been updated - this seems complicated as the UUID needs to be retained
or a new Category will be created.
- The user interface will organize the view based on the Category name
- meaning that it performs a sort of merging of categories based on
the name (i.e. two equally named categories are shown under the same
item).
- It is possible to deliver category names with NLS translation
- Although someone can add additional categorization to IUs, it is not
possible to replace someone else's (unless defining the same item with
a higher version number).
As a result:
- As the UI merges based on the NLS translated label, things there
were intended to be in the same category end up in different groups
I think this can simplified by:
- Category becomes a Categorizer - something that defines tagging/
categorization meta data for other units. Instead of defining a single
category, it defines one or possibly many tags/categories for all of
it's required capabilities.
- The categorizer has an ID that reflects the publisher - i.e.
org.eclipse.xxx.yyy, com.someone.productCatetegories etc. and have a
version.
- A repo/site could be allowed to have several Categorizers
- The tagging/categorization is performed by setting properties -
these property tags are like the "free form categories" currently in
use and consists of two parts per tag; the tag, and the NLS
translatable and human readable name.
- Adding a third part - "tag type" would allow a UI to differentiate
between "category" (as in current use), and "just tags"
- Any feature could define its own tags (without requiring a
Categorizer) by simply setting some tag properties - this would
greatly simplify the publishing for someone who "just has a feature".
- The UI would display "group items" i.e. features and Categorizers
and visually organize them in accordance with the merged set of
category tags.
Thus:
- I can directly categorize a feature (or something else being a group).
- I can categorize without need to change the categorized units
- The Ui can organize categories correctly even if they are translated
Seems a lot more straight forward to me, but maybe I am missing
something important if categorization is done this way.
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
