wiki:tickets/185

notes for  ticket 185


contents:


summary

Establish the procedure for going from the CONCIM (UML) to the APPCIM (XSD).

meta-model

In order to standardise the CONCIM (UML) to APPCIM (XSD) process, we need to agree on the UML constructs we will use in the CONCIM and what XSD constructs they should correspond to in the APPCIM. This is partly what the meta-model is all about.

Bryan began to discuss the  metamodel earlier. I will build upon what he has written there to come up with a set of rules for CIM development.

The following stereotypes will exist (other stereotypes will be ignored):

stereotype / tagged valueXML equivalentdefinition
abstractan xs:simpleType or xs:complexType, but not an xs:element or xs:attributean abstract type is not expected to ever be instantiated; it is generally used as a parent class.
documentat least an xs:element that can form a document root; may also be of type xs:complexType or xs:simpleTypea document is something that can be downloaded as a complete XML document.
enumerationan xs:restriction based on xs:string with xs:enumeration valuesa restricted set of values; a controlled vocabulary
enumeration.hrefthe (optional) location of the "vocabulary server" where the enumeration is maintained
codelista xs:union of an enumeration (above) and xs:stringan extendible set of values; a non-exclusive controlled vocabulary
codelist.hrefthe (optional) location of the "vocabulary server" where the codelist is maintained

Some relevant (built-in) datatypes & classes to use when developing the CIM:

UML datatype / classXML equivalentdefinition
Characterxs:string with a length restriction of 1
CharacterStringxs:string
Integerxs:integer
Realxs:double
Booleanxs:boolean
ISO:Datexs:date
ISO:Timexs:time
ISO:DateTimexs:dateTime
URIxs:anyURI
packagexs:schema
  1. All associations shall have cardinalities defined for both association ends [from Bryan's notes]
  2. All referenced types must exist within the UML except for enumerations and codelists with appropriate href tagged values.
  3. Restrictions on datatypes will be described using OCL in the CONCIM. OCL will not be used to...
  4. When referencing another unit of metadata the ___ construct will be used...
  5. CodeList & Enumeration classes should have the suffix "Type".
  6. All UML classes will correspond to xs:complexType. Some UML attributes will be represented as local xs:elements, others by xs:attributes. Only <<document>> classes will be global xs:elements.
  7. Therefore <<documents>> cannot simultaneously be <<abstract>>.
  8. attributes and sub-elements will be ordered alphabetically, to ensure a consistent ordering in XSD (since XMI imposes no ordering)
  9. Package and class names should be valid XML names, so no non-alphanumeric characters, UML classes should be upper camel case, UML attributes and roles should be lower camel case.
  10. "Collection classes" should be made explicit, not by using role names. That is, these two diagrams mean different things.
  11. An association is assumed to be bi-directional; if you want a relationship that is unidirectional, use an attribute. (I'm not very happy about this rule; if anybody has a better idea, let me know.)
  12. Any class can only have 1 parent.

techniques

1. generating XSD direct from EA

This has given mixed results. Largely it is dependant on the quality of the source UML. So, for something confusing like the software package it produces a big mess, while for something a bit more straightforward like the data package it works a bit better.

One drawback, though, is that EA has its own rules about the UML to XSD mapping which don't necessarily correspond to what we want to happen. For example, all UML attributes (and associated classes) are instantiated as xs:elements; there are no xs:attributes. Also, there is no built-in support for CIM-specific stereotypes, nor OCL constructs.

I think that we want more control over things than that.

I will continue to use EA to generate the APPCIM as a starting point. And that will still feed back issues into the structure of the CONCIM. But in the long run, this is not the technique we will use.

2. generating XSD using UML profile for XSD in EA

This uses predefined stereotypes which have a particular meaning for EA. That in itself isn't a bad thing. However, the stereotypes are XML-specific concepts like <<XSDattribute>>, <<XSDelement>>, etc. And it seems like bad form to insert that sort of low-level implementation-specific information into the CONCIM.

I tried tweaking this technique to just rename those stereotypes, but had no luck. I will not be pursuing this.

3. developing custom XSL code

So far, this shows the most promise. XSL code can be seen here:  http://metaforclimate.eu/trac/browser/CIM/branches/dev0p2/concim2appcim.xsl

4. tips from relevant ISO standards

random notes

  • a package corresponds to a schema, but individual documents will make use of classes from multiple packages, so I will create a single schema for the APPCIM which includes the individual package schemas w/ appropriate namespaces. Only <<documents>> can form root elements
  • look at gml:null type
  • how should we reference external documents? Suppose a new model wants to reference an existing experiment? Suppose an existing experiment wants to reference a new model? Can there be a hierarchy of documents (ie: this must exist before that)?
  • how to work out if UML attributes are xs:attributes or xs:elements:
    • a UML attribute is an xs:element, unless it is of type x, where x is either an <<enumeration>>, <<codelist>>, a built-in datatype (see above), or a restriction on a built-in dataype (ie: an xs:simpleType), or unless it has an upper bound greater than 1, in which case it is an xs:attribute.

Attachments