The intent of the model is to provide independence of the eventual serialization of XBRL, which for now is XML.  The XSB Strategic Initiatives project has a task to develop an SQL model, which may for a basis for an alternate serialization to be consumed by Arelle.

From the top down, there is the necessity to process multiple instances (DTSes) of XBRL concurrently.  A ModelManager coordinates them for the Controller, and is the interface to utility functions (such as the Python web cache), and application specific formalisms (such as the SEC restrictions on referencable base taxonomies).

Each loaded instance, DTS, testcase, testsuite, or versioning report is represented by an instance of a ModelXbrl object.  The ModelXbrl object has a collection of ModelDocument objects, each representing an XML document (for now, alternate serialization whenever that time comes).  One of the modelDocuments of the ModelXbrl is the entry point (of discovery or of the test suite).

Each modelDocument represents a set of modelObjects, which are specialized as follows according to the type of document.  There is also one specialization of modelDocument, which is a modelVersReport, as the versioning report has different objects and methods than from any other XBRL modelDocument.

There is also an inherently different model, modelRelationshipSet, which represents an individual base or dimensional-relationship set, or a collection of them (such as labels independent of extended link role).

The model objects are, from general to more specific:

• ModelObject.  Represents any of the modelObjects of a modelDocument, which in XML serialization have an associated element, possible id, and various common fields and features.
  • ModelRoleType.  Represents a roleType or arcroleType.
  • ModelSchemaObject.  Common ancestor for modelConcept and modelType.
    • ModelConcept.  Represents concepts (and any other schema element definitions).
    • ModelAttribute.  Represents schema attribute definitions.
    • ModelType.  Represents simple and complex types.
  • ModelLink.  Represents an XLink link, such as extended links in linkbases and links of footnotes in instance documents.
  • ModelResource.  Represents XLink resources, such as labels, references, footnotes, and generic resources.
    • ModelLocator.  A specialized ModelResource having an href which can be dereferenced to obtain the modelObject it represents.
    • ModelFormulaResources (listed separately below)…
  • ModelRelationship.  Represents an XLink arc, regardless of its effectivity in a relationship set.  Includes operations determining equivalence, priorityOver, and identicality with an arc represented by another modelRelationship.
  • ModelFact.  Represents an XBRL instance fact.
    • ModelInlineFact.  Different accessors than superclass modelFact for fields that have different serialization in inline, than in an instance.
  • ModelContext.  Represents an XBRL instance context.
    • ModelDimensionValue.  Represents an explicit or typed dimension value
  • ModelUnit.  Represents an XBRL instance unit.
  • ModelTestcaseVariation.  Represents a variation within a testcase.  (A testcase itself, and test suite, are each a modelDocument.)  Testcase variations are implemented for base spec, dimensions, formula, function registry, and versioning conformance suites.
• ModelRelationshipSet.  Represents a single base set, a collection of base sets (such as ignoring link roles on labels if requested), a dimensional relationship set (spanning target roles and relationship types from primary items), and ineffective relationship sets (required for some validation operations).

The formula model objects extend the above:

• ModelProgram (extends above ModelObject).  Represents a collection of compiled XPath 2 expressions of formula programs or function registry testcase variation calls and tests.
• ModelFormulaResource (extends above ModelResource).  Base type for formula resources.  Aware that resources may contain expressions that need compiling, have ordered dependencies, and have specified relationships.
  • ModelAssertionSet.  Represents assertions related to a single assertion set.
  • ModelVariableSet.
    • ModelFormula.
    • ModelVariableSetAssertion.  Has a test expression.
      • ModelExistenceAssertion.
      • ModelValueAssertion.
• ModelConsistencyAssertion.  Has related ModelFormula objects.
• ModelParameter.  Represents a parameter with optional select expression.  Considered a global variable but may have named relationships to variable sets.
• ModelVariable.
  • ModelFactVariable.  Includes fallbackValue expression.
  • ModelGeneralVariable.  Has select expression.
