In HeaderInformation Class urgency attribute refers to "information deliver " not to information about a Situation.
Definition: "This indicates the urgency with which a message recipient or Client should distribute the enclosed information. Urgency particularly relates to functions within RDS-TMC applications. "
Based on separation of concerns, D2 model would have to deal with description of a situation itself, while application based information as "deliver to any media" should be kept aside in a well separated package in order to be able to identify and understand information attributes that describe a situation record, from meta-information that is needed to manage the situation information for some functional aspects ( those could be managed as well by rules assuming such information based on other attributes as number and type of vehicle involved etc).
This kind of attributes in DATEX2 are difficult to be managed as they could be implicitely known by the situation records information (e.g. factual information attributes as number and type of vehicle involved in accident, snow deep on road etc ) but then they are also exchanged via these meta-attributes that imply some functional managements that are not explicitely agreed and generally understood and are valid only within some application specific environment among stakeholders.
As DATEX model implemented a separation of concerns for exchange attributes, I assume in future it should consider to separate intrinsically relevant information that describe a situation from application specific information that are optionally managed based on application functionality definition agreement.
same concerns apply other attributes within D2 model Classes as
confidentiality, areaOfInterest in HeaderInformation Class
overallSeverity in Situation
confidentiality, severity in SituationRecord
this separation is to best identify information appliable to situation and information that is exchanged for specific application management for which management rules are to be agreed and are not fully shared and defined by the attributes value, so the behaviour of systems with the same values of attributes can be very different for different implementation.
#1
#2
This request sounds very reasonable and should be considered by the DATEX committees. In any case, it will have impact on backwards compatibility and cannot be addressed prior to v3.0.
#3
Decision make mandatory elements in header optional.
Fabrizio makes proposal to enhance the Header.
#5
request to manage as optional the attribute confidentiality in HeaderInformation Class
internalUse
noRestriction
restrictedToAuthorities
restrictedToAuthoritiesAndTrafficOperators
seem conformant to confidentiality definition use
other literal as
restrictedToAuthoritiesTrafficOperatorsAndPublishers
restrictedToAuthoritiesTrafficOperatorsAndVms
seem to be introduced to cope with information delivery services via Broadcast or VMS and this seem better to be managed by a new attribute
allowedDeliveryChannel
definition: Information Services Channels to which the information could be delivered
Multeplicity: 0..n
vmsOrSigns : all kind of Variable Message Signs, such as VMS or Lane Control System signs.
publicBroadcast : all kind of public broadcast services via radio or web, including digital channels as RDS TMC and TPEG
the last usage will also be compatible with the future Service Request, dealing with allowance of information to be delivered, this information will be then processed to be delivered on Specific Processing Agreement with the Service Provider or Road Operator owning devices.
#6
The decision from Stockholm January was revisited after new arguments were put forward. The updated conclusion of the TG in a call on 3/12/15 was to remove the attributes areaOfInterest and urgency from the HeaderInformation, and to keep the remaining 2 attributes mandatory.
Changes made in model.