V3 Publishing ConCall Minutes 20130329

Return to Publishing Committee

Minutes of Recent Publishing Conference Calls

Present

Beeler, Kreisler, Nelson, Loyd

Agenda

Review Minutes of March 22, 2013

Approved

Lost data Types in Visio Graphics

Discussed an e-mail from Smithies dated today or yesterday. Reflects TWO bugs on Gforge (2238 and 2137). Kreisler had posted a software fix for the latter. We agreed this needs fixing before NE2013 processing.

RIM-immutable Attributes Not Correct in Schema

From Dale nelson – In performing HQMF R2 ballot reconcilliation, we believe there is a discrepency between the current schema generation output and the RIM/ITS specifications. The Act.isCriterionInd attribute is marked as "immutable", and the relevant sections of the XML ITS R1 and R2 specifications state that "immutable" attributes are represented by XML attributes on the parent class rather then elements.

We have noticed that Act.isCriterionInd currently generates element content in the schemas. (See POQM_MT000001UV, for example).

The current May 2013 ballot contains this problem.

Quick review showed it to be a "tooling" problem in that the Schema generator is not recognizing the RIM property while it processes RIM-derived models.

SUBSEQUENT to the meeting - Was determined this results from a Generator process that uses a hard-coded list of RIM immutable attributes that had not been updated for recent changes. A "q&d" fix to this was created, tested, and sent to Nelson. We will also consider a major patch to the Ballot for this.

Representation and management of "blockedContextConduction..." attributes in the RIM

This is being forwarded to MnM for management. The problem is that:

1. These attributes are immutable and therefore present as schema attributes
2. They are supposed to hold a one or more codes (either ActRelationshipType or ParticpationType) that they block.
3. The maximum set of such codes is all those codes in those code systems that are - conductible="true" - or children thereof.
4. We have no good way to express a constraint on this.

Considerations:

• We might create a value set that is all of the conductible codes plus all of their children with transitive closure. This would be the appropriate constraint at the RIM level. and could be bound to a Domain universally.
• We have provided for design-time constraint to a specific list of codes, but what are the restrictions on a design derived from that design??
  • Expectation is that they could reduce the total set of codes that can be blocked, but not increase them. However this is no-where articulated.
• If there is an established set, how do we represent this in schema??? (If at all).

Beeler will probably lodge a Neg against the RIM for this since it is an unusable construct until we clean it up.