emblem-symbolic-link

[James Richard Tyrer]

Brian J. Tarricone wrote:
> Extensive "bike-shed"-esque discussions over piddling details aren't 
> particularly conducive to a standards-making process either.

I don't see that as a valid analogy.  The reason is that this isn't a 
small detail.  Yes, this is only a small instance, but what is being 
discussed is one of the major, if not the major, principle of the spec. 
  The spec requires that the tokens separated by "-"s represent 
different levels of specificity.  For some reason, the standard does not 
appear to explicitly state that (LtoR) the first token be the least 
specific and the last token be the most specific.

It also appears clear that the tokens to the left can also provide a 
context for the tokens farther to the right.

That is, if I am using:

	emblem-link-symbolic

and wish to further subdivide this, I would only consider the set of 
symbolic links, not all things symbolic.

We can also read things into the semantic meaning of a token.

That is, although we use the single word "symbolic", I think that it is 
clear that we are referring to *NIX type file links, and if we were to 
make names for more types of icon names for links that this specific 
meaning should be respected.

I thought that everyone understood it to mean that, but there are a few 
names that don't appear to comply with this.  Since these questions 
appear to be differences of kind, it isn't a "piddling detail" as it 
would be if this is a difference of degree.

To make an analogy to the Bike-Shed story.  Consider fire plugs at the 
Power Plant, if we establish that fire plugs are to be painted yellow 
and one is painted green, this is not a piddling issue.  OTOH, if we 
have several shades of red paint (a difference of degree) then it is a 
small issue which isn't worth worrying about unless we have a very 
strict paint color standard (which does exist, BTW, for Federal Safety 
Colors).

We are trying to develop a standard, therefore we need two things:

1.	For the standard to be clear and unambiguous.

2.	To know exactly what the standard means.

Accomplishing these two goals will reduce work in the future.  If we 
adopt an ambiguous standard and people don't agree on what it means, we 
are just asking for problems down the line.

So, with the tokens "symbolic" & "link", we must consider if:

	"link" is a subset of "symbolic"

or if:

	"symbolic" is a subset "link"

I can think of different types of links other than symbolic (a URL is a 
type of link but "link-url" is really redundant unless you want it for 
fall back to the generic "link"), but I do not see any utility in trying 
to divide symbolic up into subsets.

The draft is posted so that people will read it and report errors.  That 
is what I have done.  I apologize for not doing it sooner, but it was 
only when I started to work on actually implementing the standard names 
for KDE-4 that I started to find issues.

-- 
JRT