Talk:CHALIM

jens 17:19, 21 December 2008 (CET)

Initially I added CATREA; works together with RESTRN describing RESARE features and completes this data structure.

I though deeper of these two attributes. I don't see why to use them. If restrictions like these apply the RESARE geometry can be used. That makes the duplication of these attributes superfluous. They are described there.

Remarks shown in brackets are doubtful. That makes in my opinion not much sense.

DavidAcland 16:28, 15 January 2009 (CET)

I came to the same view independantly. I do not see the need for CATREA nor how to use it,if it were retained. I believe resdes will cover restrictions better than RESTRN. Both deleted.

Agree that bracketted remarks can go. Deleted and copied in here for the record:

((((RESTRN and CATREA encode the type of restriction; a short explanation may be given by the use of the attributes INFORM, and NINFORM.))))

DavidAcland 17:26, 19 January 2009 (CET)

Now that we have the attributers agreed, it is worth thinking again about the logic.

1. Most attributes indicate the limits for passage or use of a facility or area.

2. prfmnc is a bit different because as drafted it states what is required. Perhaps we could amend that to read "minimum requirement" for "hull design, main and auxiliary machinery etc".

3. The real problem is the 3 brothers. The definition mentions "...restrictions...". Accepting that we are currently building the data dictionary and not the product specification, and that the binding shown here is only our feeling for the way attributes could be combined in a product, do we need rcmdts and reglts? What I am really getting to is, if the restrictions are fully covered by the attributes, could we remove resdes as well? If we could, that would remove one of our cases where we have an association between info objects.

4. If we do want to keep rcmdts and reglts, we should probably include these ideas in the final phrase of the definition, along the lines "...and an indication of the recommendations, regulations, and restrictions that apply."

3 brothers in relationship to this object

I hoped that would be quit simple, but...

What was our intention with this object? We intended to cover ALL limitations (restrictions, regulation, recommendations). That is probably too much. I checked this object against the other information objects. All (nearly all) have the DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA as type A attribute. (by the way, I think we should add those where they are not been added yet)

I thought that was the key to solve the problem. In a first view I recommended to put DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA to restvc and to delete the three brothers. We can handle the relationsship between the geo object (where the limitations apply) and the restrictions of vessels and well as our three (four if we add nautical information) brothers. That would work fine in anyway and I really recommend to do it.

Adhering this we will have one major problem. How to handle different limitations and brothers for different types of vessels for the same geo object? One way, the easiest for us, is to continue our initial idea to add inf object to inf objects. The other idea is to handle the reference within the geo object by using ...I don't know. INFORM - bad. Within the written text of the brothers - I'm not convinced that it works. Where else?

To summarise my ideas, the only one witch solve all problems is to continue with inf object to inf object and to improve the definition in a way that "restrictions" will not be shown. Independently from that we should add DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA as well to make the "normal" handling convenient to the modeller.

David, what do you think? My mind (the German and the English one) is at the death end.