Schema cgxml.xsd


schema location:  C:\pbecker\projects\cgxml\specs\cgxml.xsd
 
Elements  Complex types 
graph  concept 
module  graphType 
relation 


element graph
diagram
type graphType
children parameter concept relation
attributes
Name  Type  Use  Default  Fixed  
id  xsd:string  optional      
annotation
documentation 
"graph" is modelled as element so it can be used as starting element
source 
<xsd:element name="graph" type="graphType">
  <xsd:annotation>
    <xsd:documentation>"graph" is modelled as element so it can be used as starting element</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element module
diagram
children typeHierarchy relationHierarchy catalogOfIndividiuals outermostContext
annotation
documentation 
"context" is not yet explicitely modelled, therefore we use concepts in here. The concept types are not yet enforced either. Maybe using additional tools like XSLT (Schematron?) to check this constraint is easier. No keyrings are yet set up, XML Schema allows to define distinct sets of identifiers.
source 
<xsd:element name="module">
  <xsd:annotation>
    <xsd:documentation>"context" is not yet explicitely modelled, therefore we use concepts in here. The concept types are not yet enforced either. Maybe using additional tools like XSLT (Schematron?) to check this constraint is easier. No keyrings are yet set up, XML Schema allows to define distinct sets of identifiers.</xsd:documentation>
  </xsd:annotation>
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="typeHierarchy" type="concept">
        <xsd:annotation>
          <xsd:documentation>Not yet modelled (do we want to?)</xsd:documentation>
        </xsd:annotation>
      </xsd:element>
      <xsd:element name="relationHierarchy" type="concept">
        <xsd:annotation>
          <xsd:documentation>Not yet modelled (do we want to?)</xsd:documentation>
        </xsd:annotation>
      </xsd:element>
      <xsd:element name="catalogOfIndividiuals" type="concept">
        <xsd:annotation>
          <xsd:documentation>Not yet modelled (do we want to?)</xsd:documentation>
        </xsd:annotation>
      </xsd:element>
      <xsd:element name="outermostContext" type="concept"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

element module/typeHierarchy
diagram
type concept
children quantifier designator descriptor
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
annotation
documentation 
Not yet modelled (do we want to?)
source 
<xsd:element name="typeHierarchy" type="concept">
  <xsd:annotation>
    <xsd:documentation>Not yet modelled (do we want to?)</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element module/relationHierarchy
diagram
type concept
children quantifier designator descriptor
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
annotation
documentation 
Not yet modelled (do we want to?)
source 
<xsd:element name="relationHierarchy" type="concept">
  <xsd:annotation>
    <xsd:documentation>Not yet modelled (do we want to?)</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element module/catalogOfIndividiuals
diagram
type concept
children quantifier designator descriptor
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
annotation
documentation 
Not yet modelled (do we want to?)
source 
<xsd:element name="catalogOfIndividiuals" type="concept">
  <xsd:annotation>
    <xsd:documentation>Not yet modelled (do we want to?)</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element module/outermostContext
diagram
type concept
children quantifier designator descriptor
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
source 
<xsd:element name="outermostContext" type="concept"/>

complexType concept
diagram
children quantifier designator descriptor
used by
elements module/catalogOfIndividiuals relation/concept graphType/concept module/outermostContext module/relationHierarchy module/typeHierarchy
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
annotation
documentation 
Type is modelled as attribute, the notion of an explicit "referent" has been dropped.
source 
<xsd:complexType name="concept">
  <xsd:annotation>
    <xsd:documentation>Type is modelled as attribute, the notion of an explicit "referent" has been dropped.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:element name="quantifier">
      <xsd:annotation>
        <xsd:documentation>quantifier could be modelled as attribute, defaulting to "existential". We would need some way to represent the defined quantifiers then and it will be harder to validate.</xsd:documentation>
      </xsd:annotation>
      <xsd:complexType>
        <xsd:choice>
          <xsd:element name="existential"/>
          <xsd:element name="universal">
            <xsd:annotation>
              <xsd:documentation>This is different compared to section 6.7 of the standard draft, where the universal quantifier is a defined quantifier.</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
          <xsd:element name="defined" type="xsd:string">
            <xsd:annotation>
              <xsd:documentation>How to model this one? (TODO)</xsd:documentation>
            </xsd:annotation>
          </xsd:element>
        </xsd:choice>
      </xsd:complexType>
    </xsd:element>
    <xsd:element name="designator">
      <xsd:annotation>
        <xsd:documentation>An empty element represents an undetermined designator. We still don't understand the distinction between literals and locators (TODO)</xsd:documentation>
      </xsd:annotation>
      <xsd:complexType>
        <xsd:choice minOccurs="0">
          <xsd:element name="literal"/>
          <xsd:element name="locator"/>
        </xsd:choice>
      </xsd:complexType>
    </xsd:element>
    <xsd:element name="descriptor" type="graphType"/>
  </xsd:sequence>
  <xsd:attribute name="type" type="xsd:string" use="required"/>
  <xsd:attribute name="id" type="xsd:string" use="optional"/>
