EXPRESS 1.0 FTF Avatar
  1. OMG Issue

EXPRESS_ — The metamodel doesn't seem to support a Schema -> Interface -> Schema relationship

  • Key: EXPRESS_-26
  • Legacy Issue Number: 13447
  • Status: closed  
  • Source: TopQuadrant ( David Price)
  • Summary:

    Issue Submitter: David Price, Eurostep

    Document: EXPRESS Metamodel, Alpha Version

    Issue:

    The metamodel doesn't seem to support a Schema -> Interface -> Schema
    relationship. I do see Schema -> InterfaceElement -> SchemaElement
    relationship in the metamodel but it's as often as not the entire Schema
    that gets interfaced.

    If I were using the metamodel in a tool to create EXPRESS, this seems to mean
    I can't establish schema interfaces beforehand (e.g. to split a domain being
    modeled into subdomains) unless I have elements in every schema. This seems
    like a gap in the metamodel.

    What I mean by this is that I should be able to take the EXPRESS metamodel,
    build an application that directly implements the classes it defines and then
    I should be able to create any and all valid EXPRESS schemas.

    Since:
    SCHEMA A;
    Â USE FROM X;
    END_SCHEMA;
    SCHEMA X;
    END_SCHEMA;

    is valid EXPRESS it seems to me the metamodel should support this. It doesn't
    seem to me that the distinction is purely syntactic if there are valid
    schemas that cannot be represented using the metamodel. I do agree with Ed
    Barkmeyers analysis of what the text in Part 11 says, it's just that the text
    appears to be incomplete in that it doesn't cover the A and X situation
    above.

    Related Discussion Summary:

    >From Ed Barkmeyer: I would say that USE FROM <schema>; is just a syntactic
    shorthand. Â What is actually interfaced is a specific collection of
    InterfacedElements. It is not clear that any additional semantic
    relationship is established between the two schemas. Â The only relationship
    between the two schemas is that some of the InterfacedElements in one Schema
    refer to SchemaElements defined in the other one.

    In the UML case, the relationship is package-to-package, and circular
    import/merge relationships are not valid. Â But EXPRESS is very clear that the
    relationship is schema-to-InterfacedElement, and circular references among
    the schemas themselves are permitted. Â Also in UML, importing a package
    doesn't change the local package namespace. Â In EXPRESS, interfacing elements
    adds identifiers to the local schema namespace. Â So Exp:Schema and
    UML:Package are only superficially similar.

    I guess we never discussed using the metamodel to "create EXPRESS", and
    I'm not quite sure what that means. Â But Bernd Wenzel pointed out at one point
    that certain purely syntactic information should be maintained in the
    metamodel to allow a reasonable approximation to the original EXPRESS
    schema to be constructed.

    My understanding was that EXPRESS was being treated as the legacy.
    So the intent of the metamodel was to capture the knowledge contained in
    a set of EXPRESS schemas, for the purpose of rendering that knowledge
    into more useful forms.

    It is not clear whether USE FROM X (<list of everything in X>); is a
    "reasonable approximation" to USE FROM X; . Â But it is certainly true
    that there is no way in the metamodel to represent USE FROM X; if X
    contains no declarations.

    Note also that, unlike USE FROM X;, what REFERENCE FROM X; interfaces is
    selective, and there you want the metamodel to capture the
    interpretation – the results of the algorithm described in clause 11 –
    not just the parse. Â So I would never want to see a metamodel population
    in which some schema-to-schema relationship was captured INSTEAD OF the
    collection of schema-to-InterfacedElement relationships that that syntax
    MEANS. Â (But the other experts may not share my view.)

    Proposed Resolution: No

  • Reported: EXPRESS 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Add Interface to clause 8.4 and Figure 2, with two associations: interfaced-schema, interfacing-schema and an isUSE attribute

  • Updated: Wed, 11 Mar 2015 01:53 GMT