Lists Home |
Date Index |
My only take on naming standards is to keep them simple
and be very cognizant of their scope with respect to the
organizations that might be required to use them. This
is a problem for any meta-specification: no size fits all.
Most of the time, one can make it fit, but sometimes the
language or the constraints are such that one has to
push back and say, no, N/A, nahii, nyet. Odd things pop up:
for example, a naming convention that requires all
acronyms to be expanded. Seems simple enough and
desirable until one sees the rule that says an
acronym is unclassified but the name is classified.
Local rules prevail, but the organization might be
required to sign contracts that are in conflict.
I suspect that is one of the more harrowing problems
of the orchestration languages, as well.
It gets worse if one tries to subset the spec
to make it tighter by removing extensibility options.
No becomes 'no and the horse you rode in on'.
Then there are the naming conventions that force one
to carry waaay more meta-info in the name than is