complexType "Composition"

Namespace:	http://www.ivoa.net/xml/VODML/v1.0
Content:	complex, 1 attribute, 7 elements
Defined:	globally in vo-dml-v1.0.xsd; see XML source
Includes:	definition of 1 element
Used:	at 1 location

XML Representation Summary

<...

xs:string

Content:

vodml-id, name, description?, datatype, multiplicity, subsets?, isOrdered?

</...>

Content Model Elements (7):

All Direct / Indirect Based Elements (1):

Known Usage Locations

As direct type of elements (1):
collection (type Composition)

This type implements a composition relation between the parent and child ObjectTypes. Its instances are ONLY used to set the "collection" field on an ObjectType. It is a rule that an object type can only be the target of a single collection definition. A subclass can be assigned a target to a collection if a baseclass is already assigned such a target, but only if the collection is explicitly 'subsetted'. A collection is assumed to be a set, i.e. a given object (as identified by its identifier!) cannot occur multiple times in the collection. The collection may be ordered, whichi implies that the order in whichi objects have been added to the collection is to be preserved. As clients can always do an explicit sort on any of the child objects' attributes, it seems not necessary to add functionality for declaring a collection is sorted on one or more attributes. Through the uniqueInCollection constraint that can be assigned to attributes, a collection can impose the constraint that different objects in the collection must have distinct values of the attribute to which that constraint is assigned. It would be better probably to add the capability to assign such constraints to this collection type. This would also give more flexibility in for example creating explicit (named) keys, or defining multi-attribute uniqueness constraints.

Type Definition Detail

Type Derivation Tree

ReferableElement (extension)

Role (extension)

Relation (extension)

Composition

XML Source (see within schema source)

<xsd:complexType name="Composition">

<xsd:annotation>

<xsd:documentation>

This type implements a composition relation between the parent and child ObjectTypes.
Its instances are ONLY used to set the "collection" field on an ObjectType.
It is a rule that an object type can only be the target of a single collection definition.
A subclass can be assigned a target to a collection if a
baseclass is already assigned such a target, but only if the collection is explicitly 'subsetted'.
A collection is assumed to be a set, i.e.
a given object (as identified by its identifier!) cannot occur
multiple times in the collection.
The collection
may be ordered, whichi implies that the order in whichi objects have been added
to
the collection is to be preserved. As clients can always do an explicit sort on any of the child objects' attributes,
it seems not necessary to add functionality for
declaring a collection is
sorted on one or more attributes.
Through the uniqueInCollection constraint that can be assigned to attributes, a collection can impose the
constraint that different objects in the collection
must have distinct values of the
attribute to which that constraint is assigned.
It would be better probably to add the capability to assign such constraints to this collection type.
This would
also give more flexibility in for example creating explicit (named) keys, or defining
multi-attribute uniqueness constraints.

</xsd:documentation>

</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="Relation">

<xsd:sequence>

<xsd:element default="false" minOccurs="0" name="isOrdered" type="xsd:boolean">

<xsd:annotation>

<xsd:documentation>

If true, this collection preserves the ordering of object insertions.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

Attribute Detail (all declarations; 1)

Type:	xsd:string
Use:	optional
Defined:	locally within ReferableElement complexType

A referencable element may be given an @id attribute to reflect an identifier defined in some source document form which a VO-DML model may have been derived.

XML Source (see within schema source)

<xsd:attribute name="id" type="xsd:string" use="optional">

<xsd:annotation>

<xsd:documentation>

A referencable element may be given an @id attribute to reflect an identifier
defined in some source document form which a VO-DML model may have been derived.

</xsd:documentation>

</xsd:annotation>

</xsd:attribute>

Content Element Detail (all declarations; 7)

Type:	ElementRef, complex content
Defined:	locally within Role complexType

Reference to the type that plays the role represented by this Role.

XML Source (see within schema source)

<xsd:element name="datatype" type="ElementRef">

<xsd:annotation>

<xsd:documentation>

Reference to the type that plays the role represented by this Role.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

Type:	xsd:string, simple content
Defined:	locally within ReferableElement complexType

Human readable description of the model element.

XML Source (see within schema source)

<xsd:element minOccurs="0" name="description" type="xsd:string">

<xsd:annotation>

<xsd:documentation>

