1. Todd King

2. The first requirement for the Information Model [IM2008] is: 1. The Information Model shall be developed and maintained independent from any specific technology choices, implementations, or expressions. That is: The IM is implementation neutral.

3.  Early on it was decided that the target implementation was to be XML.  XML Schema was used to express the IM  It was realized that constraining content (by nodes and missions) would lead to a proliferation of XML schema.  In 2012 Schematron was adopted so that content constraints could be expressed as rules.

4.  As with past builds we performed detailed reviews of the IM.  Test Coverage: Approx. 80% of the model (excludes 8 Array classes): Product_Observation, Identification_Area, File_Area_Observational, Table_Binary (Record_Binary, Field_Binary), Table_Character (Record_Character, Field_Character), Table_Delimited (Record_Delimited, Field_Delimited), Group_Field_Binary, Group_Field_Character, Group_Field_Delimited, Time_Coordinates, Investigation_Area, Observing_System, Target_Identification, Mission_Area, Discipline_Area, Internal_Reference, External_Reference, Product_Collection, File_Area_Inventory, Product_Bundle, Bundle_Member_Entry, Context_Area, Reference_List, Product_Browse, File_Area_Browse, Product_Document, Product_Context, Agency, Facility, Instrument_Host, Instrument,Mission, Target, Node, Investigation, Target

5. Be consistent  Apply naming conventions and formation rules across the board. Refactor to Simplest Form  Reducing to common denominators (see Field_*)  Removing elements with single values. (see record_delimiter in Table_Character) Eliminate redundant information by:  Removing counts of things that can be counted (see fields in Record_*)  Bytes in data_type where length in bytes is an attribute. Don't allow the undesirable  Don't accommodate bad practices to make "migration" a literal transform. (see data_type and allowing the changing of byte order field by field) Use technology effectively  What is possible with XML schema + Schematron cannot be done with XML Schema alone. Some principals adopted in the Model where based on XML schema alone.

6. During our build 3b review it was realized that the trifurcation of Table could be addressed with Schematron rules. And that other constraints in the model can be expressed as rules. Simplification and no loss of rigor.

7. From Table_Binary Record_Binary Field_Binary Table_Character Record_Character Field_Character Table_Delimited Record_Delimited Field_Delimited To Table Record Field......... The attribute pds:encoding_type must be equal to on of the following values 'Binary', 'Character', 'Delimited'. The attribute pds:record_delimiter is not necessary when pds:encoding_type is 'Binary'. The attribute pds:field_delimiter is not necessary when pds:encoding_type is ' '. The attribute pds:record_delimiter is required and must be equal one of the following values 'carriage_return_line_feed'. The attribute pds:field_delimiter is required and must be equal to one of the following values 'comma', 'horizontal_tab', 'semicolon', 'vertical_bar'.

8.  Concise It is possible to reduce Table to a much simpler form and eliminate 14 classes in the XML schema.  Consistent Fewer variants can make documentation, training and applications more concise.  Effective It makes the most effective use of the chosen implementation technologies (XML Schema and Schematron).

9.  If applied to the "Array" class  9 classes can be consolidated to 1.  If applied to "File_Area“  13 classes can be consolidated to 1  If applied to the "Product“  31 classes can be consolidated to 1.  And XPath to elements become more uniform. /Product/Identification_Area/logical_identifier

10.  Documents  Makes them shorter and more concise.  Software  External - None.  Internal - harvest, registry.  Schedule  Minimal.  To meet immediate needs it can be done with hand edits on the XML Schema+Schematron, later it can be automated.

11. With so much time, effort and resources invested the IM should be self-consistent, concise, and optimized. We want the IM model to be:  Impressive  The wow factor.  Community impression is important.  An improvement  XML is good, but not enough.  Model should be a refinement.  Innovative  Do something to shift the paradigm.  XML Schema + Schematron is new!

12.  The simplification is an editorial pass  Like a page limit in a proposal.  Can you say the same thing with fewer words?  Are you using a minimal set of terms?  We’re about 80% there.  Some areas of the IM are ideal. i.e., Product_Context is very well formed.  Others still need work.  Focus on the deliverables  XML Schema and Schematron is what will be used.  The IM spec is an internal document.