ITS Standards

[DC Kelley]

Here is another one of the long winded paper on what the issues are relating to "lock" a table record to prevent its mis-use by others.

I had a lot of trouble drafting this out because frankly the different SDOs want to go different directions on this. What we can do today is make it easy to tell if a given records is "pure" and untainted with (which some call an authoritative record).

This goes a long way to making it possible to know you are using the records that you think you are. But is does almost nothing to prevent or control the free distribution of SDO records. In this paper I propose a general technical approach to locking the records that should leave open the door to controlling access some other way (if ever needed). If anyone has a better suggestion on how to handle this requirement area, please let me know.

This document was sent to the SDOs for feedback comments as part of the current critical improvements phase of work.

[DC Kelley]

As of release 401 and beyond records locking is now present in the tool.

As of release 409 a "master table lock" button allow locking each record in a table. This provides a one-press way to release a table to others.

I am still having mental reservations about who should be able to lock what records and when but right now the plan is as follows:

Any user has control over the "local" table (where deployments) are expected to add any control they need, as well as the user named tables. For better or worse this can be locked by all.

The Data Elements, Date Frames., Messages and Dialogs tables can only be locked by the designated stewards for that FADD. Other can use, trade, merge and edit these records as they wish but any change would void the lock and it would not longer be displayed as an authoritative record from that FADD/SDO source.

No one can lock records in the External table, this is supposed to be a catch-all for other peoples records. If you merge in one of the newly locked records, it will remain locked. Today you probably have a bunch of older unlocked records from the different standards that you use in your work. These continue as is until you chose to replace them. In time, it is presumed that you can fill you table with authoritative records from the other standards you want to use and by looking at the lock will know that they remain unchanged.

I should stress again that "locked" only means that the CRC values computed for that entry still match. You can always edit a locked record, the locking does not prevent this in any way. Ideally you do not need to edit other peoples records, but there are times (such as needing to add a usage remark) that this will still occur.

You can see that we are getting close to being able to make a web service call for a given record and check with a central repository if that records has a newer copy issued. This in an unfunded dream/hope at this point, but I have been devising the system to allow for it.

[DC Kelley]

As of release 410 and beyond. you can lock away to your hearts content.

The record is locked with the current user name and organization as the steward (hence locking party). This may be different then the person listed as the last change submitter. If you were editing it and then locked it, you will appear as both.

To lock a record you must also have the right to do so. At this time the rights are fairly simple. At a high level each user has a basic type class, either user or steward. All types of users can lock local tables and odd-ball named tables. Only stewards can lock Data Elements, Data Frames, Messages, Dialogs, DEs, and MSGs tables. No one can lock things in the ExternalDEs tables (these should come to you locked from other parties). In an ideal world a stewards lock a table entry (or all entries in a table) and then posts the result or gives it to others (stewards or users) who use it as is.

The locking simply indicates if that part of the record has changed since locked, it does not prevent further editing which will automatically unlock things. The lock is a CRC value computed over the collection of fields for each lock type. The locks are divided into four types as follows.

The Descriptive text (usage, remarks, formula, and harmonization notes)

The ASN Code parts

The XML Code Parts

The meta-data (tons of small values as well as the time stamps)

When a record is locked the then current revision for that files (00-00-00 etc) is applied to it, it is important to make certain your revision value is correct before locking. [You can set the rev values in either the Misc-text edition window or in the XML Export window]

If it also suggested you start to name your db files with the the name of the revision such as ATIS-03-00-74.its etc. Local deployment may want to adopt a short FADD like name ad well to keep data concepts in it. For example AzDOT-00-00-00 might be the initial name of a project which gathered DMS control data up and has in it records various (locked) records from TMDD, C2C, NTCIP, and ATIS. In such as framework, most of the locally developed materials would be in the local table, and most of the other records would be locked copies (indicating that they were unchanged from the standard that they came from).