Primary Information

Primary information is human input or any information that can not be regenerated automatically and that is taken as source information to produce SecondaryInformation during CodeGeneration or at runtime. -- AlekseyPavlichenko

What about redundant or useless human input? Some badly designed human interfaces (and they are almost all badly designed) require the user to enter the same information in different places, or information that overlaps, or information that's completely unnecessary. As a trivial example, one's state or province can be derived from one's postal code.

If this input is used to produce other information and can not be regenerated from other primary information then it's still primary.

Refactoring removes duplicates from primary information by generating one piece from another piece. For example, if you build a function to calculate state from postal code then state becomes secondary information, postal code remains primary and your function is primary information.

Same logic applies to all other duplicates, they represent primary information until you create a program to duplicate necessary information to follow OnceAndOnlyOnce.

I don't think I've made myself clear. Not every interface is well-factored or ideal and so your definition of primary information is either incomplete or applies only to ideal interfaces. Either way, it's flawed.

I didn't define primary information as ideal. It's not ideal. It may still violate once and only once. If you didn't make program to synchronize db structure with metadata then database structure is still primary. If you created a program to synchronize db structure with metadata both directions then they become different representations and both can be primary at different times when human starts to edit them (see notes about User input into different representations).

Re: If you created a program to synchronize db structure with metadata both directions then they both remain primary.

Surely in this case the database structure and the metadata are both primary and secondary information. (I'm reading this to say that the database structure can be generated from the metadata, and the metadata can be generated from the database structure.) Seems a strange case to consider anyway!

Yes, generating metadata from database structure is less useful, but consider refactoring of existing application when you build metadata based on existing code and database, but this database structure is being maintained by dba who doesn't like to update your meta-data and prefer to update db directly or his own way. Also it may be convenient to update metadata by updating database, just as one of ways to update metadata. --Aleksey

Are we saying that you can have redundancy in primary information and it is still primary. So taking the example of the postal code and the state even though you can derive the state from the postal code they are both primary if they are entered by the user. There are of course valid reasons to want to use redundancy in this way; eg to validate the postal code / state.

But during refactoring (or code generation, or some other kind of transformation) it can be useful to find redundant pieces of primary information and eliminate them. The process of doing this would surely make it before secondary information; eg 'postal code' and 'state' gets transformed to 'validated postal code'.

Yes, human entered redundancy inside primary information doesn't change the fact that it's primary. But if we always validate this redundancy before saving it into database, then only one of 2 redundant pieces is primary and the other piece is secondary. In this particular case, zipcode become primary and state become secondary. If we consider information about state as useful part of zip code, then both zipcode and state are equivalent (keep same information) and any of them can be considered primary (but only one of them, not both). See my note below about user input into different representations.

Interesting that here we found that user data validation and refactoring have something in common. Refactoring is validation of programmer code, validation is refactoring of user entered data.

--Aleksey

I don't know if I'd be comfortable saying 'refactoring is validation of programmer code'. That statement doesn't seem right to me.

I think it's more that refactoring and validation are two means to the same end, ensuring that SecondaryInformation doesn't fall out of sync with PrimaryInformation. In the case of refactoring, the duplication is eliminated, while in the case of validation, it is simply checked. -- jh

User input into different representations

Special interesting logical situation appears when human needs different representations to input PrimaryInformation and at the same time those representations are synchronized by computer. Each representation becomes PrimaryInformation immediately after human modifies it and becomes SecondaryInformation immediately after synchronization. If we think straight then those representations violate OnceAndOnlyOnce and at the same do not violate. To solve this logical problem we can consider only one of those representations as primary and all the rest as secondary until human edit anything, which follows definition of secondary information that any piece of secondary can be deleted at any time, so deletion of other representations will not cause InformationLoss.

When human starts to edit one of representations, it imediately becomes primary and all others secondary. If human starts to edit more than one representation without synchronizing then they both become primary which immediately causes additional violation of OnceAndOnlyOnce of PrimaryInformation if synchronization is impossible or not implemented.

--Aleksey

This doesn't really agree with what I suggesting above. In the example of postcode, state, validated postcode there are three pieces of information there - the first two primary and the last secondary. There's no need for things to suddenly change from primary to secondary depending on what the user does. I think that if you're looking for some kind of universal principle of types of information then you can't allow things to arbitrarily change from primary to secondary.

The information stored doesn't need to correspond exactly to what appears on the UI. So in the case where you have a screen where typing in a postcode will change the state, while typing in a state will change the postcode you could have your primary information as 'last field entered', 'last value entered' and secondary as 'postcode' and 'state'. That way each piece of information has a consistent immutable type.

CodeGeneration produces secondary information based on primary information + secondary information from previous generation stage. Generation stage is a stage from multi stage program execution which takes higher level information and generates lower level information. The highest level is PrimaryInformation. Runtime information represents one of the latest stages in program execution.