Issue 1502:  MOF RTF Issue: Behavior of M1 level interfaces vagualy specified (mof-rtf)
Source:  (, )
Nature:  Revision
Severity:  Significant
Summary: Summary: The current MOF spec is too vague in its specification
 of the behavior of the M1-level interfaces, both in the Reflective
 and IDL mapping sections.  It is also rather disorganised with the
 text structure of Sections 5 through 7 reflecting authorship rather 
 than relatedness of content.  If left uncorrected, these problems 
 are likely to lead to divergent implementations and interoperability 
 problems.

Resolution: resolved and closed
Revised Text: 
Actions taken:
June 4, 1998: received issue
July 23, 1999: closed issue
Discussion: 
Here are some examples:
• As described in 5.3.3, some operations can potentially cause more than one viola-tion
of structural constraints. For example, if you have an "attribute set of [0..2]
char foo" whose value is "['a', 'b']" and you invoke "add_foo('a')". The spec does
not say if an implementation has to return BOTH "overflow" and "duplicate" in the
'violations' parameter of StructuralError.
• In section 5.5.3 it was intended that an implemention be allowed to return a nil ob-ject
reference as the 'element_designator' in a StructuralException if no M2 objects
are available. [This is in line with "Reflective::RefBaseObject::meta_object"]
• Sections 5.2 and 5.4 should spell out precisely which exceptions (and for Struc-turalError,
violation_kinds) should be raised under which circumstances.
• The operations whose signatures are defined by the IDL mappings in Section 7
should be more fully described. They should be cross referenced to the correspond-ing
Reflective operations in 5.2 / 5.4 and semantic specs in Section 6.
• We should reorganize the text so that related text in Sections 5 and 6 are in the same
place. For example, details of semantics of M1 level operations are now spread
through 5.2, 5.4 and 6.2.
Status: no progress. Substantial editorial work is required
Washington : Good Suggestion, Prioritize the editorial fixes after all significant technical
issues (eg:IDL generationa are resolved)
Implementation: Specific and reflective operation specifications completely rewritten
in much greater detail. The new specs document exceptional condi-tions
for each operation, and define the specific / reflective ana-logues.
Done. [SC]
Implementation: (Some section introductions need rewriting - editorial.) [SC]
End of Annotations:=====
Return-Path: <crawley@dstc.edu.au>
To: mof-rtf@omg.org, issues@omg.org
Subject: MOF-RTF Issue: 
Errors-to: request@omg.org
Priority: bulk
Date: Thu, 04 Jun 1998 18:03:43 +1000
From: Stephen Crawley <crawley@dstc.edu.au>


Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au)
Nature: Editorial
Severity: Major
Summary: The current MOF spec is too vague in its specification
of the behavior of the M1-level interfaces, both in the Reflective
and IDL mapping sections.  It is also rather disorganised with the
text structure of Sections 5 through 7 reflecting authorship rather 
than relatedness of content.  If left uncorrected, these problems 
are likely to lead to divergent implementations and interoperability 
problems.

Additional Text:

Here are some examples:

1)  As described in 5.3.3, some operations can potentially cause
    more than one violation of structural constraints.   For example,
    if you have an "attribute set of [0..2] char foo" whose value is 
    "['a', 'b']" and you invoke "add_foo('a')".  The spec does not
    say if an implementation has to return BOTH "overflow" and 
    "duplicate" in the 'violations' parameter of StructuralError.

2)  In section 5.5.3 it was intended that an implemention be allowed
    to return a nil object reference as the 'element_designator'
    in a StructuralException if no M2 objects are available.  [This
    is in line with "Reflective::RefBaseObject::meta_object"]

3)  Sections 5.2 and 5.4 should spell out precisely which exceptions
    (and for StructuralError, violation_kinds) should be raised
    under which circumstances.

4)  The operations whose signatures are defined by the IDL mappings 
    in Section 7 should be more fully described.  They should be 
    cross referenced to the corresponding Reflective operations in 
    5.2 / 5.4 and semantic specs in Section 6.  

5)  We should reorganize the text so that related text in Sections 5 
    and 6 are in the same place.  For example, details of semantics
    of M1 level operations are now spread through 5.2, 5.4 and 6.2.