Accredited Standards Committee
X3, INFORMATION PROCESSING SYSTEMS
Project:
Reply to: Jeff Sutherland IDX Systems Corporation 116 Huntington Avenue Boston, MA 02116 617-266-0001 x2920 617-721-1226 FAX jeff.sutherland@idx.com http://www.tiac.net/users/jsuth1.0 FIXED EVENTS - none
2.0 PRELIMINARY AND ADMINISTRATIVE MATTERS
2.1 Establish scribe - Jeff Sutherland
2.2 Attendance and introductions
Glenn Hollowell, Texas Instruments, Chair <glenn@ti.com>
Joaquin Miller, MCI SHL Systemhouse, Vice-Chair <miller@shl.com>
Jeff Sutherland, IDX Systems Corp., Secretary <jeff.sutherland@idx.com>
Hiam Kilov, IBM TJ Watson Research Center <kilov@watson.ibm.com>
Frank Manola, Object Services and Consulting, Inc. <fmanola@objs.com>
William Burg, University of Texas, wdburg@lonestar.utsa.edu
2.3 Review the proposed work items
2.4 Administrative
| Date | Meeting | Place |
| 10-11 Mar 97 | X3H7 | Austin w/X3J21, OMG BODTF |
| 23-24 Jun 97 | X3H7 | Montreal w/X3J21, OMG BODTF |
| 17-18 Nov 97 | X3H7 | Princeton w/X3J21, OMG BODTF |
2.5 Special topics
2.6 X3H7 Technical Report
2.7 Review/discuss submitted documents
2.8 Define and schedule work to be done in plenary and breakout groups
Motion: That delegates instructions
as modified be accepted. (Glenn Hollowell, Haim Kilov second, 6 for, 0
against, no abstentions)
Motion: Approve U.S. contribution document X3H7-96-20 and the following integrated documents:
X3H7-96-07R2 (attachment)
X3H7-96-11 (attachment)
X3H7-96-14
X3H7-96-15
X3H7-96-16
X3H7-96-17
X3H7-96-18
and that the editor be instructed to combine these document into one document.
(William Burg, Glenn Hollowell second, 6 for, 0 against, no abstentions)
The integrated document will be emailed in RTF format to the committee
within the next two days by Joaquin Miller.
Motion: That minutes of last meeting X3H7-96-18 be accepted as
amended. (Glenn Hollowell, Haim Kilov second, 6 for, 0 against, no abstentions)
RESPONSIBILITY PRIMARY BACKUP
Chair Glenn Hollowell
Vice-Chair Joaquin Miller
Project Editor (Object Models) Frank Manola
Project Editor (Enterprise Viewpoint) Joaquin Miller
Vocabulary Rep Joaquin Miller Haim Kilov
Secretary Jeff Sutherland
OMC/SC21 TAG Rep
Membership Status Joaquin Miller
Document Log/Librarian Jeff Sutherland
Document Distribution Jeff Sutherland
| X3H7-96-01 | Some materials on relationships for the enterprise viewpoint of RM-ODP | Haim Kilov | 5 Jan 96 |
| X3H7-96-02 | Proposed New Work Item: RM-ODP Enterprise Language and Application Architecture | ISO/IEC JTC1/SC21 N 10387 Rev 1 | 23 May 96 |
| X3H7-96-03 | Minutes of Meeting, Washington, D.C. | Joaquin Miller | 7 Jun 96 |
| X3H7-96-04 | RFP-1 "Business Objects" BOF Evaluation Scenario | Oliver Sims, Peter Eeles.
OMG BODTF |
6 Sep 96 |
| X3H7-96-05 | Business Object Facility RFP Response Evaluation Guidelines | Tom Digre (Ed.) OMG BODTF | 7 Sep 96 |
| X3H7-96-06 | U.S. ballot comments on SC21 N10387 - New Work Item Proposal for Enterprise Language | Tom Rutt
X3T3-96-096 |
16 Sep 96 |
| X3H7-96-07R2 | Business rules for the Enterprise Viewpoint of RM-ODP | Haim Kilov | 7 Dec 96 |
| X3H7-96-08 | Minutes of Meeting, Hyannis, MA | Jeff Sutherland | 17 Sep 96 |
| X3H7-96-09 | Starting Point for Enterprise Work | UK draft | 6 Dec 96 |
| X3H7-96-10 | SC Enterprise Framework Process, Version 1 | Sematech | 27 Nov 96 |
| X3H7-96-11 | Texas Instruments Enterprise Framework Overview | Sematech | 6 Dec 96 |
| X3H7-96-12 | Understanding the semantics of (collective) behavior: the ISO General Relationship Model. ECOOP'95 Workshop 6: Use of Object-Oriented Technology for Network Design and Management. Arhus, Denmark. | Haim Kilov | 8 Aug 96 |
| X3H7-96-13 | X3H7 Technical Committee (Object Information Management) Object Model Technical Report | Frank Manola (Ed.) | Dec 96 |
| X3H7-96-14 | Contribution to U.S. Position at Canberra | Haim Kilov | 7 Dec 96 |
| X3H7-96-15 | Contribution to U.S. Position at Canberra | Frank Manola | 7 Dec 96 |
| X3H7-96-16 | Contribution to U.S. Position at Canberra | Glenn Hollowell | 7 Dec 96 |
| X3H7-96-17 | Contribution to U.S. Position at Canberra | William Burg | 7 Dec 96 |
| X3H7-96-18 | Contribution to U.S. Position at Canberra | Jeff Sutherland | 7 Dec 96 |
| X3H7-96-19 | [Proposed] Delegates instructions. RM-ODP enterprise language, January 1997 meeting of SC21/WG7. U.S. proprietary document. | Joaquin Miller | 6 Dec 96 |
| X3H7-96-20 | US contribution to WG7 meeting on Enterprise Viewpoint Language | Joaquin Miller | 6 Dec 96 |
11:00 Meeting Convened
Glenn Hollowell announced his resignation as Chair of X3H7. Joaquin
Miller becomes Acting Chair on the effective date of his resignation. The
Chair will need to be refilled through a ballot process. The Vice Chair
can be filled informally by the Committee with no official X3 ballot.
Volunteers for Chair may fill out an X3 form. The Chair must have written
support from his/her company for a guaranteed period of 3 years.
Joaquin Miller indicated his intent to volunteer.
William Berg proposed that we enable Net meetings via PC video conference.
Also Lotus Notes allows online tracking of written comments. This is currently
being implemented at Sematec.
X3 is reducing their meetings to a maximum of 3 meetings a year and
other meetings to be electronic.
See www.objs.com for Internet tools survey (Frank Manola). Unless you
are on the Mbone, the Internet does not guarantee any bandwidth.
Glenn Hollowell pointed out that colocation with OMG is very importance
and significantly enhances visibility and participation. There was general
agreement that this is a good policy to continue.
Frank Manola passed out the December 1996 X3H7 Technical Committee Object
Model Technical Report (Dec 96) which outlines future X3H7 activities (p.
17). Section 4.1.3 Enterprise Modeling is the major piece of work.
We need to decide on process for developing an Enterprise Modeling standard
because it is now a formal international standards project (Glenn Hollowell).
We need written submissions to work from. They do not need to be formal
change proposals as in X3H2 but they do need to be written and distributed.
People need to write down their ideas even if they are in the formative
stage. We also need a method for distribution (Frank Manola).
MCI will set up a Web site (Joaquin). They may also support conference
calls if IBM supports some. IBM has not had a lot of success with conference
calls in Europe because written submissions are the key (Haim). TI has
had success with conference calls with someone taking minutes and reporting
them out immediately (Glenn).
The important of conference calls is meeting to pull some things together
and make decisions (Frank).
Anything we submit international must be in writing a month ahead of
the meeting. This will enforce some basic discipline (Joaquin). Ultimately
the X3H2 discipline will need to be imposed for the international work
(Frank).
Agenda for today:
How do we develop material for Canberra?
What would we like to do with Frank's contribution? X3H2 votes on the
Technical Report next week and will make comments. X3H7 could take the
document home and comment back in writing along with X3H2.
Action/Decisions:
After this meeting, there will not be work to be done until the later
part of January. Joaquin will come back with first international draft.
There is already schedule an X3H7 meeting in Austin in March. We need a
process between now and then (Glenn).
Joaquin - I would like deadlines each month and circulate an increment of work with conference calls as necessary.
By the end of the year, the Committee must review the introductory material
in the Technical Report and comment back to Frank Manola by 31 December
1996. Frank, as Editor, is the arbiter of inclusion of comments.
Approval of rewritten SQL Features Matrix: Email vote
Reapproval of Technical Report for submission to OMC: Email vote
At the March OMC meeeting, Joaquin will present the updated report.
The material available is not sufficient for an initial draft for the
Canberra meeting (Haim). The UK Note has some good material. The metamodel
show links as relationships without sufficient explanation. It needs further
work. Certain concepts are already defined in RM-ODP and this definition
needs to be explicitly stated.
The intended disposition of the UK document is for Joaquin to use it
as a discussion item in Canberra (Glenn). The discussion needs to go on
at two levels (Frank). What set of different things does a specific concept
fail to distinguish? What are we talking about at a high level. What do
we want to describe? This has been a difficulty in understanding the RM-ODP
documents. Unless you understand the history of the problems RM-ODP was
trying to deal with, it is hard to understand the motivation for pieces
of the document.
We need to get a clear outline of what we are going to try to specify
before we descend into detailed analysis of concepts.
Section 2.3.1 provides a good start at beginning to define an intuitive
overview of the enterprise viewpoint (Haim).
Are we trying to describe the entire enterprise, its parts and relationships,
or only the part of the enterprise that is an information system. What
is an "ODP System?" (Frank)
The specification should start with a total description of the enterprise,
manual and automated. The next level down should describe the automated
piece (Bill).
There is an international Conceptual Schema group that is trying to
describe the larger world. The work item that we have is directed toward
an information system (Glenn). We need to model the information system
and its environment (Joaquin). We need to go one level higher than our
specification to set a context (Bill).
The enterprise viewpoint is a collection of viewpoints on the enterprise
(regulatory viewpoint, business needs, etc.) Sometimes they are consistent,
sometimes they are not consistent (Haim).
Are there relationships in the enterprise external to the "enterprise
system" that we do not have to describe in the enterprise viewpoint
(Frank). We need to focus on a specific system (Joaquin).
The enterprise system can be the business object schema or it could
be viewed as the requirements that reflect what the information system
is supposed to do, maybe obligations of the corporation to external parties
(these may be direct as the printer fails and the paycheck will not be
printed, or more indirect as what obligations does the corporation have
to stake holders). What is the relationship between the operation of the
system and the obligations to external parties. Does the failure of a piece
of the system violate the law? Does this imply that you need a conceptual
model of the enterprise that contains the information system (Frank)?
Going back to the RM-ODP viewpoints, the five viewpoints provide information
for specification of an ODP system. I think we need to agree that this
is an information system. "A viewpoint on an ODP system and its environment
that focuses on the purpose, scope,and policies" of an information
system (Joaquin).
"An ODP system is a system that conforms to the requirements of
ODP standards." In 6.5, the statement is made that the word system
can refer to an information system but can also be more general.
Business specification
design
System specification
design
Software system specification
design
If there are parts of the system which will never be automated (for
the next two years) then they may be included in the enterprise viewpoint
but only at a high level of abstraction (Haim).
The criteria for underwriting a system may not be in the system, but
the way a decision will be made is conveyed to the system. The way it is
conveyed to the system will establish a connection (Frank).
Use case are designed to describe this problem (Jeff).
I have sat through three attempts to conceptually describe GTE. All
failed. I don't want to include in the model (in principle) those things
that cannot be fully described (the whole business) (Frank).
If we focus on the systems specification and lower, we can leave it
optional as to extent of specification of the business as a whole (Frank).
If I want tracability from the system specification to the business
specification, then the business must be described to the extent necessary
(Frank).
I think this gets back to use cases which we are trying to focus on
at IDX. Who or what are the entities or agents that interact with the system.
What is the nature of that interaction and how does the system support
that set of interactions. Anything external to this is not relevant to
the system (Jeff).
A discussion of the Community section of the UK documentpart 2.1 ensued.
"Community: A configuration of objects formed to meet the objective.
The objective is expressed as a contract which specifies how the objective
can be met."
The word objective is not properly defined (Hiam). The contract specifies
enough conditions (a predicate) to know whether the objective is attained
or not (Frank). Or it is looser than that (Joaquin). We think this contract
will help us make money. We don't know for sure if meeting the contract
will meet the objective, but in our best subjective judgement it will.
Process question: How are we going to get to conclusion here?
I would like to accept or not, concepts in the UK document where they
quote from RM-ODP (Joaquin. We need a vote on a document by the end of
the meeting on a document which is the U.S. position for Canberra. Next
week this document must be on the X3T3 exploder for a vote. No one needs
to consider anything we say unless it is a US position.
We need a US position on a starting point for the Enterprise standard.
We need to write down instructions for Joaquin to follow. X3T3 suggested
that we take the position that nothing go into the document that precludes
work that we intend to undertake later. We can focus on one part of a document
and defer discussion on separate issues for future documents.
Instruction to delegate:
The current submissions are initial contributions that provide some
material for possible definitions. We are not ready yet to precisely formulate
specific definitions.
Do we want to draft a proposed baseline document? Do we want to solicit
multiple proposals for base documents and then synthesize a first draft?
Whatever comes out of the Canberra meeting will be the first base document
(Glenn).
The base document should contain a rationale part and a definitional
part. Merging of definitions is too early. We only have the UK position
and not the Australia, French, German, etc.
Assignment:
This evening, each person will write a one page contribution for a US
position document in Canberra. Joaquin can synthesize contributions and
send it back out to the committment via email for a vote.
Each contribution was reviewed. See X3H7-96-14 through 96-18
Motion: That delegates instructions as modified be accepted.
(Glenn Hollowell, Haim Kilov second, 6 for, 0 against, no abstentions)
Motion: Approve U.S. contribution document X3H7-96-20 and the following integrated documents:
X3H7-96-07R2 (attachment)
X3H7-96-11 (attachment)
X3H7-96-14
X3H7-96-15
X3H7-96-16
X3H7-96-17
X3H7-96-18
and that the editor be instructed to combine these document into one document.
(William Burg, Glenn Hollowell second, 6 for, 0 against, no abstentions)
The integrated document will be emailed in RTF format to the committee
within the next two days by Joaquin Miller.
Motion: That minutes of last meeting X3H7-96-18 be accepted as
amended. (Glenn Hollowell, Haim Kilov second, 6 for, 0 against, no abstentions)
Glenn Hollowell can be reached at glenn@hollowell.org.
An object in a composition is specified as a sender and receiver of
messages. In RM-ODP terms, a group of three related objects is a community.
Whether one object in the community or the community itself accepts a message
is a computational viewpoint question.
The community is a composite object. An operation can be applied to
the composite. The pre- and post-conditions are specified to apply at an
appropriate level of abstraction (a specific object or the whole community).
If you define a type of composition and several component types, the
composite types are distinguishable from the component types and the component
types are distinguishable from each other. You will see that these are
roles because when you instantiate a component type (Haim).
Actions happen between the composite and each component and between
components. When you consider the whole composite as one object, you have
a collection of actions for the composite and some of the component actions
become invisible.
The issue is that a system must be specified as a nested set of hierarchical
components. There is no way to do this in UML. Rumbaugh and Odell are in
disagreement as to how this is handled.
Protocol is usually used to mean interface, plus number of participants,
plus ordering of interactions (Frank).
Generalized Relationship Model (GRM) specifies this properly (Haim).
Running components are an instance based phenomenon.
Motion: That the Committee authorize Glenn Hollowell in his resignation
to X3 to state that this Committee unanimously endorses Joaquin Miller
to be elevated to the position of Chair of X3H7 (Glenn Hollowell, Haim
Kilov second, passed unanimously).
Motion: That X3H7 requests the Acting Chair, Joaquin Miller, to solicit
candidates for the open Vice Chair position. (Jeff Sutherland, Haim Kilov
second, passed unanimously)