After a lot of thought and a bunch of playing around with the code and running many tests, I have come to the conclusion that trying to have a prioritized order to the car attributes will not work. The thought was that if we could figure out the right order from most important to least, then we could start to relax the matching specifications by first ignoring the least important one, and so on with increasing importance. This would help to “force” a close-enough match during restaging.
The main problem with this idea is that there is really no intrinsic relative importance to these attributes, so that we could ignore the attributes in a fixed sequence of increasing order of importance. Such an ordering does not exist in general, because what may be safely ignored in one situation might not be the same in another. For example, is the car owner more or less important than its length? I think the correct answer is “it depends…” We may have roles that must have CPR cars because there is a contract to supply them but they don’t care about the length, and we might have other roles that must have a certain car length to fit at a loading dock but don’t care who the owner is. Neither is always more important than the other. A better way is needed to indicate what is optional and what is not.
Here is what I came up with, at least for now. Taking car length as an example, currently the program will accept an input of blank or “*” to indicate “don’t care”, or a list of one or more specific items to indicate that any one of them is acceptable. For example, a role with a length specification of “*” means that any length car is acceptable. A specification of “40|50|60” means that a car length of 40, or 50, or 60 feet is acceptable, but nothing else.
I am proposing to extend this approach and allow for something like 40|50|*, which would mean either 40 or 50 feet to start, but if there is no match, then the length can be relaxed to “Any” for a subsequent attempt. Exactly how this would apply when there are multiple attributes that include an “*” is not clear to me yet, but I’m sure something will emerge. The issue is that if a role has say three attributes that all can be relaxed, which one (or more) do you try first? How many attempts do you try? What order do you relax them in? As a start to implement the basic idea of being able to make some attributes optional, I will just have it be all or nothing. The first pass should match exactly or not, and a second pass will simply ignore all of the “relaxable” attributes. Maybe we should call them “Optional” attributes if they include an “*”?
The end result is that each role can include some specifications that are not optional and must be matched (they don’t include an “*”), and some that are optional and may be ignored in order to keep the cars rolling. I think this should provide enough flexibility, at least for now.