Unifying Policy and Events Specifications #46
Replies: 1 comment
-
|
For 1, user classes from Curbs do combine in some way elements from vehicle, propulsion, and purpose in Events. Right now, all the recommended user classes are at least represented in vehicle, propulsion, and purpose. So if you define a user class in Curb you can capture the same named thing in Events now. Another hitch is user classes are user-definable by definition. Do you think this is good for now or do you have an idea on changes here? For 2, based on what we have defined now with policies in Curbs and activities in Events, how do you propose we align these better? Where it gets tricky for me is in the negative but legitimate policy terms, like "no parking" in item 2 above. Event Types (eg, park_start) seem to align closer to Curb activities (eg, parking). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, the terminology and values used to specify curb policies is different enough from that used to specify events that it is sometimes impossible to assert that an event or sequence of events is compliant with a policy.
We will need to unify the terminology and data types used to define policies and events if we are going to enable compliance assessment in CDS. A few key points of consideration:
vehicle_type). Should events report a user class as well as a vehicle type?parking,no parking), but CDS does not define a means of accessing what each of these activities is. For example, what is the difference betweenloadingandparking? How do we know which applies to a given event/sequence of events?There are likely other points to consider, but this should be enough to start generating some useful discussion.
Beta Was this translation helpful? Give feedback.
All reactions