Cardinality attribute

[jetgeo]

Cardinality appears in abstract FC_PropertyType and in the subtype FC_AssociationRole-- would result in two identical property names in the same element-- invalid. (apparently the idea is to assign a different default value in the subtype, but this should probably be a constraint?)

[jetgeo]

Agree. Delete FC_AssociationRole.cardinality. Why is the default value different in PropertyType and AssociationRole? If needed: add constraint "Default value for cardinality is 0..*" on FC_AssociationRole.

[jetgeo]

In the General Feature Model in ISO19109, cardinality is defined on AttributeType and FeatureAssociationRole. This makes more sense - cardinality is not relevant for operations, is it? Should the cardinality attribute under FC_PropertyType be moved to FC_FeatureAttribute?

[DaveDanko]

it has been that way since 2005 version I think we are suppose to fix it up for publishing not re-engineer the model

[jetgeo]

Well, yes, but is can't be implemented. AssociationRole already have the cardinality attribute inherited from PropertyType, it can't have a cardinality attribute of its own. Changing this is not re-engineering, it is fixing a critical error for implementation.

[DaveDanko]

That was my thinking at first but It has been implemented http://www.isotc211.org/2005/1.1/gfc/gfc.xsd Maybe Nicolas had a special script in his UML to XML transform?? It is just that we've been getting in deeper and deeper, and I'm not a FC person, and I know these models have been extensively argued, by experts, over many years. But I think your suggested fix would be best. don't forget to fix the data dictionary when you make the model changes.

[jetgeo]

In the old implementation, the cardinality attribute on AssociationRole is inherited from PropertyType. The cardinality attribute that is directly on AssociationRole in the model is ignored:

xs:documentationA role of the association FC_AssociationRole::relation. - [ocl] - roleName = FC_Member::memberName; - FC_PropertyType::cardinality realizes GF_AssociationRole::cardinality - [/ocl]/xs:documentation /xs:annotation

I think the best solution both for implementation and for harmonization would be to move the cardinality attribute from PropertyType to AttributeType, like I have suggested above, and like it is in the GFM.

I can do the change in the model and update the document.

[smrgeoinfo]

+1 on Knut's suggestion to align the 19110 with GFM.

[jetgeo]

Some more challenges... Cardinality is referred to for operations several places in the document, i.e: 6.3, table 2: Identifier: req/operation/cardinality An operation SHALL have a cardinality property that specifies the number of return values possible. Default value is 1.

Table B.4: cardinality of the member in the feature class. If this is an attribute or operation, the default cardinality is 1. If this is an association role, then the default cardinality is 0..*. For operations, this is the number of return values possible. This is an elaboration of the GFM to allow for complete specifications for various programming and data definition languages.

So I guess what we have to do is this:

• Remove FC_AssociationRole.cardinality
• Add constraint about defaultvalue on FC_AssociationRole
• Fix the text according to this.

I'll try to do these changes now, and ask you to look at it afterwards.

[jetgeo]

Done. Changes in the document:

• Figure B.1 (not sure about the constraint on FC_AssociationRole)
• Table B.10
• Tables E.21, E.22

If think this is OK now - if you disagree - reopen the issue.