XMLSchemaDocument
Related Doc:
package dsom
Abbreviation.
Abbreviation. We use this very often.
The enclosing component, and follows back-references from types to their elements, from globalElementDef to elementRefs, from simpleType defs to derived simpletype defs, from global group defs to group refs
The enclosing component, and follows back-references from types to their elements, from globalElementDef to elementRefs, from simpleType defs to derived simpletype defs, from global group defs to group refs
Note: the enclosing component of a global element or global group referenced from a element ref or group ref, is NOT the ref object, but the component that contains the ref object
All schema components except the root have an enclosing element.
All schema components except the root have an enclosing element.
Elements that enclose this.
Elements that enclose this.
If this is already an element, this still walks outward to find the next tier out.
The terms that can enclose this.
The terms that can enclose this.
Even if this is already a term, this walks outward to find those enclosing this.
This is a bit complex.
This is a bit complex. It's folding the list of includes (or imports) and threading the accumulating map of included/imported things we've already seen, and also building up a shorter list of just the local children.
True if this is a DFDL schema that Daffodil should process.
True if this is a DFDL schema that Daffodil should process. False if this schema should be ignored because it has no DFDL annotations.
We will ignore this import/include if it does not use the DFDL namespace definition for a prefix (or the default) on the xs:schema element.
We do this so that other annotation languages can co-exist with DFDL. That is, they can use all of XML Schema including things DFDL doesn't allow like attribute decls, but only when those schemas are only needed to process non-DFDL annotations. Since Daffodil ignores non-DFDL annotations entirely, Daffodil won't run into these non-DFDL allowed things like attribute decls. But validators like Xerces will see the regular import/include and process normally, which enables validation of all annotations, DFDL and otherwise.
Further discussion - see the comments on JIRA ticket DAFFODIL-1909
Whether the component is hidden.
Whether the component is hidden.
Override this in the components that can hide - SequenceGroupRef and ChoiceGroupRef
Annotations can contain expressions, so we need to be able to compile them.
Annotations can contain expressions, so we need to be able to compile them.
We need our own instance so that the expression compiler has this schema component as its context.
Namespace scope for resolving QNames.
Namespace scope for resolving QNames.
We insist that the prefix "xsi" is properly defined for use in xsi:nil attributes, which is how we represent nilled elements when we convert to XML.
Used as factory for the XML Node with the right namespace and prefix etc.
Used as factory for the XML Node with the right namespace and prefix etc.
Given "element" it creates <dfdl:element /> with the namespace definitions based on this schema component's corresponding XSD construct.
Makes sure to inherit the scope so we have all the namespace bindings.
The lexically enclosing schema component
The lexically enclosing schema component
path is used in diagnostic messages and code debug messages; hence, it is very important that it be very dependable.
path is used in diagnostic messages and code debug messages; hence, it is very important that it be very dependable.
All non-terms get runtimeData from this definition.
All non-terms get runtimeData from this definition. All Terms which are elements and model-groups) override this.
The Term class has a generic termRuntimeData => TermRuntimeData function (useful since all Terms share things like having charset encoding) The Element classes all inherit an elementRuntimeData => ElementRuntimeData and the model groups all have modelGroupRuntimeData => ModelGroupRuntimeData.
There is also VariableRuntimeData and SchemaSetRuntimeData.
For include, if the included schema doesn't have a targetNamespace, then we will take on the namespace of whatever we are included into.
For include, if the included schema doesn't have a targetNamespace, then we will take on the namespace of whatever we are included into.
This is the chameleon namespace concept, and it works inductively. I.e., the included schema could include more schemas, all of them ultimately getting the targetNamespace from the schema enclosing that outermost include.
If an included schema DOES have a targetNamespace, it must match what we're included into.
Elements only e.g., /foo/ex:bar
Elements only e.g., /foo/ex:bar
A schema document gets its target namespace from the targetNamespace attribute of the xs:schema root.
A schema document gets its target namespace from the targetNamespace attribute of the xs:schema root.
However, if this schema document is being included in another document, then the target namespace (if none is specified) is of the document into which this is being included. If this schema document DOES have a target namespace, then it must match the target namespace of the schema into which this is being included.
And, if this schema document is being imported, then the target namespace (if found) on the xs:schema of this schema document must match that of the import statement. If a namespace is specified there.
Handles everything about schema documents that has nothing to do with DFDL. Things like namespace, include, import, elementFormDefault etc.