Starter object model and libCellML intro #8
Conversation
…t is connected. This is not normalised from the API view, i.e. if a has b in its collection, b will have a in its collection. In the XML serialisation for CellML 1.1, and proposed for CellML 1.2, this is normalised by means of the "Connection" XML element. The implementation of the API would most likely have this normalised.
Started adding classes etc for representing imported components.
This is one idea, there are other options.
Also, hid members on overview diagram
Please see: http://codecurve.github.io/cellml-core-spec/#interpretation-of-units and associated sections.
Also: - some minor renaming of association ends. - some minor tidying, e.g. hiding association names on some diagrams. Will probably do this in other places.
One proposal for implementing reset rules is to allow boolean variables. Added boolean and real subtypes for variable class, removed association with Unit class from variable and moved to real subtype. Also, added "Variable" diagram for more details on variable class, showing these details, as well as connectedVariables. Also, made unit class name property visible on Units diagram, probably need to do the same on some similar situations.
Also, hid members that are shown as associations on overview diagram.
Reason: connections design shown on Variable diagram.
Also, unhid name attribute of component superclass on Imports diagram.
Maybe relying on relative links is simpler?
Also, "stand alone" -> "stand-alone"
There was some private discussion of previous versions.
|
Hi Randall. Just a couple of initial comments.
What do others think about this? Cheers, |
|
I'd agree about not merging it yet. Although note that it's common GitHub style to leave a pull request open while a piece of work is ongoing, as a convenient place to summarise discussion on that work item. Any new commits to the source branch get added to the pull request automatically. |
|
good point, thanks! |
|
FWIW, I agree with both David's and Jonathan's comments. |
|
From what I can tell, it is preferable to include the .project, although I don't think we want it at the top level in the long run, but for the sake of not having to figure out sub-repos or having the eclipse project not at the top level, I committed it now, since we can always figure that out later. Since the images are derived from the UML files, the docs generator could (in theory anyway) generate the images from the UML files (perhaps there is a Papyrus CLI, or some other UML CLI image generator). Anyway, it probably makes more sense to version control the UML files than the image files, but for the sake of expedience, I just did it this way for now. Jonathan's understanding of the use of a pull request is exactly the same as mine, i.e. discuss the work that is on the branch for the pull request and make changes on the branch until eventually the pull request gets merged. |
|
It is definitely not preferable to include the .project file in the repository it may contain absolute paths that are only relevant to a particular user so they should not be present in the repository. The source UML files should also not be added to the repository as they are for generating the images of the object model design. They are not in themselves of interest to libCellML, I agree with |
|
I don't really mind whether or not we include the .project and UML files, but I don't see any harm in including them now and moving them out later. |
|
Given one vote of ambivalence and three votes to remove those files from this repository, they should be removed. Might even be worth creating a new branch with just the near-complete version of the objectModel document just to make the history of the cellml/libcellml repo cleaner - but we can decide that later in the review/discussion process. |
|
OK, see cellml/libcellml#9 So we should probably close this pull request? |
|
Thanks Randall. Closing this one in favour of #9. |
No description provided.