Menu

#264 Put 'id' and 'name' attributes on SBase

closed
1
2014-05-29
2014-05-27
No

Lucian originally filed this under issue 255, but that issue was specifically about not adding id and name to SBase and instead, adding the attributes selectively to those things that lacked them. However, we should open a new item for the new decision of putting the attributes on SBase, and close 255. This way, we record the decision against taking the approach outlined in 255, and have an issue for the specific item of adding id and name on SBase.

Here is the text originally written by Lucian. It works well as the text for this new issue:

By common consent at the 2014 HARMONY meeting, this issue was accepted by agreeing to make 'id' and 'name' optional attributes of SBase.
Some implications:

  • Section 3.3.1 will have to be rewritten.
  • The UnitSId type will have to be revisited and possibly removed, to be replaced by a discussion similar to section 3.3.1 that talks about model-wide uniqueness of Unit "id"s.
  • SIdRef and UnitSIdRef types remain, but their descriptions will have to be modified slightly.
  • All the UML diagrams for anything with an id/name will have to be updated.lk
  • Any element where 'id' was required will need some sort of text explaining how the id was optional on SBase, but is required on the derived class.
  • A description of what to do with package elements that inherit from SBase will have to be added, probably to section 3.3.1

Discussion

  • Michael Hucka

    Michael Hucka - 2014-05-27
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -4,9 +4,9 @@
    
     By common consent at the 2014 HARMONY meeting, this issue was accepted by agreeing to make 'id' and 'name' optional attributes of SBase.
     Some implications:
    -* Section 3.3.1 will have to be rewritten.
    -* The UnitSId type will have to be revisited and possibly removed, to be replaced by a discussion similar to section 3.3.1 that talks about model-wide uniqueness of Unit "id"s.
    -* SIdRef and UnitSIdRef types remain, but their descriptions will have to be modified slightly.
    -* All the UML diagrams for anything with an id/name will have to be updated.lk
    -* Any element where 'id' was required will need some sort of text explaining how the id was optional on SBase, but is required on the derived class.
    -* A description of what to do with package elements that inherit from SBase will have to be added, probably to section 3.3.1
    +- Section 3.3.1 will have to be rewritten.
    +- The UnitSId type will have to be revisited and possibly removed, to be replaced by a discussion similar to section 3.3.1 that talks about model-wide uniqueness of Unit "id"s.
    +- SIdRef and UnitSIdRef types remain, but their descriptions will have to be modified slightly.
    +- All the UML diagrams for anything with an id/name will have to be updated.lk
    +- Any element where 'id' was required will need some sort of text explaining how the id was optional on SBase, but is required on the derived class.
    +- A description of what to do with package elements that inherit from SBase will have to be added, probably to section 3.3.1
    
     
  • Michael Hucka

    Michael Hucka - 2014-05-27

    Since the decision was made during HARMONY with in-person discussions, we don't need a separate vote using the issue tracker. I am calling this issue accepted.

     
  • Michael Hucka

    Michael Hucka - 2014-05-27
    • status: open --> accepted
    • Group: Reported-Proposed --> Accept-conformance-implications
     
  • Lucian Smith

    Lucian Smith - 2014-05-27
    • labels: --> Level 3 Version 1 Core
     
  • Lucian Smith

    Lucian Smith - 2014-05-29

    Incorporated into SVN for L3v2, and will be part of the forthcoming release of that specification.

     
  • Lucian Smith

    Lucian Smith - 2014-05-29
    • status: accepted --> closed
     

Log in to post a comment.

MongoDB Logo MongoDB