Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 sensible. len
|
