nc:ObjectType?

[iamdrscott]

Every object type in NIEM 5 XSD is derived from structures:SomeObjectType. But I didn't include that derivation in CMF, for three reasons:

1. Everything in structures is XML plumbing. There's nothing that belongs in an application data model.
2. Derivation from structures is an obstacle to reusing external definitions -- it requires adapter types.
3. I didn't think we needed a universal base class in NIEM models.

And so I was as happy as a pig in mud, until I wanted to handle ISM attributes as an attribute augmentation. Well, now, genius: if you want to augment every model component with an ISM attribute, you need a universal base class for that augmentation.

I could put the structures base classes into CMF. But I still don't want to do that. Everything in structures is still XML plumbing. A universal base class in the NIEM model should be part of the core. So for NIEM 6, I've created nc:ObjectType and nc:AssociationType, and derived all the other model classes from these.

  <xs:complexType name="ObjectType" abstract="true">
    <xs:annotation>
      <xs:documentation>A data type for a thing with its own lifespan that has some existence.</xs:documentation>
    </xs:annotation>
    <xs:complexContent>
      <xs:extension base="structures:ObjectType">
        <xs:sequence>
          <xs:element ref="nc:ObjectAugmentationPoint" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>        
      </xs:extension>
    </xs:complexContent>

What do you think?

[davaya]

If you want every model component to have an ISM attribute, then I agree that a universal base class is needed, and XML-specific plumbing is not.

But I question the requirement. Just as every component that can be referenced incurs the overhead of defining and managing an id URI, adding information security markings to every atom of a body incurs overhead that outweighs the atom itself. In a paper document the minimum marking granularity is the paragraph - (u//fouo)we(/u//fouo) (u//fouo)don't(/u//fouo) (u//fouo)mark(/u//fouo) (u//fouo)every(/u//fouo) (ts//sci)word(/ts//sci).

Note: fake markings for illustration purposes only.

In a data model for an image we are not going to individually mark the classification of every pixel. In a data model for a GPS track, we are not going to individually mark every GPS coordinate. In a Crash Driver, we're not going to mark the classification of a Person's middle initial separately from the classification of their first name.

I would push back strongly on this requirement for universal marking, but if it were a requirement a universal base class would be needed.

[TomCarlson-NTAC]

This harkens back to earlier (as in a decade ago) discussions about the 0 to unbounded cardinality of everything. The discussion ended up at while certainly there are things in NIEM where a 0 to unbounded cardinality doesn't apply, no one wanted to go to the considerable effort to detail all those cases, only to then find out that there was a use case for wider cardinality where it may have been narrowed. Instead, NIEM left the cardinality wide open and let the IEPD developers determine it for their individual use cases.

I feel like it's basically the same thing here. Going through and trying to determine the appropriate level of ISM marking granularity for every object in NIEM would be a huge undertaking. And as soon as NIEM decided that you could mark a GPS track but not individual coordinates, someone is going to come by wanting to mark a portion of a track. Instead of making folks extend NIEM to then add that, it's easier to just make it available to everything.

[iamdrscott]

I figured out a better way to do what I want, without putting the structures namespace into CMF files, and without introducing a new nc:ObjectType base class. So this is OBE.