|
|
|
MEG0038 Structure of the Reference Model
.04
04/24/2009
Purpose
1. Introduction
Traditionally within MISMO, data managed before loan closing and data managed after loan closing have been viewed very differently. There are different data points, different terminology, different processes and different delivery methods (which require different structures for efficiency). Organizations looking to implement Version 2.x standards that fall on both sides of the closing event (e.g. Flood Request and Servicing Transfer), were faced with certain inconsistencies (that were necessary at the time) that prevented much reuse.
In Version 3.0, MISMO has developed a single model that supports transactions on both sides of the closing event. The model ensures consistency in structure and allows for maximum reuse within organizations. In order to support both sides of the transaction, there are certain rules that need to be followed when constructing the model.
1.4 Audience
1.5 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 . See «add reference to MISMO glossary for terminology used in this MEG».
1.6 Document Status
The information supplied in this document reflects the MISMO interoperability principles at the time of writing. It is a living document, which will be updated as required to reflect the evolving nature of XML technologies and service requirements identified by MISO constituency. Comments on this document should be sent to the MISMO designated contact identified in the document preface. MISMO does not accept any liability for the accuracy, adequacy or completeness of the information contained in these Guidelines.
2. Rationale for this MEG
Provide guidance on the XML format required for the MISMO data standards.
Content
Guidelines
| Ref |
Guideline |
| 38.1 |
Containers that have a maximum cardinality greater than one SHOULD have a parent container that is named the plural version of itself. For example, a deal MAY have multiple LOAN containers causing the maximum cardinality of LOAN to be “many”. Therefore, the parent of LOAN is LOANS (its plural). |
| 38.1.1 |
When the instances of a recurring container need to be grouped into separate sets, then the recurring container SHOULD have a parent container whose name is the name of the recurring container, plus the suffix “_SET”. For example, a MESSAGE may have multiple, separate sets of documents. Therefore, the parent of DOCUMENT SHOULD be DOCUMENT_SET, which in turn (based on 38.1) SHOULD have a parent named DOCUMENT_SETS. |
| 38.1.2 |
As you approach closing, events occur that narrow down the numbers of types of loan until finally you start dealing with one loan only. After the closing event, even though information is used to refer to just one loan (the one that closed), not multiple “potential” loans, in order to maintain the consistency of XPATHs, you MUST keep the plural LOANS container (even though it is redundant). It is understood that after closing you are only ever dealing with one loan. |
| 38.2 |
Plural containers MAY contain SUMMARY containers to capture summary level data regarding the multiple children containers. For example, the LOANS_SUMMARY container could have the field TotalLTVRatioPercent which represents the combined LTV of all loans represented in specific LOAN child containers. |
| 38.3 |
Relationships SHOULD NOT be established at the plural container level. |
| 38.4 |
For transactions that occur after closing (e.g. Servicing) the PARTIES container MAY be replicated at the MESSAGE level as a sibling of DEAL, DEALS, BUNDLE or BUNDLES. This is intended to prevent repeating information (redundancy). |
| 38.4.1 |
For the PARTIES container under MESSAGE (sibling of DEAL or other structures) there SHALL be limited parties that can be included as children. For example LENDER and MI_COMPANY would be candidates to occur under that PARTIES container while BORROWER would NOT be. |
| 38.4.2 |
Relationships SHALL be established between the PARTIES structure and the appropriate data within each of the individual DEAL pieces. |
| 38.4.3 |
The PARTIES container will still exist under DEAL to manage the necessary DEAL-level information (e.g. BORROWER). PARTIES will exist in two places. |
| 38.5 |
MISMO‘s model SHALL NOT allow recursive relationships. Therefore a parent container cannot also exists as a child of its child. |
| 38.6 |
MESSAGE MUST be the root of the MISMO messages. For example when using SOAP messages, MESSAGE will be the single child of <soap:body>. |
| 38.6.1 |
The MESSAGE will manage the following types of information: |
| 38.6.1.1 |
DOCUMENT – the representation of a paper or electronic document, with its metadata (information about the document), signatures, and, optionally, the data used to populate the document. |
| 38.6.1.2 |
DATA – Data describing a concept from the everyday business terminology and vocabulary of the end-users, like a LOAN, an ASSET, a BORROWER, a CREDIT REPORT. |
| 38.7 |
A term MAY appear in more than one location within the Reference Model. |
| 38.7.1 |
Any term that appears in SERVICES under a Service Request MAY be repeated in the corresponding Service Response. Example: For ease of use the business may need to echo back the Service Request terms in a Service Response. It may also be necessary to have the same terms that occurred in either the Request or Response in a place outside of SERVICES, for example under LOAN, to facilitate ease of use for underwriting and other functions. |
| 38.7.2 |
The XPATH location in the Service Response SHOULD be unique from the XPATH of the Service Request so that there is no risk that the response instance data is confused with the request data. |
| 38.7.3 |
A Service Response including information on parties, loans and properties MUST include the plural containers as children of their response (e.g. PARTIES, LOANS and PROPERTIES). |
Below is an example of the plural containers under the DEAL structure:
Metadata
Version .04
04/25/2008
| Metadata |
| Element |
Description |
| Title |
MEG0038 Single Reference Model |
| Identifier |
MEG0038 |
| Category |
Foundation |
| Publisher |
MISMO |
| Rights |
Copyright of MISMO. All rights reserved. |
| Date Created |
04/02/2008 12:02:00 PM |
| Date Modified |
04/24/2008 2:55:00 AM |
| Release History |
| Date |
Release |
Comments |
| 04/02/2008 |
.01 |
Initial Version |
| 04/06/2008 |
.02 |
Expanded rules with examples |
| 04/14/2008 |
.03 |
Updated per the 5/8 CDS call. Clarification on plural rules. |
| 04/24/2008 |
.04 |
Updated during D3 call |
| Changes Since Last Version |
|
| Contacts |
| Name |
Organization |
Contact Details |
| MISMO Staff |
MISMO |
info@mismo.org |
References
Comments
None.
Disclaimer
Circulation Material in this guideline may be reproduced free of charge without requiring specific permission provided that the source is acknowledged, the document title given and the material is used in context.
Copyright All material in these MISMO Engineering Guidelines are the copyright of the MISMO. All rights are reserved.
|
Last modified at 8/13/2010 11:03 AM by MERSEXTERNALAD\administrator
|
|
|
|