Schema Composer - Editing Restrictions

[Ian Mitchell]

I'm a bit of a newbie to the XML Schema Composer, but think I get the basic function - which is clear and usable.
I'm now trying some of the value-add which I would expect to be doing as I generate a schema from a class model, by adding and editing Restrictions - the multiplicity/optionality of an attribute.
I right-click the attribute to see the restriction, but I can't edit it. Is there something simple I'm doing wrong?
(EA V12 build 1215, Ultimate Edition)

[Eve]

The restrictions available will depend on the schema set you have selected.

[Rodrigo Nascimento]

Hi Ian,

The restrictions will be based on how you modelled the physical class model.  In the case of a class attribute that is going to be translated as a XSD simple type, just go to respective class attribute settings and change the multiplicity.

I'm finishing my first overview of the Schema Composer tool, and will post the link here by the end of this week.

Hope it helps!

Cheers,
Rod

[Rodrigo Nascimento]

As promised... here is my Schema Composer overview article:

http://connection.rnascimento.com/2015/06/24/sparx-ea-schema-composer-overview/

Hope you find it useful!

[Eve]

It may be useful to see the Enterprise Architect 12 - Release Highlights webinar. There is a segment there on the schema composer.

Rodrigo,

I read through your article for the indirect feedback.

Probably the most important thing is that we didn't design it to work with the xsd profile. It's designed to work primarily with class models and create an appropriate schema to allow send that model (or a subset of it.) That should give a different perspective on the multiple physical formats issue. It also explains what is happening when EA doesn't correctly handle all of those stereotypes. As you know, it's on our todo list.

[Rodrigo Nascimento]

Hi Simon,

I understand where you guys started with the Schema Composer and appreciate the efforts to listen to feedbacks and, most importantly, considering them in your product development.

If you allow me, I would like to suggest something to your strategic view of the Schema Composer. As one of the mains features of Sparx EA (in my view) is the support to MDA approach, I would leave the transformation from logical to physical models to the Model Transformation (MDA) functionality (for all the benefits that the MDA approach offers). I don't think that the Schema Composer is (or should be) the right tool to give the different perspectives on multiple physical formats, but definitely the right one to generate the respective physical files (a.k.a. code generation functionality). Therefore, I would use the MDA Transformation Templates to deal with the different physical formats (XSD, JSON, RDF...), mainly because it can deal with unavoidable translations between PIM and PSMs, and Schema Composer to create the code generation profiles (schema profiles).

We have been using this approach to deal with our SOA/API challenges by deriving XML and JSON schemas from our Enterprise Information Model, and it has been solving a lot of our problems related to traceability, consistency and delivery time/cost.

Does it make sense?

Regards,
Rod