• ModelPrecondition.
• ModelFilter.  Base type for filters.
  • ModelTestFilter.  Base type for filters with test expressions.
    • ModelEntityIdentifier.
    • ModelGeneral.
    • ModelPeriod.
    • ModelSegmentFilter.
    • ModelScenarioFilter.
    • ModelGeneralMeasures.
  • ModelPatternFilter.  Base type for filters with pattern expressions.
    • ModelEntityRegexpIdentifier.
    • ModelEntityRegexpScheme.
  • ModelAspectCover.  Represents aspect cover filter.
  • ModelBooleanFilter.  Represents boolean filters.
    • ModelAndFilter.
    • ModelOrFilter.
  • ModelConceptName.  May have multiple QName and QNameExpressions (or alternatives for filtering).
  • ModelConceptPeriodType.
  • ModelConceptBalance.
  • ModelConceptFilterWithQnameExpression.  Represents concept filters with single qname expression options (not concept name filter, which has multiple qname expression options, above).
    • ModelConceptCustomAttribute.
    • ModelConceptDataType.
    • ModelConceptSubstitutionGroup.
  • ModelConceptRelation.
  • ModelEntitySpecificIdentifier.  Has scheme and value specifications.
  • ModelEntityScheme.
  • ModelMatchFilter.
  • ModelDateTimeFilter.
    • ModelPeriodStart.
    • ModelPeriodEnd.
    • ModelPeriodInstant.
  • ModelForever.
  • ModelInstantDuration.
  • ModelCustomFunctionImplementation.
  • ModelExplicitDimension.
  • ModelTypedDimension.
  • ModelRelativeFilter.
  • ModelAncestorFilter.
  • ModelParentFilter.
  • ModelLocationFilter.
  • ModelSiblingFilter.
  • ModelSingleMeasure.
  • ModelNilFilter.
  • ModelPrecisionFilter.

Validation operations are separated from the objects that are validated, because the operations are complex, interwoven, and factored quite differently than the objects being validated.  There are these validation modules at present:

• Validate.  If validating a test suite, it sequences all test cases in the suite.  If (and in recursion) validating a test case, it sequences all variations in the test case.  If (and in recursion) validating an XBRL versioning report, it loads the specified fromDTS, toDTS, versioning report, and validates the versioning report.  If (and in recursion) validating an XBRL instance or DTS, it validates XBRL validations, calculation validation if selected, and SEC validation if selected.
• ValidateVersReport.py.  Validates the versioning base, concept basic, and concept extended tests defined in module specs.  (Relationship sets and instance aspects in development.)
• ValidateXbrl.py.  Validates instance, schema, and linkbase documents.  There are some SEC tests in this module where they depended on the infrastructure of XBRL validation.
• ValidateXbrlCalcs.py.  Validates summation-item, essence-alias, and requires-element checks.
• ValidateXbrlDimensions.py.  Validates dimensions linkbase and instance checks, factored to a separate module from the main XBRL validation checks.
• ValidateXbrlDTS.py.  Performs DTS document checks that relate to serialized XML constructs behind the XML.  Includes document and element based checks.
• ValidateFiling.py.  Validates instance, schema, and linkbase documents for Edgar/Global Filer Manual tests that are covered by the disclosure system test suite.  The tests are factored to minimize duplicative passes through the data, not according to the rule set or test suite organization.  The easiest way to find test coding is to search on the rule set identifier.
• ValidateFilingDimensions.py.  Validates disclosure system rules that deal with complex dimensions issues and are factored to be independent of the non-dimensional tests.
• ValidateFilingDTS.py.   Performs DTS document disclosure system rule checks.
• ValidateFilingText.py.  Validates disclosure system rules that deal with the text structure of submission files, text block concepts, and footnote contents.
• ValidateFormula.py.  Validates formula linkbase static checks, compiles XPath expressions, determines interdependencies, and performs formula and assertion set checks (implementation in progress).
• ValidateUtr.py.  Validates fact items usage of units according to the unit type registry.
• XPathParser.py.  Represents the XPath 2 grammar, parses and compiles expression stacks that can be executed.  Grammar parser implemented with PyParsing.   ( ” )
• XPathContext.py.  Represents the XPath execution context, including formula, assertion set, and function registry tests. ( ” )