Human readable description of the model element.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

Type:	xsd:boolean, simple content
Default:	"false"
Defined:	locally within (this) Composition complexType

If true, this collection preserves the ordering of object insertions.

XML Source (see within schema source)

<xsd:element default="false" minOccurs="0" name="isOrdered" type="xsd:boolean">

<xsd:annotation>

<xsd:documentation>

If true, this collection preserves the ordering of object insertions.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

Type:	Multiplicity, complex content
Defined:	locally within Role complexType

The multiplicity of the role (also called cardinality) indicates whether it must have a value or may be without value, or possibly how many values are allowed.

XML Source (see within schema source)

<xsd:element name="multiplicity" type="Multiplicity">

<xsd:annotation>

<xsd:documentation>

The multiplicity of the role (also called cardinality) indicates whether it must have a
value or may be without value, or possibly how many values are allowed.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

Type:	VODMLName, simple content
Defined:	locally within ReferableElement complexType

The name of the model element. MUST NOT be an empty string.

XML Source (see within schema source)

<xsd:element minOccurs="1" name="name" type="VODMLName">

<xsd:annotation>

<xsd:documentation>

The name of the model element.
MUST NOT be an empty string.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

Type:	ElementRef, complex content
Defined:	locally within Role complexType

Represents the UML subsetted property. Indicates that a particular relation refines the definition of another relation. ONly a relation inherited form a base class can be subsetted. Typical usage is that the base class has a relation to a class A, and the subclass refines this to indicating that the relation should be to a subclass of A. The value should identify the subsetted property. TBD IF we are going to use utype-s to refer to elements also inside this document, we should use an appropriate keyref

TBD this is a somewhat abstract, but very useful modeling concept. It implements a very common modeling design pattern. It exists in UML2.

XML Source (see within schema source)

<xsd:element minOccurs="0" name="subsets" type="ElementRef">

<xsd:annotation>

<xsd:documentation>

Represents the UML subsetted property. Indicates that a particular relation refines the definition
of another relation. ONly a relation inherited form a base class can
be subsetted. Typical usage is
that the base class has a
relation to a class A, and the subclass refines this to indicating that
the relation should be to a subclass of A.

The value should identify the subsetted property.
TBD IF we are going to use utype-s to refer to elements also inside this
document, we should use an
appropriate keyref

</xsd:documentation>

<xsd:documentation>

TBD this is a somewhat abstract, but very useful modeling concept.
It implements a very common modeling design pattern.
It exists in UML2.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

Type:	VODMLID, simple content
Defined:	locally within ReferableElement complexType

Identifier for its containing element. Extracted as a separate type so that we can easily adapt to a different identifier design.

XML Source (see within schema source)

<xsd:element minOccurs="1" name="vodml-id" type="VODMLID">

<xsd:annotation>

<xsd:documentation>

Identifier for its containing element.
Extracted as a separate type so that we can easily adapt to a different identifier design.

</xsd:documentation>

</xsd:annotation>

</xsd:element>

This XML schema documentation has been generated with DocFlex/XML RE 1.8.0 using DocFlex/XML XSDDoc 2.2.0 template set.

DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML.

DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-end XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future).

A commercial license for "DocFlex/XML XSDDoc" will allow you:

To configure the generated documentation so much as you want. Thanks to our template technology, it was possible to support more than 300 template parameters (working the same as "options" of an ordinary doc-gen), which will give you an unprecedented control over the generated content!
To use certain features disabled in the free mode (such as the full documenting of substitution groups).
To enable/disable documenting of the initial, imported, included and redefined XML schemas selectively.
To document local element components both globally and locally (similar to attributes).
To enable/disable reproducing of namespace prefixes.
To format your annotations with XHTML tags and reproduce that formatting both in HTML and RTF output.
To insert images in your annotations using XHTML <img> tags (supported both in HTML and RTF output).
To use PlainDoc.tpl main template to generate all the XML schema documentation in the form of a single HTML file.
To use the same template to generate the incredible quality RTF documentation.
To document only selected XML schema components specified by name.
To remove this very advertisement text

Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML SDK and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required!

But this is not all. In addition to it, a commercial license for DocFlex/XML SDK will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own!

Please note: By purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the result of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us!

To buy a license, please follow this link: http://www.filigris.com/shop/