</xsd:complexType>

element concept/quantifier
diagram
children existential universal defined
annotation
documentation 
quantifier could be modelled as attribute, defaulting to "existential". We would need some way to represent the defined quantifiers then and it will be harder to validate.
source 
<xsd:element name="quantifier">
  <xsd:annotation>
    <xsd:documentation>quantifier could be modelled as attribute, defaulting to "existential". We would need some way to represent the defined quantifiers then and it will be harder to validate.</xsd:documentation>
  </xsd:annotation>
  <xsd:complexType>
    <xsd:choice>
      <xsd:element name="existential"/>
      <xsd:element name="universal">
        <xsd:annotation>
          <xsd:documentation>This is different compared to section 6.7 of the standard draft, where the universal quantifier is a defined quantifier.</xsd:documentation>
        </xsd:annotation>
      </xsd:element>
      <xsd:element name="defined" type="xsd:string">
        <xsd:annotation>
          <xsd:documentation>How to model this one? (TODO)</xsd:documentation>
        </xsd:annotation>
      </xsd:element>
    </xsd:choice>
  </xsd:complexType>
</xsd:element>

element concept/quantifier/existential
diagram
source 
<xsd:element name="existential"/>

element concept/quantifier/universal
diagram
annotation
documentation 
This is different compared to section 6.7 of the standard draft, where the universal quantifier is a defined quantifier.
source 
<xsd:element name="universal">
  <xsd:annotation>
    <xsd:documentation>This is different compared to section 6.7 of the standard draft, where the universal quantifier is a defined quantifier.</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element concept/quantifier/defined
diagram
type xsd:string
annotation
documentation 
How to model this one? (TODO)
source 
<xsd:element name="defined" type="xsd:string">
  <xsd:annotation>
    <xsd:documentation>How to model this one? (TODO)</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element concept/designator
diagram
children literal locator
annotation
documentation 
An empty element represents an undetermined designator. We still don't understand the distinction between literals and locators (TODO)
source 
<xsd:element name="designator">
  <xsd:annotation>
    <xsd:documentation>An empty element represents an undetermined designator. We still don't understand the distinction between literals and locators (TODO)</xsd:documentation>
  </xsd:annotation>
  <xsd:complexType>
    <xsd:choice minOccurs="0">
      <xsd:element name="literal"/>
      <xsd:element name="locator"/>
    </xsd:choice>
  </xsd:complexType>
</xsd:element>

element concept/designator/literal
diagram
source 
<xsd:element name="literal"/>

element concept/designator/locator
diagram
source 
<xsd:element name="locator"/>

element concept/descriptor
diagram
type graphType
children parameter concept relation
attributes
Name  Type  Use  Default  Fixed  
id  xsd:string  optional      
source 
<xsd:element name="descriptor" type="graphType"/>

