The most important rule when providing Nodose example document decomposition is to be consistent. Make sure that each instance of a structure has its boundaries defined identically. Most problems result from careless selection of white space (spaces, carriage returns, etc.). The next two screen shots show an example of inconsistently defining the end of a list element. The first element ends before a carriage return by the second element ends after a carriage return. Since there is no consistent way to decide whether or not to include the carriage return in the element, Nodose will usually fail in this case.
Not all of the elements in a list need to be manually added before successful mining can take place. If a list is partially decomposed, however, all of the missing elements must be after the specified ones. For example, if only the first, second, and fourth elements are identified, mining on the list will fail - the third element must also be identified.
When mining a record type, all instances of the type must be either fully specified (all fields identified) or fully unspecified. If some of the records have only some of their fields identified, mining will fail.
After unsuccessful mining, the "Miner Errors" tab in the bottom pane will list the errors that the miner made. Selecting an error will highlight the associated text in the file window. Four different types of errors can be returned from miners: