Configuration management in NIEM 6: CMF and XSD

[iamdrscott]

Configuration management in NIEM 6: CMF and XSD files

The main target of configuration management in NIEM version 1 through 5 is the XML schema document. A NIEM domain publishes its model as one or more reference schema documents, each providing declarations and definitions of the components in its target namespace. The NBAC does the same for the NIEM core model. A message designer likewise publishes extension schema documents as part of his message specification. These schema documents are the authoritative source for their corresponding namespaces.

(It bothers me a little that there is nothing in the schema document to say it is the authoritative source. Conformance target assertions are not quite the same thing. Oh well, if it matters people can write something in the schema xs:documentation, I guess.)

CMF and XSD are interchangeable In NIEM 6, and so we need a CMF equivalent to the authoritative XSD document. You won't get that by dropping, say, domains/cyber.xsd into the current CMFTool. That tool today produces complete model CMF file. What we need is a namespace CMF file — one that defines components in just one namespace, and merely references the components in all the others. And that means a namespace CMF file can't use REFs for components in the other namespaces. So instead of the ref in line 7 below:

01 <Class structures:id="cyber.CompromisedCommunicationType">
02   <Name>CompromisedCommunicationType</Name>
03   <Namespace structures:ref="cyber" xsi:nil="true"/>
04   <DefinitionText>A data type for a compromised communication between systems</DefinitionText>
05   <AugmentableIndicator>true</AugmentableIndicator>
06   <HasProperty>
07     <Property structures:ref="nc.StartDate" xsi:nil="true"/>
08     <MinOccursQuantity>0</MinOccursQuantity>
09     <MaxOccursQuantity>unbounded</MaxOccursQuantity>
10   </HasProperty>

The authoritative CMF file for the cyber domain (cyber.cmf) must have the uri in line 8 below:

06   <HasProperty>
07     <Property 
08       structures:uri="https://docs.oasis-open.org/niemopen/ns/model/niem-core/6.0/StartDate" 
09       xsi:nil="true"/>

The cyber.cmf file won't contain objects for any of the components in other namespaces. It will just point to them with uri attributes.

All this requires some new capabilities in CMFTool:

1. Write a single namespace CMF file from a model
2. Write a complete set of namespace CMF files for a model
3. Combine a set of CMF files into a model, checking for consistency and completeness

[cdmgtri]

I've been thinking of something similar to deal with subsets. We are replacing the old SSGT wantlists with CMF files. I'd like to make it so that tools do not need to capture the full set of information for namespaces and components that we already track in the database.

If a subset tool can fill in the minimal set of info needed, it can be run through the API to fill in the details and get the full CMF file for any version of a model stored in the database.

CMF minimal set

• Model
• Version
• Property qnames
• Type qnames
• Properties contained within a type
• Cardinality if more restrictive than the default
• Code values if subsetting a code set and code values are unique
• Code values and definitions if subsetting a code set and code values are not unique
• Nillable value if not default
• Others?

QNames

Also, instead of using structures:id and structures:ref (qnames are not valid values and have to be tweaked) or structures:uri (cumbersome to read or write by hand), wasn't there a plan to use qnames instead?

[iamdrscott]

Easier, I think, to list the properties you don't need in a wantlist. It might be simpler to just write the complete CMF for the subset you want. I've been thinking less about wantlists, more about a language for edit actions. But I don't have anything worth talking about.

We did have a structures:qname at one point, but -- heh, heh -- you removed it from PSD01 :-). I mainly wanted structures:qname for the low-bandwidth world, but it turns out that QNames are less efficient than URIs in an EXI serialization, so bang! goes that excuse, and now I'm not convinced the juice is worth the squeeze. But I'll do what the NTAC decides.

[cdmgtri]

I'd definitely like to avoid subset tools having to explicitly document 10,000 vehicle make codes in CMF if a user wants the full code set. We can fill in that kind of information for them, plus dependencies, definitions, etc.. The other fields needed for a minimal CMF for subsets are probably out of scope for this topic, but being able to refer to existing properties and types that are defined elsewhere without having to redefine them should be useful for both CMF files for single namespaces and for subsets.

I do like the idea of a cmf:qname. Just hadn't seen a good reason why it would be common enough to put it into structures instead. There's the PS 02 if it really is needed.

[iamdrscott]

D'accord. The things we need for single-namespace CMF files are also helpful for wantlists. I'm guessing the same CMF model/schema will work for both. Writing the first alpha for CMF 1.0 (to bring in everything from the metamodel) is next on my list, and then we can be sure, or make it so.

You can't really use cmf:qname instead of structures:qname. The RDF will be broken. Here's the difference:

<cmf:Property structures:qname="nc:Person"/>    |  _:n0 cmf:Property nc:Person .
<cmf:Property cmf:qname="nc:Person"/>           |  _:n0 cmf:Property "nc:Person" .

The point of structures:qname is that it's a shorthand for structures:uri. So, in the first case, you get an edge in a graph, one that can be interpreted by any software that speaks RDF, just as you do with @ref or @uri. But cmf:qname is just another attribute property; no architecture magic for it. So, in the second case, you get a string that must be interpreted by an application that understands CMF. The element says it's a Property object, but it's not; it's a string your application can maybe use to look up a Property object. And now the RDF for the CMF model is broken. We were going to say:

cmf:Property rdfs:range cmf:PropertyType .

but now we can't say anything useful, because sheesh! it could be a Property object, it could be a string satisfying QName syntax; danged if I'm bothering to write the owl:unionOf for that. More honest would be to do this instead:

<cmf:PropertyQName>nc:Person</cmf:PropertyQName>

and have a PropertyAbstract and substitutions. For a horrible minute last year I thought I was going to have to do exactly that, but then I realized I could just use structures:uri instead. I really liked structures:qname when I thought it made for smaller messages in EXI. I've pretty much talked myself out of it now that I've proved it doesn't. But I could be persuaded to change my mind again if the long URI strings are too ugly in CMF files that aren't complete models.