complexType graphType
diagram
children parameter concept relation
used by
elements concept/descriptor graph
attributes
Name  Type  Use  Default  Fixed  
id  xsd:string  optional      
source 
<xsd:complexType name="graphType">
  <xsd:sequence>
    <xsd:element name="parameter" minOccurs="0" maxOccurs="unbounded">
      <xsd:annotation>
        <xsd:documentation>If at least one parameter is given the graph is a lambda expression (ok? what about 0-adic lambda expressions?). The type is modelled as attribute, the number and order is defined by the XML structure.</xsd:documentation>
      </xsd:annotation>
      <xsd:complexType>
        <xsd:attribute name="type" type="xsd:string" use="required"/>
        <xsd:attribute name="id" type="xsd:string" use="required"/>
      </xsd:complexType>
    </xsd:element>
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="concept" type="concept">
        <xsd:annotation>
          <xsd:documentation>has type (required) and id (optional) as attribute. The id can be used for coreferences, maybe it should be required.</xsd:documentation>
        </xsd:annotation>
      </xsd:element>
      <xsd:element name="relation" type="relation"/>
    </xsd:choice>
  </xsd:sequence>
  <xsd:attribute name="id" type="xsd:string" use="optional"/>
</xsd:complexType>

element graphType/parameter
diagram
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  required      
annotation
documentation 
If at least one parameter is given the graph is a lambda expression (ok? what about 0-adic lambda expressions?). The type is modelled as attribute, the number and order is defined by the XML structure.
source 
<xsd:element name="parameter" minOccurs="0" maxOccurs="unbounded">
  <xsd:annotation>
    <xsd:documentation>If at least one parameter is given the graph is a lambda expression (ok? what about 0-adic lambda expressions?). The type is modelled as attribute, the number and order is defined by the XML structure.</xsd:documentation>
  </xsd:annotation>
  <xsd:complexType>
    <xsd:attribute name="type" type="xsd:string" use="required"/>
    <xsd:attribute name="id" type="xsd:string" use="required"/>
  </xsd:complexType>
</xsd:element>

element graphType/concept
diagram
type concept
children quantifier designator descriptor
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
annotation
documentation 
has type (required) and id (optional) as attribute. The id can be used for coreferences, maybe it should be required.
source 
<xsd:element name="concept" type="concept">
  <xsd:annotation>
    <xsd:documentation>has type (required) and id (optional) as attribute. The id can be used for coreferences, maybe it should be required.</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element graphType/relation
diagram
type relation
children conceptRef concept parameterRef
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
source 
<xsd:element name="relation" type="relation"/>

complexType relation
diagram
children conceptRef concept parameterRef
used by
element graphType/relation
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
source 
<xsd:complexType name="relation">
  <xsd:choice maxOccurs="unbounded">
    <xsd:element name="conceptRef" type="xsd:string">
      <xsd:annotation>
        <xsd:documentation>The content of this has to match an id of a concept</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
    <xsd:element name="concept" type="concept">
      <xsd:annotation>
        <xsd:documentation>this could be dropped in favour of forcing a declaration as separate construct somewhere</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
    <xsd:element name="parameterRef" type="xsd:string">
      <xsd:annotation>
        <xsd:documentation>The content of this has to match the id of a parameter in a lambda expression</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
  </xsd:choice>
  <xsd:attribute name="type" type="xsd:string" use="required"/>
</xsd:complexType>

element relation/conceptRef
diagram
type xsd:string
annotation
documentation 
The content of this has to match an id of a concept
source 
<xsd:element name="conceptRef" type="xsd:string">
  <xsd:annotation>
    <xsd:documentation>The content of this has to match an id of a concept</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element relation/concept
diagram
type concept
children quantifier designator descriptor
attributes
Name  Type  Use  Default  Fixed  
type  xsd:string  required      
id  xsd:string  optional      
annotation
documentation 
this could be dropped in favour of forcing a declaration as separate construct somewhere
source 
<xsd:element name="concept" type="concept">
  <xsd:annotation>
    <xsd:documentation>this could be dropped in favour of forcing a declaration as separate construct somewhere</xsd:documentation>
  </xsd:annotation>
</xsd:element>

element relation/parameterRef
diagram
type xsd:string
annotation
documentation 
The content of this has to match the id of a parameter in a lambda expression
source 
<xsd:element name="parameterRef" type="xsd:string">
  <xsd:annotation>
    <xsd:documentation>The content of this has to match the id of a parameter in a lambda expression</xsd:documentation>
  </xsd:annotation>
</xsd:element>


XML Schema documentation generated with XML Spy Schema Editor www.xmlspy.com