class XMLSchemaComplexType represents the definition of the type for an element – that is, the structure of a set of elements with the same name. If an XMLSchemaElement is analogous to a utility::tag::Tag, an XMLSchemaComplexType is analogous to the wiki page describing the valid format for an instance of that Tag. More...

#include <XMLSchemaGeneration.hh>

Inheritance diagram for utility::tag::XMLSchemaComplexType:

[legend]

Public Member Functions
	XMLSchemaComplexType ()

XMLSchemaComplexType &	name (std::string const &setting)

XMLSchemaComplexType &	description (std::string const &setting)

XMLSchemaComplexType &	set_model_group (XMLSchemaModelGroupCOP model_group)

XMLSchemaComplexType &	add_attribute (XMLSchemaAttribute attribute)

XMLSchemaComplexType &	add_attributes (AttributeList const &attributes)

std::string const &	element_name () const override

void	write_definition (int indentation, std::ostream &os) const override

void	prepare_for_output (XMLSchemaDefinition &xsd) const override

Public Member Functions inherited from utility::pointer::ReferenceCount
	ReferenceCount ()
	Default constructor. More...

virtual	~ReferenceCount ()

Private Attributes
std::string	name_

std::string	desc_

XMLSchemaModelGroupCOP	model_group_

std::list< XMLSchemaAttribute >	attributes_

Additional Inherited Members
Public Types inherited from utility::pointer::ReferenceCount
typedef platform::Size	Size

typedef platform::Size	size_type

Detailed Description

class XMLSchemaComplexType represents the definition of the type for an element – that is, the structure of a set of elements with the same name. If an XMLSchemaElement is analogous to a utility::tag::Tag, an XMLSchemaComplexType is analogous to the wiki page describing the valid format for an instance of that Tag.

XMLSchemaComplexTypes can be named or unnamed: if they are named, then the are inserted into the XMLSchemaDefinition on their own, and can be referred to by name in other XMLSchemaElements; if they are unnamed, then they are given as an in-line definition for an XMLSchemaElement. So a name is not required for an XMLSchemaComplexType. That said: the recommended structure for defining an XML Schema is that complex types should be named and to live on their own – elements should refer to these complex types by name.

(There are some who recommend that instead elements be defined at "global scope" – i.e. directly beneath the xs:schema tag – and that complex types be unnamed. The principle disadvantage of that idea is that you cannot have two elements in different contexts with the same name but different structures. This problem of "name collisions" is addressed in XML Schema through the use of "namespacing," which is horrendous, so we won't use it. By giving complex types names, we can avoid name collision by just giving the complex types different names, which has no effect on the apperance of the XML file itself.)

Complex types must be one of the five options in the XMLSchemaComplexTypeType. They are either:

empty (xsctt_empty) meaning that they do not contain any sub-elements, though they may contain attributes. Most of the complex types in Rosetta will be declared as empty.
sequence (xsctt_sequence) meaning that they may contain attributes, and that they expect every one of the listed sub-elements to appear inside of them in the order defined.
all (xsctt_all) meaning that they may contain attributes, and that they expect every one of the listed sub-elements to appear inside of them, but that these sub-elements may appear in any order
choice (xsctt_choice) meaning that they may contain attributes, and that they expect exactly one of the listed sub-elements to appear, or
group (xsctt_group) in which case, attributes are not allowed, and a list of subelements are given. The group category is perhaps the most confusing: a complex type with a group type will contain a sub-complex-type with either a sequence, all, or choice designation. A group can be written out by name, and then referred to within one or more complex types. Interestingly, the way to define flexible, recursive data types is to use a group. For example, if the ParsedProtocolMover type can contain any mover, including a ParsedProtocolMover, then to represent this in XML schema requires defining a group for all movers – and then saying that instances of this group can appear within the ParsedProtocolMoverType. Similarly, residue selectors can contain other residue selectors. Look at ResidueSelectorFactory::define_residue_selector_xml_schema for an example of how a group is defined.

A complex type may refer to a reference type, and then extend that type, e.g. by adding extra attributes.

In the case of a "group" complex type, the complex type needs to contain a subtype. E.g. the group complex-type defined by ResidueSelectorFactory holds a choice complex-type.

Complex types may contain subelements; these subelements can be added through a model group (e.g. "xs:all") that itself contains elements and possibly other model groups.

Complex types may contain attributes; these attributes can be added through the add_attribute method.

Complex types may be repeated, e.g., in the sequence or group cases. You may specify the minimum and maximum number of times the complex type is to appaer.