Standards » Management Area » GLUE WG

h1. Board for ideas Considered at least by one person

Pool of other ideas that are being considered by one of other people. You are free to make use of this page to draft your ideas.

* In the ComputingService entity (page 24), you are trying to redefine relationships of a superclass, which is not possible using the standard inheritance concepts.

** In this definition, there is also StorageService.ID defined and Service.ID still there.

** This error is also repeated in most of the entities done from page 24 onwards.

** Sergio: in UML 2.0 it is possible to redefine assocation ends, therefore the proposed solution is correct

** Final: No, in UML 2.0 it can be done this way, so we will use it although we won´t be able to hide the relation of the superclasses.

* ToStorageService and ToComputingService entities are not bidrectional with StorageService and ComputingService.

** Solution: Make them bidirectional adding the proper fields to StorageService and ComputingService.

** Sergio: I'm not clear about this observation; the two concepts are unidirectional in the reality and we need to represent this in the model

** In the ComputingService entity, you let the relation "StorageService.ID" empty. This will be removed so access to StorageService will be performed through the ToStorageService entity.

** No, because we want it to be unidirectional, although in the implementations will be seen both ways (because of language restrictions)

* Paul Millar: Location.Country is simply "Name of country." However, this can lead to confusion. Is the United States of America "US", "USA", "United States", "United States of America"? Is the United Kingdom represented by "GB", "GBR", "UK", "U.K." etc.

** Perhaps we should clarify this. I would change the definition to: Name of country. The value SHOULD be the country's ISO 3166-1 Alpha-3 code.

** David Horat and Paul Millar agree.

* David Horat: In the GLUE Specification v. 2.0, in the association end list, relations are always specified with the attribute they have to link with. (E.g. Service.ID) This is not correct because of several reasons:

** In the Entity-Relationship models, you just specify relationship between entities/classes/objects, without any knowledge of each of the attributes in them.

** To know which attribute you want to link with from the related object, you should have to take a look of its definition to get the key fields.

** The key fields could be more than one. Sometimes the key of an entity is a combination of several fields, so the current way of visualizing relations will be broken.

** I suggest just taking out every attribute in all the Association End list to comply on how to use this kind of diagrams, to avoid problems in the future with multiple key fields.