Community
Participate
Working Groups
Provide a model library to represent the types defined in the XMLType metamodel in EMF; be sure to update the Ecore/UML converters to make use of this new library.
I propose that the XML Schema datatype library be implemented using UML DataType instances (instead of Class or PrimitiveType). The XSD datatype spec describes the built-in types as being a small number of "primitives" and the others as "derived". Because the UML2 spec prohibits a DataType from subclassing a PrimitiveType, it is not possible to implement the XSD type inheritance with the base types as primitive. In addition, when creating UML models of schema designs, it is natural to represent complexType with simple content (i.e. a complexType that extends a simpleType, then adds XML attributes) as a UML DataType with properties for the complexType attributes. If the entire library of XSD built-in types were represented as PrimitiveType, then they cannot be extended with a DataType that adds attributes.
How would you expect your specialized data types (with additional attributes) to be handled when converting the UML model to/from Ecore (given that data types in Ecore cannot have attributes)?
Not all UML models are converted to Ecore... my primary use case (and that of the companies I am working with) is to create UML models of XML schema designs and to generate XSD from the models. They mostly use JAXB 2.0 or XMLBeans for Java binding. However, I would expect the Ecore conversion to be handled in the same way that Ecore models are created while importing these same kinds of structures from XSD. The structures I am referring to here is a complexType that extends a simpleType and adds attributes, a.k.a complexType with simple content. EMF import from schema does handle this, but I have not studied how it is done.
Created attachment 54660 [details] first crack at support
Created attachment 54661 [details] 2 of 4
Created attachment 54662 [details] 3 of 4
Created attachment 54663 [details] 4 of 4
Comment on attachment 54660 [details] first crack at support small modifications to come.
Thanks, James. I was planning to test this patch today but will wait for your modification. Are these patches applied against HEAD? Will this library be delivered with a 2.0.x or 2.1 build? The sooner the better for me. I have my own XSDDataTypes library (using my XSD profile) but would like to change to this common library asap.
Hi Dave, After discussing in more detail with Kenn (and Kenn speaking with Ed Merks) I will be making more changes shortly. ( ie complex types going to EClass not EDataTypes) I will be delivering to the 2.1 (head). This feature is targeted for M4 but I expect that this will be ready to go in the next couple of days. Regards, - James.
Can we add the Generalizations between DataTypes, as defined by baseType restrictions in the XSD schema for schemas? This is very helpful for modeling tools that provide constraints on property types, e.g. must inherit from XSD String type. I can help add these Generalizations to the library model if you like.
I can add those generalizations in (I'll have to add support for creating those automatically anyway).
Created attachment 54732 [details] Updated patch Here is an updated patch based on the discussion I had with Ed. Basically, the XML types library will contain primitive types that have generalizations between them based on the baseType annotations from Ecore.
Dave, please hold off on applying the latest patch ... there are very minor issues with the menu items and the resources need to be updated.
Created attachment 54749 [details] update with all mods
The changes have been committed to CVS.
Dave, The XML data types in question are marked as PrimitiveTypes. To get the kind of complex types you are looking for you need to: 1. Create a DataType. 2. Stereotype your new data type with <EClass> 3. Set the XML Content Kind to Simple 4. Create a property 5. Type the property with a Primitive type 6. Streotype your property with EAttribute. 7. Set the featureKind to "Simple". Converting such a uml model to .ecore will now produce the kind of model you expect and also converting from .ecore to .uml will work as you want. Let us know if you have any issues.
Available in build: I200611301324 From: http://www.eclipse.org/modeling/mdt/downloads/?project=uml2-uml
Move to verified as per bug 206558.
