Talk:APPLIC

---

The _HI and _LO attributes can be defined like this:

Definition: Draught, upper bound

Acronym: DRF_HI

Camel case: DraughtUpperBound

Attribute type: F

Definition: The upper bound of a numeric range for vessel draught.

Resolution: 0.01 m or 0.01 ft

Format:

xx.xx

Example:

12.56 for a maximum draught of 12.56 metres.

Remarks:

No remarks

jens 06:35, 6 July 2010 (UTC)

ok, I understand that. It sounds logical.

May I point to two items I identified as either being a problem or offering room for improvement. 1. How works LOGCON 2? I have problems to develop and to understand an example which satisfied me.
Using your first example I would assume that if LOGCON is been set to 2 the regulation applies for either vsl over 50 m length or tankers. Is my assumption correct?
2. I discussed the problem with Martin this morning and some very interesting ideas are on the table now.
Is it thinkable to state certain characteristics like draught, length, beam, air draught etc. as complex attributes and introduce logicalComparisonOperator.
That would reduce the quantity of attributes used and offers much more flexibility. A further reason why I am suggesting the complex type is that in the two examples you provided only max and min parameters are settled. The term "vessels of 50 m length or more" is not settled.

Example:

Attribute: name to be defined
Attribute type: Complex

Sub-attribute	Camel Code Identifier	Multiplicity	Sequential
VSLCAR	vesselsCharacteristics	0..*	True
????	value	0..*	True
COMPOP	logicalComparisonOperator	0..*	True

VSLCAR (length, beam, draught, air draught, GT, NT, DWT, DPL ) is just an idea, depends on the result of the discussion we can keep or bin it.
COMPOP has to be to developed and should provide various comparison operators; see http://de.wikipedia.org/wiki/Logische_Operatoren or the English version http://en.wikipedia.org/wiki/Logical_connective
However, the German version provides the better symbols :)
The definition of LOGCOM must provide the relation between the value given in the model and the real ship's value.

That would result
1. VSLCAR=draught; value=10.5; COMPOP=(>=) the regulation applies for vsl of 10.5 m draught and above
2. VSLCAR=DWT; Value=2000; COMPOP=(=) the regulation applies for vsl of exact 2000 DWT
3. VSLCAR=length; value=150; COMPOP=(<) the regulation applies for vsl of less than 150 m length

Using your first example
[complex attribute [VSLCAR=length; value=50.0; COMPOP=(>)]], CATVSL=3 (tanker), LOGCON=1 (and), LIMTYP=2 (required); associated to a PILBOP object: tankers with LOA > 50.0 m must use the PILBOP

If the example should work for tanker between 50 and 100 m length the coding is like this
[complex attribute [VSLCAR=length; value=50.0; COMPOP=(>)], [VSLCAR=length; value=100.0; COMPOP=(<)]], CATVSL=3 (tanker), LOGCON=1 (and), LIMTYP=2 (required); associated to a PILBOP object: tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP

What do you think?

raphael 22:46, 6 July 2010 (UTC): Only short answers today; let's create a new page for APPLIC and discuss it there (no need to make new pages for its new attributes yet, we can discuss them on the Talk:APPLIC page).

The new complex attribute is theoretically OK. I want to think about the practical issues some more: how easy/difficult it might be for encoders to understand; integer vs. float limits; specifying data validation tests.

ComparisonOperator (COMPOP) is better than LOGCOM (which is likely to be confused with LOGCON).

LOGCON=2 (or): Yes, that is how it would work (and a HI/LO pair would define a range, not separate conditions).

jens 04:58, 7 July 2010 (UTC) ok. I replaced LOGCOM by COMPOP.

I don't understand your reservation against Integer vs. Float from 2 views:
1. From the ship's theory point of view it is not impossible to provide also information which is currently given as Integer as Float or vice versa. Indeed, ship's theory information on GT or NT are rounded to Integer after a high accuracy calculation with Float.
2. From the data point of view I think it is not impossible for software developer to calculate with Float in the BE although Integer is presented to the FE user and vice versa.

raphael 23:52, 8 July 2010 (UTC): (1) I agree in principle with the VSLCAR-COMPOP idea.

(2) Making NewComplexAttribute itself repeatable (instead of its sub-attributes) might be easier for humans and software (encoders, validators, displays). That is, for vessels of length 50.0 to 90.0:

NewComplexAttribute(VSLCAR=length; COMPOP=(>=); value=50.0)
NewComplexAttribute(VSLCAR=length; COMPOP=(<=); value=90.0)

instead of
NewComplexAttribute(VSLCAR=length; COMPOP=(>=); value=50.0; VSLCAR=length; COMPOP=(<=); value=90.0)

(The integer/float issue is a bit complicated...it might be better on its own page.)

We need to work on watertight and simple definitions for the new attributes and sub-attributes.