Subject: [mile] Classes extending iodef:MLStringType

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 21 Dec 2015 18:16:29 +0000

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.

Roman