Each transaction listed below has an XSD (stylesheet) associated with it defining the required and optional fields.
mifNew:A completely new component (dataset). This can be a new component within an existing collection, or a new component in a completely new collection.
mifNewInstance: A new instance of an existing component (dataset). This xml stylesheet ONLY contains items that are discontinued, redefined, or brand new.
Required fields: component, collection short name, collection long name, instance
· Only if there is no break in series (the most current instance) the item will continue. That means it is looking for a combination of both continues flag and most current instance.If there is a break in series then it will put a discontinue flag on the item and NOT continue the item to the new instance.
- When going forward this means it puts a discontinue flag on the item’s timeframe and that timeframe does not get the new instance in the periodmap table.
- When going backward (adding before first instance) there is NO discontinue flag, the item gets a different timeframe that does not include the new (earlier) instance in the periodmap table.
Discontinuing an item at beginning of a series effectively changes the “start” date compared to all other items that continued back.
- When going forward this means it puts a discontinue flag on the item’s timeframe and that timeframe does not get the new instance in the periodmap table.
- When going backward (adding before first instance) there is NO discontinue flag, the item gets a different timeframe that does not include the new (earlier) instance in the periodmap table.
mifModify: This makes any and all changes to existing information (dataset and item levels) for the instance specified ONLY. (Note: some dataset level information is not instance-specific.)
Required fields: component, collection short name, collection long name, instance
Optional fields that can be changed (changes apply to all instances):
· SponsorInfo (recommend moving to the instance level in metadata)
· category
· logo (recommend moving to the instance level in the metadata)
These changes apply ONLY to the instance listed.
· extractionHost
· tabulationHost
· restriction
Note: modifying an instance does not make sense because the user can just delete an instance and insert a new one.(We did this because it is hard to figure out changing an instance in the middle of a series.)
Required fields: component, collection short name, collection long name, instance, original item name (variable id attribute)
Optional fields that can be changed:
· name (id)
· label
· concept
· security
· unit
· type
o type
o iterationgroup
o datatype
o decimal
o geographyIndicator
o interval
o isweight
o length
o weightvar
· values (need to define all values for item, not just modified ones)
· longDscr and universe?? – Because the way we store these 2 separate attributes in a single html file, how can a user update only one of the 2 parts? Either we don’t let them update at all, or we make them define both in the update XSD. Or we completely change the way we store them or collect them.CURRENTLY in the mifModify XSD we DO NOT allow a user to update the universe. However, if the user updates the longDscr, they will overwrite any universe info that was contained in the original html file.
· attachment ???
· synonyms????
· Notes????
Just a list of changes/rules (bh FIXME)
***** VARIABLES *****
Stuff not being used in repository if not being updated (embargo)
mifDelete: This deletes an entire component, instance, or individual items. Deletes in a roll up structure format – will delete the parent if no children exist any longer (therefore it can end up deleteing subsurveys and collections.
User defines these things for deletions: collection, subsurvey, component, instance, variable(s) – and based on what parts are defined, the deletions will be as follows:
modifyTime: All changes that are related to time are made through this. E.g.: discontinuing all items, discontinuing/continuing specific items, and redefining items (break in series).NOTE: all references to forward and backward are using a timeline analogy. Forward is moving towards the most recent time, and backward is moving towards the earliest time.
· continue forward last instance– this simply changes the continuesForward flag to Y from N (continuesForward flag is proposed name change for current stopdateflag field in timeframe table)
· continue backward first instance– this simply changes the continuesBackward flag to Y from N (continuesBackward flag is a proposed new field in timeframe table)
· continue from past definition (you want to “pull” the previous period’s definition of an item forward or essentially continue previous variable to a later time)
· continue from future definition (you want to “pull” the next period’sdefinition of an item backward or essentially continue a variable back to an earlier time)
newItemInExisting: This adds new items to components that already exist, e.g. the item was initially missing in the metadata when the component was defined.
Required fields: component, collection short name, collection long name, instance
The items are defined in the exact same way as in the newComponent XSD.
NOTES: Can you add an item to more than one instance at a time or all defined instances? or do you have to add it to one, then use the timeModify to pull it to the other instances?
Redefining an item and updating an item are two completely different things.
Assumptions