Some Techniques

Some techniques

When you specify the structure in Solid, that does not get passed on to the FLEx import process, so you can do some "tricks" to help you validate the structure of the file. Here are some examples.

• In general, try to make your settings as restrictive as possible, so you can discover more about the database:

  • If you start by saying something can occur "Once", then any time it occurs twice it will be flagged. It may be an error, or it may mean you need to change the setting. But you can quickly find all those occurrences and inspect them.

  • If you start by saying "One or more times together", then it will flag any time something else comes between these elements. You can see if it is an error to fix, or a reality that needs to be reflected in the settings.

  • If you say that a marker "Must occur" under something else, you will find the places it wasn't included. Maybe it is okay to omit it sometimes, but it is useful to see how many of those cases there are before you allow it.

  • It is more restrictive to "report error" than "infer [a marker]" when no parent is found. You may want to start with "report error", and once you have learned enough, then switch to "infer [marker]".

• Just because MDF says that all examples should start with \rf, that doesn't mean \rf has to be there. If your database does not have any \rf fields, then change \xv to have \sn as its parent, rather than an inferred \rf.

• When there is a pair of fields that usually occur together and in the same order, sometimes I will make the second one a child of the first, just so that if they ever do not occur as a pair or in that order, it will be flagged, and I can investigate whether there is some other problem. Just because you tell Solid the second one is a child, that does not mean FLEx will interpret it that way, so this can be a useful trick.

It can be especially helpful if you are not sure where in the hierarchy the cluster comes: if you make the subsequent fields children of the first one, then you only need to change the first one if you are experimenting with where it goes in the hierarchy.

Examples:

• • If you have normalized the \ps and have both \ps and \ps_orig, you can make the second one a child of the other, and you might even make the child be required ("Must occur") to discover if it was inadvertently omitted somewhere..

  • I usually make xe and xn children of xv.

  • If you have ge and gn, and they always occur in that order, you can make gn a child of ge (same for de/dn, re/rn, and any other fields with both WSs).