Subject: Re: [mile] Classes extending iodef:MLStringType

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Jan 2016 14:58:16 +0000

Hi Roman,

On 21/12/2015 18:16, Roman D. Danyliw wrote:
> Hello WG!
>
> Updates to 5070bis addressing the feedback from the WGLC is almost complete.  In cleaning up the text in Section 2, Data Types, I noticed that four classes (SystemImpact, BusinessImpact, IntendedImpact and NodeRole) are defined as extentions to iodef:MLStringType -- they add more attributes.  I wonder if that's the right thing to do giving the recently introduced complexity of the @translation-id.
>
> Consider the following:
>
> <Assessment>
>    <SystemImpact xml:lang="foo" translation-id="1" type="damaged-data">Impact 1</SystemImpact>
>    <SystemImpact xml:lang="bar" translation-id="1" type="cps-damage">Translation of Impact 1</SystemImpact>
> ...
> </Assessment>
>
> There appear to be two SystemImpact classes that are translations of each other (both with @translation-id=1).  However, they have different values for the @type attribute strongly suggesting they aren't identical instances of the same class.  Shouldn't instances of SystemImpact with the same translation-id have the same @type value?  This same circumstance can arise in BusinessImpact, IntendedImpact and NodeRole.
>
> Option 1:
> =======
> Would a syntax as follows be preferred to prevent this inconsistency:
> ...
> <Assessment>
>    <SystemImpact type="damaged-data">
>      <Description xml:lang="foo" translation-id="1">Translation of Impact 1</Description>
>      <Description xml:lang="bar" translation-id="1">Translation of Impact 1</Description>
>    </SystemImpact>
>    <SystemImpact cps-damage" />
> ...
> </Assessment>
>
> +-----------------------+
> | SystemImpact          |
> +-----------------------+
> | ENUM severity         |<>--{0..*}--[ Description       ]
> | ENUM completion       |
> | ENUM type             |
> | STRING ext-type       |
> +-----------------------+
>
> Option 2:
> =======
> As an alternative, class-specific text could be written to state which attributes need to be identical for a given translation-id.
>
> IMHO, I'm leaning towards Option #1 because it will likely mean less implementation logic and it prevents even making the wrong XML.
Speaking with no hats, I prefer your option #1 as well.