Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

ISO IEC TC JTC SC SC

VIEWS: 7 PAGES: 137

									ISO/IEC JTC1/SC 32 N 1081

Date : 2004-02-02


ISO/IEC


ISO/IEC JTC1/SC 32/WG 1 N 267
Secretariat : ANSI




Information Technology - Business Agreement Semantic Descriptive Techniques -
Part 2: Registration of Scenarios and their Components as Business Objects



                                                           Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without
notice and may not be referred to as an International Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they
are aware and to provide supporting documentation.
     Copyright notice
     This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
     under the applicable laws of the user’s country, neither this ISO draft nor any extract from it may be
     reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
     photocopying, recording or otherwise, without prior written permission being secured.

     Requests for permission to reproduce should be addressed to ISO at the address below or ISO’s member
     body in the country of the requester.

         Copyright Manager
         ISO Central Secretariat
         1 rue de Varembé
         1211 Geneva 20 Switzerland
         tel. + 41 22 749 0111
         fax + 41 22 734 1079
         internet: iso@iso.ch

     Reproduction may be subject to royalty payments or a licensing agreement.

     Violators may be prosecuted.




ii
                                                                                            ISO/IEC CD 15944-2 :2003



Project Editor Notes
                     nd
1. Although this 2        CD ballot document requires more work, SC32/WG1 deemed it advanced enough to go out for
a 2nd CD ballot.

This 15944 Part 2 expands on ISO/IEC 15944 Part 1 requirements for registration purposes in support of
interoperability and re-use. It therefore identifies and specifies requirements in addition to those stated in ISO/IEC
15944 Part 1. Some requirements have been identified but are not yet specified. There may be other additional
                                                                                                                     nd
requirements. The SC32/WG1 and 15944 Part 2 Project Editor recognizes this and welcomes contributions or 2
CD ballot comments on completion of this work.
            nd
During the 2 CD ballot period, the Project Editor is undertaking a quality control check to ensure that all the rules
and associated requirements for scoping Open-edi scenarios and specifying Open-edi scenarios and their
components are stated and supported in 15944 Part 2 for registration purposes. Contributions or ballot comments
                                                               nd
identifying such gaps between ISO/IEC 15944 Part 1 and this 2 CD for 15944 Part 2 are welcome.

2. It is understood that the definitions in this Part 2 (and associated terms) will be harmonized with resolution of
comments resulting from CD ballot resolutions on CD ballot documents for Parts 3, 4 & 5 of ISO/IEC 15944.

3. It is also understood that prior to this Part 2 going to FCD (or FDIS) ballot document stage, the Template(s)
which it contains will be harmonised with and support registration requirements of Open-edi scenarios and their
components of Parts 3, 4 & 5 of ISO/IEC 15944

4. At the FDC ballot document preparation stage, that any definition (and associated term) listed in Clause 3 which
is not utilized in the text for Clause 5+ in this standard will be removed.
                                            nd
5. It is assumed that as part of the 2           Ballot resolution and the FCD preparation phase, additional “rules” will be
inserted as required.

6. For the preparation of the FCD ballot , all the definitions and associated terms will be presented as a single and
complete set.

7. This Part 2 captures the registration requirements arising from Part 1, 3, 4 and 5 of the multipart ISO/IEC 15944
standard. In ISO/IEC 15944-1, the definitions in Clause 3 were repeated in Clauses 5+, i.e. in that Clause or sub-
clause where they were introduced. Since this Part 2 will use definitions from all the other Parts as well as its own,
it is recommended that text containing definitions in Clauses 5+ be deleted and appear in Clause 3 (as well as in
their English/French language equivalents inAnnex A).
                                       nd
8. It is anticipated that during the 2 CD ballot on this document, that CD ballot documents for Parts 3, 4 and 5 will
also be issued. Consequently, it will be beneficial for all parties concerned that (1) in the review of the CD
documents for Parts 3, 4 and 5 particular attention be paid in identifying any additional registration requirements;
and (2) that these be incorporated in the FCD document for Part 2.




                                                                                                                          iii
Contents                                                                                                                                                          Page

0        Introduction ................................................................................................................................................... vi
0.1      Purpose and overvie-w ................................................................................................................................ vi
0.2      Use of « Person », « person », and « party » in the context of business transactions and
         commitment exchange ................................................................................................................................ vii
0.3      Organization and description of the document ........................................................................................ vii
1        Scope .............................................................................................................................................................. 1
2        Normative references .................................................................................................................................... 2
3        Terms and definitions ................................................................................................................................... 2
4        Symbols and abbreviated terms ................................................................................................................ 17
5        Open-edi registration requirements .......................................................................................................... 17
5.1      Reusability .................................................................................................................................................... 18
5.2      Multilingualism ............................................................................................................................................. 18
6        Principles of registration ............................................................................................................................ 20
6.1      Federation of registration authorities ........................................................................................................ 20
6.2      Identification ................................................................................................................................................ 20
6.3      Qualification of OeRAs/OeROs .................................................................................................................. 20
6.4      Registry operation ....................................................................................................................................... 20
6.5      Registration information ............................................................................................................................. 21
6.6      OeDT requirements ..................................................................................................................................... 21
7        Administration attributes ............................................................................................................................ 21
7.1      Version information ..................................................................................................................................... 21
7.2      Replacement information............................................................................................................................ 22
7.3      Status information ....................................................................................................................................... 22
7.4      Change history ............................................................................................................................................. 22
7.5      Administration attribute list ........................................................................................................................ 22
8        Classification attributes .............................................................................................................................. 30
8.1      Trade models by type .................................................................................................................................. 30
8.2      Agents and third parties ............................................................................................................................. 30
8.3      Process planning ......................................................................................................................................... 31
8.4      Process identification ................................................................................................................................. 31
8.5      Process negotiation .................................................................................................................................... 31
8.6      Process actualization .................................................................................................................................. 32
8.7      Process post-actualization ......................................................................................................................... 32
8.8      Scenario management ................................................................................................................................ 32
9        Scenario specification attributes ............................................................................................................... 40
10       Registration authority and operations ...................................................................................................... 44
10.1     Registration authority for Open-edi scenarios ......................................................................................... 44
10.1.1   Appointment ................................................................................................................................................. 44
10.1.2   Qualification ................................................................................................................................................. 44
10.1.3   OeRO establishment ................................................................................................................................... 44
10.1.4   Duties ............................................................................................................................................................ 44
10.2     Applicant for registry .................................................................................................................................. 45
10.3     Application procedure for registration ...................................................................................................... 45



iv
                                                                                                                          ISO/IEC CD 15944-2 :2003



10.4       Operation of registration authority ............................................................................................................ 45
11         Maintenance of the register ........................................................................................................................ 46
11.1       Confidentiality of information held within the register ............................................................................ 46
11.2       Publication of the register .......................................................................................................................... 46
11.3       Dispute resolution ....................................................................................................................................... 46
11.4       Modification, deletion, obsolesce of the registered scenario ................................................................. 46
11.4.1     Modification and deletion ........................................................................................................................... 46
11.4.2     Obsolescence .............................................................................................................................................. 46
Annex A (normative): Consolidated list of terms and definitions with cultural adaptability : ISO English
      and ISO French lanuguage equivalency ................................................................................................. A-1
A.1   Introduction ................................................................................................................................................ A-2
A.2   ISO English and ISO French ..................................................................................................................... A-2
A.3   Cultural adaptability and quality control ................................................................................................. A-2
A.4   Organization of Annex A consolidated list is in matrix form ............................................................... A-3
A.5   Consolidated Annex A matrix .................................................................................................................. A-4
Annex B (normative): Registration matrix ........................................................................................................... B-1
Annex C (informative): Concept of classification attributes for scenarios ...................................................... C-1
Annex X (Normative) Classification Concepts .................................................................................................. X-1


INCLUDE LIST OF FIGURES IF THERE ARE ANY




                                                                                                                                                                       v
vi
 1   Foreword
 2   ISO (the International Organization for Standardization) and IEC (the International
 3   Electrotechnical Commission) form the specialized system for worldwide standardization.
 4   National bodies that are members of ISO or IEC participate in the development of International
 5   Standards through technical committees established by the respective organization to deal with
 6   particular fields of technical activity. ISO and IEC technical committees collaborate in fields of
 7   mutual interest. Other international organizations, governmental and non-governmental, in liaison
 8   with ISO and IEC, also take part in the work.

 9   International Standards are drafted in accordance with the rules given in the ISO/IEC Directives,
10   Part 2.

11   In the field of information technology, ISO and IEC have established a joint technical committee,
12   ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are
13   circulated to national bodies for voting. Publication as an International Standard requires approval
14   by at least 75 % of the national bodies casting a vote.

15   Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 15944 may
16   be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all
17   such patent rights.

18   International Standard ISO/IEC 15944-2 was prepared by Joint Technical Committee
19   ISO/IEC JTC JTC1, Information Technology, Subcommittee SC 32, Data Management and
20   Interchange.

21   ISO/IEC 15944 consists of the following parts, under the general title Information Technology —
22   Business agreement semantic descriptive techniques:

23   Part 1: Operational aspects of Open-edi for implementation

24   Part 2: Registration of scenarios and their components as business objects

25   Part 3 : Open-edi description techniques

26   Part 4 : Business transaction scenarios – Accounting and economic ontology

27   Part 5: Identification and mapping of various categories of jurisdictional domains as external
28   constraints

29   This standard contains several annexes with Annexes A, B and C being normative and the
30   following Annexes being for information purposes only, i.e. D1, D1, E1, and E2.


31   0     Introduction

32   0.1    Purpose and overvierw

33   Project Editor’s Note



     vi
                                                                         ISO/IEC CD 15944-2 :2003



34   Here we will include general introductory material common to each part. It is likely that the sub-
35   clauses for Introduction will either be the same for all Parts or be unique to the part to which they
36   pertain.ISO/IEC 14462 Open-edi Reference Model1) section 4.1.2 states:

37   “Different user groups will generate Open-edi scenarios in accordance with the specification given
38   in the BOV related standards. Open-edi shall be specified in conformity to the BOV related
39   standards. Business communities can propose Open-edi scenarios as candidates for
40   standardization and registration into (an) Open-edi scenario repository (ies). Procedures to be
41   used for introducing new Open-edi scenarios in one or more repositories are specified in a BOV
42   related standard.”

43   This standard is the second part of a multi-part standard that supports the registration of
44   scenarios, scenario attributes and scenario components as "business objects". The objective of
45   this standard is the identification, registration, referencing and re-useability of common objects in
46   a business transaction. As stated in ISO/IEC 15944-1, re-useability of scenarios and scenario
47   components is an achievable objective because existing (global) business transactions, whether
48   conducted on a for-profit or not for profit basis, already consist of reusable components
49   unambiguously understood among participating parties. However, such existing "standard"
50   components have not yet been formally specified and registered. The purpose of this standard is
51   to fill this gap.

52   An open-edi scenario is expected to be generated among user groups in accordance with the
53   specification given in the ISO/IEC 15944-1, and to be submitted as a candidate for a new Open-
54   edi scenario for reuse in the open world. User groups or parties will have a need to reuse an
55   Open-edi scenario as a whole or some component, or to refer just for preliminary negotiation and
56   further reuse purpose.

57   Open-edi scenario types will have specific or generic characteristics with different granularity, so
58   that the registration scheme should meet those requirements.

59   Open-edi scenarios include the following components to be described using an Open-edi
60   Description Technique (OeDT)

61   -Scenario attribute

62   - Role

63   - Information Bundle (IB)

64   - Semantic Component (SC)

65   0.2     Use of « Person », « person », and « party » in the context of business
66         transactions and commitment exchange

67   INSERT COMMON TEXT HERE

68   0.3      Organization and description of the document

69   INSERT APPROPRIATE TEXT HERE

     1) ISO/IEC 14662 Information technology - Open-edi Reference Model/Technologies de l'information -
     Modèle de référence EDI-ouvert. The English and French versions of this ISO/IEC standard are publicly
     available. {See <http://www.jtc1.org>}



                                                                                                       vii
70




     viii
     ISO/IEC CD 15944-2 :2003



71




                                ix
                                                                             ISO/IEC CD 15944-2 :2003




72   Information Technology - Business Agreement Semantic
73   Descriptive Techniques - Part 2: Registration of Scenarios and
74   their Components as Business Objects



75   1   Scope
76   This Business Operational View (BOV) related standard addresses the requirements of
77   producing, updating and registering an Open-edi scenario as well as scenario components.

78   This standard provides requirements for

79           Open-edi scenario registration method and procedure

80           Information required to register Open-edi scenarios and scenario components

81           Role and operation of registration authority of Open-edi scenarios

82            Identification of scenario specification attributes as stated in all the parts of this multipart
83           standard

84

85   This international standard defines the procedures to be applied by qualified JTC1 Registration
86   Authority(ies) appointed by the ISO and IEC council to maintain a register(s) of Open-edi
87   scenarios and/or secnario components for the purpose of their reusability.

88




                                                                                                             1
89    2   Normative references
90    Project Editor’s Notes

91        1. Clause 2 will be updated prior to FCD ballot to contain the normative references
92           appropriate to definitions and terms utilzed from other standards.

93        2. Where definitions already exist in international standards, the standard is referenced. For
94           the purposes of the preparation of the FCD ballot document, the defintion will be inserted.

95    The following referenced documents are indispensable for the application of this document. For
96    dated references, only the edition cited applies. For undated references, the latest edition of the
97    referenced document (including any amendments) applies.

98    ISO/IEC 14662: 2004 Information Technology - Open-edi reference model

 99   IEC/ISO 15944-1: 2002 Information technology- Business agreement semantic descriptive
100   techniques Part 1: Business operational aspects of Open-edi for implementation

101   ISO/IEC 6523-1:1998 (E) Information Technology - Structure for the identification of organizations
102   and organization parts Part 1: Identification of organization identification schemes

103   ISO/IEC 6523-2:1998 (E) Information Technology - Structure for the identification of organizations
104   and organization parts Part 2: Registration of organizations identification schemes

105   ISO/IEC JTC1 Directives pertaining to registration authorities


106   3   Definitions
107   Project Editor’s Notes

108       1. The FCD ballot document will contain a single set of definitions. Further any definition
109          listed here for which there is no text in Clause 5+ in the FCD ballot document will be
110          removed.
                                                         nd
111       2. The set of definitions found here in the 2 CD ballot document will be harmonized with
112          those found in Parts 3,4 and 5 (for which CD ballot documents are currently being
113          issued).
                                    nd
114       3. It is noted that the 2 edition of ISO/IEC 14662 is currently out for FDIS ballot. It is
115          expected to pass and be adopted. The FCD ballot document for ISO/IEC 15944 Part 2
116          will contain the appropriate and updated references for the definitions below for which
117          ISO/IEC 14662 is the Nornative Reference.

118   For the purposes of this part of ISO/IEC 15944, the following terms and definitions apply.

119   3.1
120   address
121   a set of data elements that specifies a location to which a recorded information item(s), a
122   business object(s), a material object(s) and/or a person(s) can be sent to or received from




      2
                                                                          ISO/IEC CD 15944-2 :2003



123   3.2
124   administration attribute
125   a member of a set of attributes to uniquely identify an Open-edi scenario, a scenario atrribute,
126   role, information bundle, or semantic component and the relevant Person responsible for its
127   maintenance

128   NOTE: Administration attributes are used to specify information pertaining to version,
129   replacement, status, change history and association as appropriate for a scenario, scenario
130   attribute, role, information bundle, or semantic component.

131   3.3
132   applicant
133   a Person which requests the assignment of a register entry and entry label

134   NOTE: An applicant can be an individual, organization, or public administration

135   3.4
136   applicant name
137   The name of the applicant who applies to register a scenario or scenario component

138   3.5
139   application date
140   The date an applicant submits a scenario or scenario component for registration

141   3.6
142   application number
143   the identification number assigned by the OeRO to the application of registering a scenario or
144   scenario component

145   3.7
146   association name
147   Name of the association a registry entry has with other registry entries

148   3.8
149   author
150   the Person who created a scenario or scenario component

151   Note: Where the author is not the Source Authority for the constraints being modeled, this shall
152   be stated and the Source Authority identified and referenced.

153   3.9
154   business [ISO/IEC FDIS 14662:2003]
155

156   3.10
157   Business Operational View [ISO/ FDIS 14662:2003]
158

159   3.11
160   business transaction [ISO/IEC FDIS 14662:2003-]
161




                                                                                                     3
162   3.12
163   change date
164   the date when the scenario or scenario component modification was successfully registered
165   (Editorial Note : this is a placeholder to be revisited when the registration process is stable)

166   3.13
167   change description
168   Description of why and how the scenario or scenario component has been modified

169   Note : It is advised that such a change description be accompanied by the “original “ template
170   values utilized and a “ change template” indicating which of the “Decision Code(s)” have been
171   changed.

172   3.14
173   change type
174   Nature of the change, such as new scenario or scenario component, new version, modification,
175   status modification, replacement

176   3.15
177   classificaton attribute
178   a member of a set of attributes required to distinguish the functionality and adaptability of an Open-
179   edi scenario

180   NOTE Classification attributes are used to provide convenient keys for retrieval of scenarios to
181   the extent that they can be specified.

182   3.16
183   commitment [ISO/IEC 15944-1:2002]
184

185   3.17
186   constraint [ISO/IEC 15944-1:2002]
187

188   3.18
189   Contact
190   an instance of a role of a Person to whom a recorded information item(s), a material object(s), a
191   business object(s), and/or natural persons (as either individual(s), or organization Person(s) can
192   be sent to or received from in a specified context

193   NOTE 1 A Person here as a Contact can be an individual, an organization (or organization part
194   or organization Person).

195   NOTE 2 Contact is capitalized to distinguish it from the many ordinary uses of the word

196   3.19
197   cross-reference
198   identification and version of the scenario(s) or scenario component(s) that is (are) related to
199   this scenario or scenario component

200   3.20
201   electronic address
202   an address utilized in a recognized electronic addressing scheme, (e.g., telephone, telex, IP, etc.),
203   to which recorded information item(s) and/or business objects can be sent to or received from a
204   Contact



      4
                                                                          ISO/IEC CD 15944-2 :2003



205   3.21
206   entity [ISO/IEC 15944-1:2002]
207

208   3.22
209   entry label
210   the name information uniquely associated with the identification and resulting identifier of a
211   registered Open-edi scenario or sub component of scenario

212   3.23
213   expected user community
214   the relevant community, industry, country, etc., to which the scenario or scenario component
215   could be effectively applied

216   3.24
217   external constraint [ISO/IEC 15944-1:2002]
218

219   3.25
220   Decision Making Application (DMA) [ISO/IEC FDIS 14662:2003]
221

222   3.26
223   definition [ISO 1087-1:2000 (3.3.1)]
224

225   3.27
226   Electronic Data Interchange (EDI) [ISO/IEC FDIS 14662:2003]
227

228   3.28
229   Formal Description Technique (FDT) [ISO/IEC FDIS 14662:2003]
230

231   3.29
232   Functional Service View (FSV) [ISO/IEC FDIS 14662:2003]
233

234   3.30
235   identifier [ISO/IEC 15944-1
236

237   3.31
238   Information Bundle (IB) [ISO/IEC 14662:2003]
239

240   3.32
241   information technology system (IT system) [ISO/IEC FDIS 14662:2003]
242

243   3.33
244   inheritance
245   identification and version of the scenario or role that is a superclass to this scenario or role




                                                                                                         5
246   3.34
247   Intellectual Property Right (IPR)
                                                       nd
248   [insert and get definition from WIPO as part of 2 CD ballot resolution work]

249   3.35
250   internal constraint [ISO/IEC FDIS14662:2002, also 15944-1:2002]
251

252   3.36
253   International Standard Identifier
254   Identifier of the version of ISO/IEC 15944-2 upon which attributes are based

255   3.37
256   JTC 1 registration authority [JTC 1 procedure Standard]
257

258   location:

259   3.38   a place, either physical or electronic, that can be defined as an address.
260   name [ISO 1087:1990 (5.3.1.3)]
261

262   3.39
263   OeDT used
264   the formal description language and/or technique that is used to specify the scenario contents,
265   i.e., Open-edi Descriptive Technique (Refer to ISO/IEC 15944-3, Information Technology –
266   Business Agreement Semantic Descriptive Techniques Part 3: Open-edi description techniques

267   3.40
268   OeS language code
269   the ISO 639-2T language code for the natural language used for specifying the Open-edi
270   Scenario.

271   Note: Where the Open-edi scenario or scenario components pertains to an external constraint for
272   which the Source Authority is a jurisdictional domain , the language code may need to be
273   qualified by the country code (or other identifier) for that jurisdictional domain. (See further Annex
274   C in ISO/IEC 15944-5).

275   3.41
276   Open-edi Description Technique (OeDT) [ISO/IEC 14662:1997 (4.1.1)]
277

278   3.42
279   Open-edi Registration Authority (OeRA)
280   The body responsible for the Open-edi Registration Schema and for maintaining the register of
281   OeROs and for the issuance of OeRO identifiers.

282   3.43
283   Open-edi Registration Organization (OeRO)
284   A body qualified by the OeRA to assume the responsibility for the registration of scenario and
285   scenario components




      6
                                                                         ISO/IEC CD 15944-2 :2003



286   3.44
287   Open-edi Registration Schema [OeRS]
288   the formal definition of a set of rules governing the data fields for the specification of an entity
289   and the allowable contents and semantics of those fields, including the rules for the assignment
290   of identifiers

291   3.45
292   Open-edi registry entry
293   the information within a registry relating to a specific Open-edi scenario or component of
294   scenario including linkage information to a scenario content

295   3.46
296   organization [ISO/IEC 15944-1:2002]
297

298   3.47
299   Person [ISO/IEC 15944-1:2002]
300

301   3.48
302   persona [ISO/IEC 15944-1:2002]
303

304   3.49
305   physical address
306   an address that is used/recognized by a postal authority and/or courier service to deliver
307   information item(s), material object(s), or business object(s) to a Contact at either an actual
308   address or a pick-up point address, (e.g., P.O. Box, rural route, etc.)

309   3.50
310   process [ISO/IEC 15944-1:2002]
311

312   3.51
313   recorded information [ISO/IEC 15944-1:2002]
314

315   3.52
316   reference document
317   external document(s) containing relevant information about the modification to the scenario or
318   scenario component

319   3.53
320   registrar
321   the Person responsible who has entered the scenario or scenario component in the repository

322   3.54
323   registration
324   a rule-based process, explicitly stated, involving the use of one or more data elements, whose
325   value (or combination of values) are used to identify uniquely the results of assigning a registry
326   entry




                                                                                                        7
327   3.55
328   registration Contact e-mail address
329   a valid instance of an electronic address based on a X.400, X.500 and/or IP directory
330   schema/service

331   3.56
332   registration Contact facsimile number
333   the use of a specified telephone address designated for facsimile transmission purpose and
334   utilized by the Person to register a scenario or scenario component

335   3.57
336   registration Contact mailing address
337   the physical address utilized by a Person applying to register a scenario or scenario
338   component

339   3.58
340   registration Contact name
341   name of a Person who has the responsibility of Contact regarding the scenario registration and
342   inquiry of its registration

343   3.59
344   registration Contact telephone number
345   a specified telephone address utilized by the Person applying to register a scenario or scenario
346   component

347   3.60
348   registration name
349   The name that may be commonly used to refer to the identifier of a scenario or scenario
350   component in the relevant business community

351   3.61
352   related regulation
353   an applicant shall identify any regulation that may govern or restrict the application of a
354   scenario, scenario attribute, or scenario component

355   Note : if applicable, these shall be specified using the relevant scenario specification attributes

356   3.62
357   replacement date
358   date from which the replacement is effective

359   3.63
360   replacement description
361   for each stored pair of registry entries where one register entry replaces the other, reason for the
362   scenario or scenario component being replaced

363   3.64
364   repository location
365   the URI address of the scenario with the repository where the scenario or scenario component
366   is located

367   3.65
368   restriction
369   specific restrictions of an application community and/or objectives of a scenario




      8
                                                                               ISO/IEC CD 15944-2 :2003



370   3.66
371   role [ISO/IEC 14662: 2004 (4.1.2.1)]
372

373   3.67
374   scenaro attribute [ISO/IEC 1997 (4.1.2.3)]
375

376   3.68
377   scenario component
378   the three fundamental elements of a scenario, namely role, information bundle, semantic
379   component

380   3.69
381   scenario specification attribute
382   any attribute of a scenario, role, information bundle, and/or semantic component

383   3.70
384   Semantic Component (SC) [ISO/IEC 14662:1997 (4.1.2.2)]
385

386   3.71
387   registry entry status
388   state of the registry entry (i.e., draft, provisionally registered, registered, to be retired, retired, …)

389   3.72
390   registry entry status change reason
391   description of why the registry entry status has been changed

392   3.73
393   registry entry status change reference
394   external document(s) containing relevant information the registry entry status change

395   3.74
396   registry entry status comment
397   remark(s) about the registry entry status

398   3.75
399   registry entry status start date
400   date on which the registry entry status comes into effect

401   3.76
402   telephone address
403   a valid instance of an electronic address in a directory schema/service based on ITU Rec. E164,
404   i.e., a string or combination of decimal digits, symbols, and additional information which identifies
405   the specific termination point(s) of a connection in a public network(s) or, where applicable, in
406   interconnected private network(s)

407   [ITU-T Rec. E.164 (1997)]

408   3.77
409   unambiguous [ISO/IEC 15944-1:2002]
410




                                                                                                                   9
411   3.78
412   version number
413   The version number of a scenario or scenario component assigned by an Open-edi
414   Registration Organization ; default = 1.0

415   REVIEW THE FOLLOWING DEFINITIONS AND ASSOCIATED TERMS AND INCLUDE ANY
416   THAT ARE USED IN PART 2, HARMONIZE WITH PARTS 3, 4 & 5; ELIMINATE ALL OTHERS

417   Project Editor’s Note

418   The following terms and definitions are retained as a placeholder for their introduction through
419   text to be added to this standard. At such time that these terms are used in text accepted by SC
420   32/WG 1, they will be considered for inclusion as normative terms in Clause 3. Some such as IT-
421   interface, human-interface equivalent, coded domain, ID code, etc. were already used in Part 1
422   and/or this Part 2 but not yet defined. Perhaps this should be done in the text before the Part 2
423   template, i.e, tables (which are coded domains) are introduced)

424   coded domain

425   a domain for which (1) the boundaries are defined and explicitly stated as a rulebase of a Source
426   Authority; and, (2) each entity which qualifies as a member of that domain is identified through the
427   assignment of a unique ID code in accordance with the applicable Registration Schema.

428   NOTE 1 The rules governing the assignment of an ID code to members of a coded domain reside
429   with its Source Authority and forms part of the Coded Domain Registration Schema of the Source
430   Authority.

431   NOTE 2 Source Authorities which are jurisdictional domains are the primary source of coded
432   domains.

433   NOTE 3 A coded domain is a data set for which the content of the data element values are
434   predetermined and defined according to the rule base of its Source Authority and as such have
435   predefined semantics.

436   NOTE 4 Associated with a code in a coded domain can be:

437   -       one or more equivalent codes;

438   -       one or more equivalent representations especially those in the form of human interface
439           equivalent (linguistic) expressions.

440   NOTE 5 In a coded domain the rules for assignment and structuring of the ID codes must be
441   specified.

442   NOTE 6 Where an entity as member of a coded domain is allowed to have, i.e., assigned, more
443   than one ID code, i.e., as equivalent ID codes (possibly including names), one of these must be
444   specified as the pivot ID code.

445   NOTE 7 A coded domain in turn can consist of two or more coded domains, i.e., through the
446   application of the inheritance principle of object classes.

447   NOTE 8 A coded domain may contain ID code which pertain to predefined conditions other than
448   qualification of membership of entities in the coded domain. Further, the rules governing a coded
449   domain may or may not provide for user extensions.



      10
                                                                         ISO/IEC CD 15944-2 :2003



450   EXAMPLE Common examples include: (1) "0" (or "00", etc.) = Others, Not Known; (2) "9" or ("99",
451   etc.) = Not Applicable.

452   NOTE 9 In object methodology, entities which are members of a coded domain are referred to as
453   instances of a class.

454   NOTE 10 In UML modelling notation, an ID code is viewed as an instance of an object
455   class.composite identifier
456   an identifier (in a business transaction) functioning as a single unique identifier consisting of
457   one or more other identifiers, and/or one or more other data elements, whose interworking are
458   rule-based

459   NOTE 1 Most widely used composite identifiers consist of the combinations of:

460   -       the ID of the overall identification/numbering schema, (e.g., ISO/IEC 6532, ISO/IEC 7812,
461           ISO/IEC 7506, UPC/EAN, ITU-R E.164, etc.), which is often assumed;

462   -       the ID of the issuing organization (often based on a block numeric numbering schema);
463           and,

464   -       the ID of the entities forming part of members of the coded domain of each issuing
465   organization.

466   NOTE 2 Identifiers (in business transactions) are for the most part composite identifiers.

467   Project Editor’s Note

468   Do we need a Normative or Informative Annex on “composite identifiers” in Part 2 ? According to
469   Part 1 rules, most of the identifiers for scenario components are in fact “composite identifiers”

470   computational integrity
471   the expression of a standard in a form that ensures precise description of behaviour and semantics
472   in a manner that allows for automated processing to occur, and the managed evolution of such
473   standards in a way that enables dynamic introduction by the next generation of information
474   systems

475   NOTE Open-edi standards have been designed to be able to support computational integrity
476   requirements especially from a registration and re-use of business objects perspective.

477   Human Interface Equivalent (HIE)

478   a representation of the unambiguous and IT-enabled semantics of an IT interface equivalent (in a
479   business transaction), often the ID code of a coded domain (or a composite identifier), in a
480   formalized manner suitable for communication to and understanding by humans.

481   NOTE 1 Human interface equivalents can be linguistic or non-linguistic in nature but their semantics
482   remains the same although their representations may vary.

483   NOTE 2 In most cases there will be multiple human interface equivalent representations as required
484   to meet localization requirements, i.e. those of a linguistic nature, jurisdictional nature, and/or
485   sectorial nature.




                                                                                                       11
486   NOTE 3 Human interface equivalents include representations in various forms or formats, (e.g., in
487   addition to written text those of an audio, symbol (and icon) nature, glyphs, image, etc.)

488   [ISO/IEC 15944-5:200n (3.nnn)]

489   ID code

490   an identifier assigned by the Source Authority to a member of a coded domain. ID codes must be
491   unique within their Coded Domain Registration Schema.

492   NOTE 1 Associated with an ID code in a coded domain can be:

493   -         one or more equivalent codes;

494   -         one or more equivalent representations especially those in the form of human equivalent
495             (linguistic) expressions.

496   NOTE 2 Where an entity as a member of a coded domain is allowed to have more than one ID
497   code, i.e., as equivalent codes (possibly including names), one of these must be specified as the
498   pivot ID code.

499   EXAMPLE Common examples include: (1) the use of an ID code "0" (or "00", etc.), for "Other, Not
500   Known; (2) the use of an ID code "9" (or "99") for Not Applicable; (3) the pre-reservation of a series
501   or set of ID codes for use for "user extensions".

502   NOTE 3 A coded domain may contain ID codes pertaining to entities which are not members as
503   peer entities, i.e., have the same properties and behaviours, such as ID codes which pertain to
504   predefined conditions other than member entities. If this is the case, the rules governing such
505   exceptions must be predefined and explicitly stated.

506   NOTE 4 In UML modelling notation, an ID code is viewed as an instance of an object class.

507   [ISO/IEC 15944-5]IT-enablement
508   the transformation of a current standard utilized in business transactions, (e.g., coded domains
509   and associated tables), from a manual to computational perspective so as to be able to support
510   commitment exchange and computational integrity

511   IT-interface equivalent

512   a computer processable identification of the unambiguous semantics of a scenario, scenario
513   attribute and/or scenario component(s) pertaining to a commitment exchange in a business
514   transaction which supports computational integrity.

515   NOTE 1 IT interface equivalents have the properties of identifiers (in business transaction) and are
516   utilized to support semantic interoperability in commitment exchange.

517   NOTE 2 An IT interface equivalent at times is a composite identifier.

518   NOTE 3 An IT interface equivalent as a composite identifier can consist of the identifier of a coded
519   domain plus an ID Code of that coded domain.

520   NOTE 4 An IT interface equivalent may have associated with it one or more human interface
521   equivalents (HIEs).




      12
                                                                                    ISO/IEC CD 15944-2 :2003



522   NOTE 5 An IT Interface Value is independent of its encoding in programming languages or APIs.

523   [ISO/IEC 15944-2:200n (3.nnn)]jurisdictional domain

524   a jurisdiction, recognized in law as a distinct legal and/or regulatory framework, which is a source of
525   external constraints on Persons, their behaviour and the making of commitments among
526   Persons including any aspect of a business transaction.

527   NOTE 1 The pivot jurisdictional domain is a United Nations (UN) recognized member state. From a
528   legal and sovereignty perspective they are considered "peer" entities. Each UN member state,
529   (a.k.a. country) may have sub-administrative divisions as recognized jurisdictional domains, (e.g.,
530   provinces, territories, cantons, länder, etc.), as decided by that UN member state.

531   NOTE 2 Jurisdictional domains can combine to form new jurisdictional domains, (e.g., through
532   bilateral, multilateral and/or international agreements).

533   EXAMPLE Included here, for example, are the European Union (EU), NAFTA, WTO, WCO, ICAO,
534   WHO, Red Cross, the ISO, the IEC, the ITU, etc.

535   NOTE 3 Several levels and categories of jurisdictional domains may exist within a jurisdictional
536   domain.

537   NOTE 4 A jurisdictional domain may impact aspects of the commitment(s) made as part of a
538   business transaction including those pertaining to the making, selling, transfer of goods, services
539   and/or rights (and resulting liabilities) and associated information. This is independent of whether
540   such interchange of commitments are conducted on a for-profit or not-for-profit basis and/or include
541   monetary values.

542   NOTE 5 Laws, regulations, directives, etc., issued by a jurisdictional domain are considered as parts
543   of that jurisdictional domain and are the primary sources of external constraints on business
544   transactions.

545   [ISO/IEC 15944-5]

546   localization

547   pertaining to or concerned with anything that is not global and is bound through specified sets of
548   constraints of:

549   (a)     a linguistic nature including natural and special languages and associated multilingual
550           requirements;

551   (b)     jurisdictional nature, i.e., legal, regulatory, geopolitical, etc.;

552   (c)     a sectorial nature, i.e., industry sector, scientific, professional, etc.;

553   (d)     a human rights nature, i.e., privacy, disabled/handicapped persons, etc.,

554   (e)     consumer behaviour requirements; and/or

555   (f)     safety or health requirements.

556   [ISO/IEC 15944-5:200n (3.nnn)]


                                                                                                               13
557   Open-edi business object
558   an unambiguously identified, specified, referenceable, registered and re-useable Open-edi
559   scenario or scenario component of a business transaction

560   principle
561   a fundamental, primary assumption and quality which constitutes a source of action determining
562   particular objectives or results

563   NOTE 1 A principle is usually enforced by rules that affect its boundaries.

564   NOTE 2 A principle is usually supported through one or more rules.

565   NOTE 3 A principle is usually part of a set of principles which together form a unified whole.

566   EXAMPLE: Within a jurisdictional domain, examples of a set of principles include a charter, a
567   constitution, etc.

568   rule
569   a statement governing conduct, procedure, conditions and relations

570   NOTE 1 Rules specify conditions that must be complied with. These may include relations
571   among objects and their attributes.

572   NOTE 2 Rules are of a mandatory or conditional nature.

573   NOTE 3 In Open-edi, rules formally specify the commitment(s) and role(s) of the parties involved,
574   and the expected behaviour(s) of the parties involved as seen by other parties involved in
575   (electronic) business transactions. Such rules are applied to:

576        -   content of the information flows in the form of precise and computer-processable
577            meaning, i.e. the semantics of data; and,

578        -   the order and behaviour of the information flows themselves.

579   NOTE 4 Rules must be clear and explicit enough to be understood by all parties to a business
580   transaction. Rules also must be capable of being able to be specified using a using a Formal
581   Description Technique(s) (FDTs).

582   EXAMPLE A current and widely used FDT is "Unified Modelling Language (UML)".

583   NOTE 5 Specification of rules in an Open-edi business transaction should be compliant with the
584   requirements of ISO/IEC 15944-3 “Open-edi Description Techniques (OeDT)”.

585   coded Domain Source Authority
586   a Person, usually an organization, which sets the rules governing a coded domain

587   NOTE 1 For widely used coded domains the coded domain Source Authority is often a
588   jurisdiction.

589   NOTE 2 Specific sectors, (e.g., banking, transport, geomatics, agriculture, etc.), may have
590   particular coded domain Source Authority(ies) whose coded domains are used in many other
591   sectors.

592   NOTE 3 A coded domain Source Authority usually also functions as a Registration Authority but
593   can use an agent, i.e., another Person, to execute the registration function on its behalf.



      14
                                                                           ISO/IEC CD 15944-2 :2003



594   de facto language
595   a natural language used in a jurisdictional domain which has the properties and behaviours of
596   an official language in that jurisdictional domain without having formally been declared as such
597   by that jurisdictional domain

598   NOTE 1 A de facto language of a jurisdiction is often established through long term use and
599   custom.

600   NOTE 2 Unless explicitely stated otherwise and for the purposes of modeling a business
601   transaction through scenario(s), scenario attributes and/or scenario components, a de facto
602   language of a jurisdictional domain is assumed to have the same properaties and behaviours of
603   an official language.

604   human interface equivalent
605   a representation of the unambiguous and IT-enabled semantics of an IT interface equivalent (in
606   a business transaction), often the ID code of a coded domain (or a composite identifier), in a
607   formalized manner suitable for communication to and understanding by humans

608   NOTE 1 Human interface equivalents can be linguistic or non-linguistic in nature but their
609   semantics reamin the same although their representations may vary.

610   NOTE 2 In most cases there will be multiple human interface equivalent representations as
611   required to meet localization requirements, i.e. those of a linguistic nature, jurisdictional nature
612   and/or sectorial nature.

613   NOTE 3 Human interface equivalents include representations in various forms or formats, (e.g.,
614   in addition to written text those of an audio, symbol (and icon) nature, glyphs, image, etc.)

615   IT interface equivalent
616   a computer processable identification of the unambiguous semantics of a scenario, scenario
617   attribute and/or scenario component(s) pertaining to a commitment exchange in a business
618   transaction which supports computational integrity

619   NOTE 1 IT interface equivalents have the properties of identifiers (in business transaction) and
620   are utilized to support semantic interoperability in commitment exchange.

621   NOTE 2 An IT interface equivalent at times is a composite identifier.

622   NOTE 3 An IT interface equivalent as a composite identifier can consist of the identifier of a
623   coded domain plus an ID Code of that coded domain.

624   NOTE 4 An IT Interface Value is independent of its encoding in programming languages or APIs.

625   NOTE 5 An IT Interface Value is independent of its encoding in programming languages or APIs.

626   jurisdictional domain
627   a jurisdiction, recognized in law as a distinct legal and/or regulatory framework, which is a source of
628   external constraints on Persons, their behaviour and the making of commitments among
629   Persons including any aspect of a business transaction

630   NOTE 1 The pivot jurisdictional domain is a United Nations (UN) recognized (or candidate)
631   member state. Each state, (a.k.a. country) may have sub-administrative divisions as recognized
632   jurisdictional domains, (e.g., provinces, territories, cantons, länder, etc.), as decided by that UN
633   member state.



                                                                                                          15
634   NOTE 2 Several levels and categories of jurisdictional domains may exist within a jurisdictional
635   domain.

636   NOTE 3 Jurisdictions can combine to form new jurisdictional domains (e.g. through bilateral,
637   multilateral and/or international agreements).

638   EXAMPLE Included here, for example, are the European Union, NAFTA, WTO, WCO, ICAO,
639   WHO, Red Cross, the ISO, the IEC, the ITU, etc.

640   NOTE 4 A jurisdictional domain may impact aspects of the commitment(s) made as part of a
641   business transaction including those pertaining to the making, selling, transfer of goods, services
642   and/or rights (and resulting liabilities) and associated information. This is independent of whether
643   such interchange of commitments are conducted on a for-profit or not-for-profit basis and/or include
644   monetary values.

645   natural language
646   language which is or was in active use in a community of people, and the rules of which are
647   mainly deduced from the usage

648   [ISO 5217:2000 (1.1.2.02)]

649   official language
650   an external constraint in the form of a natural language specified by a jurisdictional domain for
651   official use by Persons forming part of and/or subject to that jurisdictional domain for use in
652   communication(s) either (1) with that jurisdictional domain; and/or, (2) among such Persons,
653   where such communications are recorded information involving commitment(s)

654   NOTE 1 Unless official language requirements state otherwise, Persons are free to choose their
655   mutually acceptable natural language and/or special language for communications as well as
656   exchange of commitments.

657   NOTE 2 An official language(s) can be mandated for formal communications as well as provision of
658   goods and services to Persons subject to that jurisdictional domain and for use in the legal and
659   other conflict resolution system(s) of that jurisdictional domain, etc.

660   NOTE 3 Where applicable, use of an official language may be required in the exercise of rights
661   and obligations of individuals in that jurisdictional domain.

662   NOTE 4 Where an official language of a jurisdiction has a controlled vocabulary of the nature of a
663   terminology, it may well have the characteristics of a special language. In such cases, the
664   terminology to be used shall be specified.

665   NOTE 5 For an official language, the writing system(s) to be used shall be specified, where the
666   spoken use of a natural language has more than one writing system.

667   EXAMPLE 1 The spoken language of use of an official language may at times have more than one
668   writing system. For example, three writing systems exist for the Inuktitut language. Canada uses
669   two of these writing systems, namely, a Latin-1 based (Roman), the other is syllabic-based. The
670   third is used in Russia and is Cyrillic based.

671   EXAMPLE 2 Another spoken language with two writing systems is that of Serbian and Croatian.
672   They are the same spoken language but the former is written using the Cyrillic alphabet and the
673   latter uses the Latin-1 (Roman) alphabet.




      16
                                                                             ISO/IEC CD 15944-2 :2003



674   NOTE 6 A jurisdiction may have more than one official language but these may or may not have
675   equal status.

676   EXAMPLE Canada has two official languages, Switzerland has three, while the Union of South
677   Africa has eleven official languages.

678   NOTE 7 The BOV requirement of the use of a specific language will place that requirement on any
679   FSV supporting service.

680   EXAMPLE A BOV requirement of Arabic, Chinese, Russian, Japanese, Korean, etc., as an official
681   language requires the FSV support service to be able to handle the associated character sets.

682   NOTE 8 A jurisdictional domain decides whether of not it has an official language. If not, it will
683   have a de facto language


684   4     Symbols and abbreviated terms
      BOV             Business Operational View
      CIF             Cost, Insurance and Freight
      FDT             Formal Description Technique
      FOB             Free On Board
      IB              Information Bundle
      INCO            International Commercial Terms (from International Chamber of
                      Commerce (ICC))
      ITTF            Information Technology Task Force (of ISO/IEC)
      OeDT            Open-edi Descriptive Technique
      OeS             Open-edi Scenario
      RA              Registration Authority
      SC              Semantic Component (in the context of Open-edi Scenaro
                      components)
      UN/CEFACT United Nations/Centre for Trade Facilitation and Electronic
                Business
685

686   MAY NEED CLAUSE 5 TO BE FUNDAMENTAL PRINCIPLES AND ASSUMPTIONS


687   5     Open-edi registration requirements

688   The requirements of semantic descriptive techniques 2 and use of natural or special languages
689   are incorporated in the context and characteristics of a registered scenario as well as scenario
690   components including:

      2 A working draft of ISO/IEC 15944-3, Information Technology – Business Agreement Semantic Descriptive
      Techniques – Part 3 : Open-edi Description Techniques, is scheduled to be available for review by 15 May,
      2003.



                                                                                                            17
691         -     the ability to register any organization and support the requirements of internal and/or
692               external constraints
693         -     the ability to support cultural adaptability requirements as well as requirements of a
694               jurisdictional nature as are applicable to the nature and goal of the business transaction
695               being registered
696         -     sets of recorded information to be included within a registry
697         -     unambiguity in use of formal descriptive techniques including those of scenario
698               components involving coded domains

699   5.1       Reusability

700   Rule nnn:

701   Any scenario, scenario atrribute, and/or scenario component shll be identified and
702   specified in a manner which maximizes its reuseability.

703   Scenario contents to be referenced for reuse of the scenario are to be registered with the various
704   business information documents as well as implementable (executable) computer programs. The
705   linkage information for accessing that information shall be clearly described in the registry entry
706   application.

707   (NEED INPUT FROM ebXML REGISTRY/REPOSITORY AND UN/CEFACT WORK)

708   5.2       Multilingualism and Human Interface Equivalents

709   Rule nnn:

710   The registration of any scenario, scenario attribute or scenario component shall be
711   capable of supporting multilingual semantic equivalents at the human interface.

712   This rule, although not expressly stated in Part 1, was nevertheless assumed and supported in
713   the definition for “identifier (in business transaction)”, the use of “IT-interface” and “Linguistic
714   Human-Interface Equivalents” in the templates for Part 1 as well as the bilingual, i.e.
715   English/French (and multilingual expandable) normative Annex A. The purpose of this Clause 5.2
716   is to build on these Part 1 assumptions and state them explicitly in order to be able to support
717   computational integrity requirements while at the same time providing the ability to support
718   multiple, i.e. multilingual human interface, semantic equivalents. to

719   The language used in this standard are:

720         -     International level: ISO English,

721         -     Multilingual Equivalents

722   This standard supports and facilitates the use of equivalents in languages other than ISO English.
723   Annex A contains French language equivalents of the terms and definitions and is structured to
724   facilitate the addition of other language equivalents.

725   The use of unambiguous, unique and linguistically neutral identifiers for scenarios and scenario
726   components will facilitate interoperability in the use of different languages in various jurisdictional
727   domains, and thus will support cultural adaptability. Such identifiers can be simple identifiers or
728   composite identifiers and together form the IT-interface equivalent of the semantics of the




      18
                                                                           ISO/IEC CD 15944-2 :2003



729   processes and data comprising the scenario or scenario component. IT-interface equivalent is
730   defined as:

731        IT interface equivalent
732       a computer processable identification of the unambiguous semantics of a scenario, scenario
733       attribute and/or scenario component(s) pertaining to a commitment exchange in a
734       business transaction which supports computational integrity

735       NOTE 1 IT interface equivalents have the properties of identifiers (in business transaction)
736       and are utilized to support semantic interoperability in commitment exchange.

737       NOTE 2 An IT interface equivalent at times is a composite identifier.

738       NOTE 3 An IT interface equivalent as a composite identifier can consist of the identifier of a
739       coded domain plus an ID Code of that coded domain.

740       NOTE 4 An IT Interface Value is independent of its encoding in programming languages or
741       APIs.

742   From a human interface perspective, any natural language can be utilized to express and
743   represent the semantics of embedded in an IT interface equivalent, i.e. as a “human interface
744   equivalent”.

745   Rule nnn: On the whole, and from an internal constraints only based prespective, parties
746   to a business transaction are free to choose the language(s) to be used.

747   Rule nnn: If the nature of the good, service, and/or right which is the goal of the business
748   transaction and/or the location(s) at which the business transaction is deemed to take
749   place invokes an external constraint(s), then the external constraints invoked may well
750   mandate choice of language(s) (e.g. an official language) to be supported in the
751   registration and reuse of the bsuiness transaction being modelled.

752   Open-edi standards including this standard recognize that on the whole, parties to a business
753   transaction are free to choose and decide among themselves the language(s) to be used. This
754   can be a natural language or a special language, (e.g., as may be appropriate in a specific
755   industry sector, technical area, scientific discipline, etc.). Agreement on choice of language is
756   important in order to ensure common understandings of the recorded information exchanged
757   among parties to a business transaction. However, depending on the nature of the business
758   transaction (e.g. in terms of goods or services provided, the location of the business transaction,
759   etc.), a particular constraint may require the use of specific language (or de facto language). This
760   may result in the requirement of the use of a language other than ISO English (or in addition to
761   English). If this is the case such linguistic requirements shall be specified.

762   Project Editor’s Note

763   Text needed that registration requirements arise from support of Parts 3, 4, 5, etc. of this multipart
764   standard. Part 2 will be revised as requirements arise from other parts of this standard reaching
765   FDIS status




                                                                                                         19
766   6     Principles of registration
767   The following principles are introduced to ensure simplicity in and convenience of registering
768   scenarios and scenario components as well as identifying and retrieving the information of
769   registered scenarios and of scenario components.

770   6.1       Federation of registration authorities

771   (PROJECT EDITOR’S NOTE : SOURCES USE APPLICABLE PARTS OF 7812, 6523, 7501
772   AND JTC1 DIRECTIVES. IT IS RECOGNIZED THAT ONE WILL BE TAKING AND
773   SUPPORTING A FEDERATED APPROACH)

774   Rule nnn:

775   An Open-edi Registration Organization (OeRO) and its operation shall be performed
776   according to an Open-edi Registration Schema (OeRS) as governed by an Open-edi
777   Registraton Authority (OeRA) based upon JTC1 registration definition and cultural
778   adaptability (multiple linguistic support concept) from the viewpoint of diversified laws
779   and regulatory environment.

780   [INSERT ADDITIONAL RULES – BASED ON 6523]

781   6.2       Identification

782   [EDITOR’S NOTE] NEED TEXT FOR IDENTIFICATION PROCESS THAT REFLECTS 6.1
783   FOLLOWING STATEMENTS NEED TO BE EXPRESSED AS RULES. LINK HERE TO
784   COMPOSITE IDENTIFIERS]

785   Open-edi Registration Authority for this standard to assign sequential unique identifiers for
786   OeROs

787   The unique identifier for a scenario or scenario component shall be assigned by OeRO for
788   unambiguous identification of scenarios to provide interoperability at the international level.

789   Implementation rules of registration procedures shall be in accordance with OeRA procedures.

790   6.3       Qualification of OeRAs/OeROs

791   [TEXT FROM 7812]

792   6.4       Registry operation

793   In order to achieve successful registration and reuse of Open-edi scenarios and their
794   components, registration information is required to easily determine the applicability of an Open-
795   edi scenario to a specific business application. Every application for registration of an Open-edi
796   scenario submitted for registration in accordance with this International Standard shall include the
797   following information.

798         -     Administrative information for scenario identification and RA management

799         -     Scenario specification for determination of suitability of application to business objectives

800         -     Classification information for convenient retrieval



      20
                                                                               ISO/IEC CD 15944-2 :2003



801   6.5    Registration information

802   Reuse of registered scenarios and their components requires identification of administrative
803   attributes, e.g., ownership and location from which scenarios and their components can be
804   retrieved. In addition, the scenario specification itself, as prescribed in ISO /IEC 15944-1, is
805   essential in applying the scenarios and their components to a specific business objective. Clear
806   understanding of the registered scenario would facilitate reuse of Open-edi Scenarios; therefore
807   the scenario specification shall be described in as formal a manner as possible. A scenario
808   specification includes an indication of the applicability of Open-edi scenario, role, information
809   bundle and semantic component attributes, and a detailed description of their applicable
810   attributes.

811   Classification attributes provide characteristics of Open-edi scenarios and their components that
812   are also fundamental for their reuse. Well organized classification attributes provide the best
813   search criteria for retrieving a registered scenario that is the best fit for certain business
814   objectives. Classification attributes effectively identify the scope of registered scenarios and their
815   components. While previously considered to be part of registration information in the body of this
816   standard, classification attributes more properly form part of the Open-edi Ontology Model of
817   ISO/IEC 15944 Part 4. As an interim measure, primitive classification attributes alread agreed to
818   are captured in Annex X and will be balloted as part of CD ISO/IEC 15944 Part 2, not Part 4.

819   6.6    OeDT requirements

820   Various formal descriptive techniques (Note: allow for business process specifications that
821   already exist) may be employed to define the class of business requirement and predefined set
822   of scenario components.

823   OeDTs and various templates as well as classification attributes are encouraged to describe a
824   scenario, which are referenced in this Standard.

825   Detailed contents of scenario registration items shown in Clause 9 and Annex C (examples) are
826   recommended to be reviewed before submitting the registration form.


827   7     Administration attributes
828   Administrative information for the registration of a scenario or scenario component, includes
829   version information, replacement information, status information, and change history. 3

830   7.1    Version information

831   Even though at any given point in time only one version of a scenario or scenario component can
832   be valid, multiple previous versions may have existed and a future version may be in preparation.
833   The version association makes it possible to link the consecutive versions of a scenario or
834   scenario component. There will not be branches in the versioning; only linear versioning will be
835   supported.




      3A source, in addition to JTC1 standards, is the UN/CEFACT Core Components Technical Specification..
      Key contents from this specification to be imported into this standard



                                                                                                          21
836   7.2   Replacement information

837   A scenario or scenario component may be replaced by another scenario or scenario component
838   at some point in time (e.g. because a duplicate is discovered). The ‘Replaced by’ association
839   makes it possible to do this. Replacement information makes it possible to document the date of
840   and reason for replacement.

841   7.3   Status information

842   Information about the live status of a scenario or scenario component is provided by status
843   information attributes.

844   7.4   Change history

845   Scenarios and scenario components shall include the history of the status lifecycle of each
846   version. This information about all changes that are made to a scenario or scenario component is
847   maintained using change history attributes.

848   7.5   Administration attribute list

849   Registration administration attributes are numbered as A.n. Refer to Table 1 for the application of
850   administration attributes to scenarios, roles, information bundles and semantic components.
851   Open-edi Scenario Component ID Codes in Table 1 for A.4, Registration Name, A.19, Related
852   Regulation, A.22, OeS Inheritance, and A.23, Cross-References are carried over from ISO/IEC
853   15944-1, 9.2.3, Consolidated template of attributes of Open-edi scenarios, roles and information
854   bundles. It should be noted that relatively few administration attributes reference Open-edi
855   Scenario Component ID Codes, because administration attributes serve registration
856   administration purposes only, and are not considered to be descriptive characteristics of a
857   scenario or scenario component. The application of such administration attributes to scenario,
858   role, information bundle, or semantic component is indicated by X in the registration matrix.

859   The Registration Matrix in Annex B provides a consolidated list of administration attributes, along
860   with the scenario specification attributes of ISO/IEC 15944-1. Administration attributes are
861   mandatory, unless indicated otherwise.

862   THE LIST OF ADMINISTRATIVE ATTRIBUTES A.1 THROUGH A.37 WILL BE DELETED AND
863   REPLACED BY RULES THAT PERTAIN TO ADMINISTRATIVE ATTRIBUTES.

864

865   A.1 Identifier
866   The unique identification number of a scenario or scenario component assigned by a registration
867   authority

868   A.2 Version Number
869   The version number of a scenario or scenario component assigned by a registration authority ;
870   default = 1.0

871   A.3 Registration Name
872   The name that may be commonly used to refer to the scenario or scenario component in the
873   relevant business community




      22
                                                                         ISO/IEC CD 15944-2 :2003



874   A.4 Change Type
875   Nature of the change, such as new scenario or scenario component, new version, modification,
876   status modification, replacement

877   A.5 Change Date
878   The date when the scenario or scenario component modification was successfully registered
879   (Editorial Note : this is a placeholder to be revisited when the registration process is stable)

880   A.6 Change Description
881   Description of why and how the scenario or scenario component has been modified

882   A.7 Application Number
883   The identification number assigned by the Registration Organization to the application of
884   registering a scenario or scenario component

885   A.8 Application Date
886   The date an applicant4 submits a scenario or scenario component for registration

887   A.9 Applicant Name
888   The name of the applicant who applies to register a scenario or scenario component

889   A.10    Reference [optional, repetitive]
890   External document(s) containing relevant information about the modification to the scenario or
891   scenario component

892   A.11     Registration Contact Name
893   Contact
894   an instance of a role of a Person to whom an information item(s), a material object(s), a business
895   object(s), and/or natural persons (as either individual(s), or organization Person(s) can be sent to
896   or received from in a specified context

897   NOTE 1 A Person here as a Contact can be an individual, an organization (or organization part or
898   organization Person).

899   NOTE 2 Contact is capitalized to distinguish it from the many ordinary uses of the word

900   Registration Contact Name
901   name of a Person who has the responsibility of contact regarding the scenario registration and
902   inquiry of its registration

903   NOTE Where an organization is the applicant, it may designate an organization Person, an agent,
904   or a third party as its registration Contact name in applying to register a scenario or scenario
905   component

906   A.12    Registration Contact Mailing Address




      4 See 3.1




                                                                                                       23
907   address
908   a set of data elements that specifies a location to which an information item(s), a business
909   object(s), a material object(s) and/or a person(s) can be sent to or received from

910   physical address
911   an address that is used/recognized by a postal authority and/or courier service to deliver
912   information item(s), material object(s), or business object(s) to a Contact at either an actual
913   address or a pick-up point address, (e.g., P.O. Box, rural route, etc.)

914   registration Contact mailing address
915   the physical address utilized by a Person applying to register a scenario or scenario component

916   A physical address that is recognised and used by a postal authority and/or courier service for
917   delivery of correspondence to the applicant

918   A.13      Registration Contact Telephone Number
919   telephone address
920   a valid instance of an electronic address in a directory schema/service based on ITU Rec. E164,
921   i.e., a string or combination of decimal digits, symbols, and additional information which identifies
922   the specific termination point(s) of a connection in a public network(s) or, where applicable, in
923   interconnected private network(s)

924   [ITU-T Rec. E.164 (1997)]

925   registration Contact telephone number
926   a specified telephone address utilized by the Person applying to register a scenario or scenario
927   component

928   A.14     Registration Contact Facsimile Number
929   registration Contact facsimile number
930   the use of a specified telephone address designated for facsimile transmission purpose and
931   utilized by the Person to register a scenario or scenario component

932   A.15    Registration Contact email Address
933   registration Contact e-mail address
934   a valid instance of an electronic address based on a X.400, X.500 and/or IP directory
935   schema/service

936   A.16   Author
937   The Person who created a scenario or scenario component

938   A.17     Expected User Community
939   The relevant community, industry, country, etc., to which the scenario could be effectively
940   applied.

941   Project Editor’s Note

942   This could also be stated as the Target Community, i.e. the set of users for whom this scenario
943   is intended to be used.. Further from an external constraints perspective, one may need a
944   “mandated user Community”, i.e. the users to whom a scenario based on external constraints
945   applies.




      24
                                                                           ISO/IEC CD 15944-2 :2003



946   A.18    Related Regulation (2070) [conditional]
947   An applicant shall identify any regulation that may govern or restrict the application of a scenario,
948   scenario attribute, or scenario component

949   Note : if applicable, these shall be specified using the relevant scenario specification attributes

950   Project Editor’s Note

951   We need to take into consideration the use of scenarios and scenario components to model and
952   register a regulatory requirement as a scenario. (Note Annex I in Part 1 is an example of this).

953   A.19     Intellectual Property Right [conditional]
954   Rule__: An applicant shall identify any intellectual property right (IPR) of any element of a
955   scenario, attribute or scenario component being registered. Note : IPR may be copyright, patent,
956   industrial design [e.g., WIPO document]

957   A.20    Restriction [optional]
958   Specific restrictions of an application community and/or objectives of a scenario

959   A.21     Inheritance (2080) [optional]
960   Identification and version of the scenario that is a superclass to this scenario

961   A.22     Cross-References (2080, 3030, 2140, 2150, 4090) [optional]
962   Identification and version of the scenario(s) or scenario component(s) that is (are) related to this
963   scenario or scenario component

964   A.23   OeS Language Code
965   Open-edi Scenario Language Code
966   The ISO 639-2T language code for the natural language used for specifying the Open-edi
967   Scenario.

968   A.24   OeDT Used
969   The description language and/or technique that is used to describe the scenario contents, i.e.,
970   Open-edi Descriptive Technique (Refer to ISO/IEC 15944-3, Information Technology – Business
971   Agreement Semantic Descriptive Techniques Part 3: Open-edi description techniques

972   A.25    Repository Location
973   The URI address of the scenario with the repository where the scenario or scenario component is
974   located

975   A.26    Registrar
976   Name of the person responsible who has entered the scenario or scenario component in the
977   repository

978   A.27   Open-edi Registration Organization
979   Organization authorized to register the scenario or scenario component

980   A.28    Replacement Description




                                                                                                            25
981   For each stored pair of registry entries where one register entry replaces the other, reason for the
982   scenario or scenario component being replaced

983   A.29    Replacement Date
984   Date from which the replacement is effective

985   A.30    Registry Entry Status
986   Status of the registry entry (i.e., draft, provisionally registered, registered, to be retired, retired, …)

987   A.31   Registry Entry Status Start Date
988   Date on which the status comes into effect

989   A.32    Registry Entry Status Change Reason [optional]
990   Description of why the registry entry satus has been changed

991   A.33    Registry Entry Status Change Reference [optional, repetitive]
992   External document(s) containing relevant information the the status change

993   A.34  Registry Entry Status Comment [optional, repetitive]
994   Remark about the registry entry status

995   A.35    Remarks [optional]
996   A.36    Other Informative Information [optional]
997




      26
                                                                                                                   ISO/IEC CD 15944-2 :2003




998                                                        Table 1 Administrative Attributes
999    Project Editor’s Note

1000   For these tables, i.e. coded domains, we need to have a “standard” presentation and one which is harmonized with the two templates already
1001   found in Part 1.

1002

                          Administration Attributes                    Scenario         Role             Information      Semantic
                                                                                                         Bundle           Component
                                                                                    Open-edi Scenario Component ID Code

       A.1
       A.1 Identifier                                                  X                X                X                X
       A.2 Version Number                                              X                                 X                X
       A.3 Registration Name                                           2020             3010             4020             5020
       A.4 Change Type                                                 X                                 X                X
       A.5 Change Date                                                 X                                 X                X
       A.6 Change Description                                          X                                 X                X
       A.7 Application Number                                          X                                 X                X
       A.8 Application Date                                            X                                 X                X
       A.9 Applicant Name                                              X                                 X                X
       A.10    Reference (optional, repetitive)                        X                                 X                X
       A.11    Registration Contact Name                               X                                 X                X
       A.12    Registration Contact Mailing Address                    X                                 X                X
       A.13    Registration Contact Telephone Number                   X                                 X                X




                                                                                                                                              27
                   Administration Attributes            Scenario   Role   Information   Semantic
                                                                          Bundle        Component
A.14   Registration Contact Facsimile Number            X                 X             X
A.15   Registration Contact email Address               X                 X             X
A.16   Author                                           X                 X             X
A.17   Expected User Community                          X
A.18   Related Regulation (conditional)                 2070
A.19   Intellectual Property Right (conditional)        X                 X             X
A.20   Restriction (optional)                           X
A.21   Inheritance (optional)                           2080       3030
A.22   Cross-References (optional)                      2080       3030   2140          2150, 4090
A.23   OeS Language Code                                X
A.24   OeDT Used                                        X
A.25   Repository Location                              X                 X             X
A.26   Registrar                                        X                 X             X
A.27   Open-edi Registration Organization               X                 X             X
A.28   Replacement Description                          X                 X             X
A.29   Replacement Date                                 X                 X             X
A.30   Status                                           X                 X             X
A.31   Status Start Date                                X                 X             X
A.32   Status Change Reason (optional)                  X                 X             X
A.33   Status Change Reference (optional, repetitive)   X                 X             X
A.34   Status Comment (optional, repetitive)            X                 X             X




28
                                                                             ISO/IEC CD 15944-2 :2003




                  Administration Attributes       Scenario   Role   Information    Semantic
                                                                    Bundle         Component
A.35   Remarks (optional)                         X                 X              X
A.36   Other Informative Information (optional)   X                 X              X




                                                                                                        29
       COMMITTEE DRAFT INTERNATIONAL STANDARD                                                                CD 15944-2 :2003




1003   CLAUSE 8 WILL BE DELETED, ONCE ANNEX X IS IN PLACE


1004   8     Classification attributes
1005   There are two types of classification attributes. The first type of classification attribute is described
1006   by making an appropriate choice among given alternatives. These are predefined (or demed to
1007   be “pre-definable”) The second type of classification attribute is described by providing
1008   appropriate specification(s) in a given format. The specification should be written in the Common
1009   Description Language for Open-edi business object registration.

1010   Classification attributes provide for selection from an exhaustive list of options for each attribute
1011   as specified in table format, or addition of an option for an attribute that is not fully defined.
1012   Classification attributes are numbered as CL.n, and reference Scope Tag ID Codes in Table 2,
1013   most of which are carried over from ISO/IEC 15944-1, 7.3, Template for specifying scope of an
1014   Open-edi scenario. Classification attributes are repeated in the consolidated Registration Matrix
1015   of Annex B. Registration of classification attributes is optional, as determined by a Decision Code
1016   of 1, (i.e., YES) or 2 (i.e., NO) in Template 7.3 of ISO/IEC 15944-1. A classification attribute
1017   shall be registered if its Decision Code is 1 in Template 7.3.

1018   8.1    Trade models by type

1019   CL.1    Market Type (1065)

1020   market type:
1021   a classification concept of market where the market is defined (bounded) or undefined
1022   (unbounded) for specific types of business transactions or communities under the Open-edi
1023   environment

1024   CL.2    Settlement Type (1070)

1025   settlement type:
1026   a classification concept of settlement where all aspects of the business transaction are settled
1027   immediately or separately5.

1028   the delivery and payment an Open-edi transaction is simultaneously settled through the network,
1029   or separately performed through different channels

1030   CL.3    Participation Type (1060)

1031   participation type:
1032   a classification concept of participation of Open-edi parties where intermediate(s) other than
1033   either buyer(s) or seller(s) is involved in an Open-edi transaction, or not

1034   8.2    Agents and third parties

1035   CL.4    Agent Type (1110)


       5 See Part 1, 6.6.3.2 and Annex H




       30
                                                       ISO/IEC CD 15944-2 :2003



1036   Need definition

1037   CL.5    Third Party Constraint Type (1130)

1038   Need definition

1039   CL.6    Role Type of third Party (1135)

1040   Need definition

1041   8.3    Process planning

1042   CL.7    Catalogue Provision (1225)

1043   Need definition

1044   CL.8    Order Type (1230)

1045   Need definition

1046   CL.9    Offer Type (1235)

1047   Need definition

1048   CL.10    Manufacturing Type (1245)

1049   Need definition

1050   CL.11    Liability/Risk Management (1247)

1051   Need definition

1052   8.4    Process identification

1053   CL.12 Economic Resource Type (1280)

1054   Need definition

1055   CL.13    Exchange Value Type (1285)

1056   Need definition

1057   8.5    Process negotiation

1058   CL.14    Pricing Type (1320)

1059   Need definition

1060   CL.15    Non-pricing Negotiation Terms (1330)

1061   Need definition

1062   CL.16    Sales Channel Type (1340)


                                                                                  31
1063   Need definition

1064   8.6   Process actualization

1065   CL.17   INCO Terms Delivery Type (1360)

1066   Need definition

1067   CL.18   Transport Type (1362)

1068   Need definition

1069   CL.19   Payment Term Type (1365)

1070   Need definition

1071   CL.20   Payment Method (1370)

1072   Need definition

1073   CL.21   Settlement Type (1380)

1074   Need definition

1075   8.7   Process post-actualization

1076   CL.22   Warranty Type (1405)

1077   Need definition

1078   8.8   Scenario management

1079   CL.23   Successiveness Type (1450)

1080   Need definition

1081




       32
                                                                          ISO/IEC CD 15944-2 :2003




1082                                  Table 2 Classification Attributes

                           Classification Attributes                          Scenario
                                                                              Scope Tag ID
                                                                              Code/Coded
                                                                              Domain Value
       CL.1   Market Type                                                     1065
         Open Market Model - a trade model, conforming to the                        01
         description of Basic Trade Model, which is performed in an
         unbounded market under the Open-edi environment.
         Closed Market Model – a trade model where buyer(s) and                      02
         seller(s) accept the entry terms of market in advance and then
         commence the actual business transaction in the market under
         the Open-edi environment.
       CL.2   Settlement Type                                                 1070
         Immediate Settlement Model - a trade model where the entire                 01
         business transaction process, such as planning, identification,
         negotiation, delivery of goods or services and payment, is
         completed in real-time under the Open-edi environment
         Separate Settlement Model - a trade model where the                         02
         business transaction is performed under the Open-edi
         environment, and where the delivery of the good, service,
         and/or right and/or payment is separated from the agreement
         process
       CL.3   Participation Type                                              1060
         Bilateral Trade Model - a trade model where only buyer and                  01
         seller are directly involved in a business transaction
         Mediated Trade Model - a trade model where a third party                    02
         mediates a specified role(s) or function(s) as mutually agreed
         to by the buyer(s) and seller(s) for a certain business
         transaction.
       CL.4   Agent Type                                                      1110
         Buyer’s Agent - the scenario explicitly supports the role type of           01
         buyer’s agent in business transactions
         Seller’s Agent - the scenario explicitly supports the role type of          02
         Seller’s agent in business transactions
         None - the scenario does not support any role type of agent in              99
         a business transaction
       CL.5   Third Party Constraint Type                                     1130
         Internal Constraint - use of a third party is by mutual                     01
         agreement of the buyer and seller
         External Constraint - use of a third party is mandated                      02




                                                                                                     33
                       Classification Attributes                         Scenario
     None - the scenario does not support any role type of a third              99
     party
CL.6      Third Party Role Type                                          1135
     Other - the scenario explicitly supports the other role types              00
     than those specified below in business transactions
     Mediator – the scenario explicitly supports the role type of               01
     mediator in business transactions
     Guarantor - the scenario explicitly supports the role type of              02
     guarantor in business transactions
     Escrow - the scenario explicitly supports the role type of                 03
     escrow in business transactions
     Notary - the scenario explicitly supports the role type of notary          04
     in business transactions
     None - the scenario does not explicitly supports any role type             99
     of third party in business transactions
CL.7      Catalog Provision                                              1225
     Provided - the scenario explicitly supports catalogue provision            01
     of merchandize in business transaction
     None - the scenario does not support catalogue provision of                99
     merchandize in business transaction
CL.8      Order Type                                                     1230
     Other - the scenario explicitly supports other order types than            00
     those specified below
     Pre-order - the scenario explicitly supports query/response                01
     interactions related to product/service availability, terms and
     conditions, etc.
     Purchase - the scenario explicitly supports the purchase type              02
     order process in business transaction
     Change - the scenario supports the ability of the buyer to                 03
     amend a purchase type order
     Cancel - the scenario supports the ability of the buyer to cancel          04
     a purchase type or change type order
     Contract - the scenario explicitly supports the contract type              05
     order process in business transaction
CL.9      Offer Type                                                     1235
     Other - the scenario explicitly supports other offer types than            00
     those specified below
     Proposal - the scenario explicitly supports the proposal type              01
     offer process in business transactions
     Consign - the scenario explicitly supports the consign type                02
     offer process in business transactions



34
                                                                   ISO/IEC CD 15944-2 :2003




                   Classification Attributes                           Scenario
CL.10 Manufacturing Type                                               1245
  Other - the scenario explicitly supports other manufacturing                00
  types than those specified below
  Predefined - the scenario explicitly supports the readymade                 01
  type products or packaged services provision in business
  transactions
  Definable - the scenario explicitly supports the order made                 02
  type products or customized services provision in business
  transactions
  Off-the-shelf - the scenario explicitly supports standardized               03
  products ready for turn-key operation
  Configurable - the scenario explicitly supports products that               04
  may require the buyer to specify configurable options with the
  seller during Process Negotiation
CL.11 Liability/Risk Management                                        1247
  Other - The scenario supports a protection type other than                  00
  insurance or deposit
  Insurance - The scenario supports the insurance protection                  01
  type. Either the buyer or the seller may insure the payment for
  the goods or the value of the goods delivered
  Deposit - The scenario supports the deposit protection type.                02
  The buyer deposits money either with the seller or with a third
  party
  None - The scenario does not explicitly support any liability/risk          99
  management of business transaction
CL.12 Economic Resource Type                                           1280
  Other - The scenario explicitly supports other value resource               00
  than those specified below
  Good - The scenario explicitly supports the physical type                   01
  products in the business transaction
  Service - The scenario explicitly supports the provision of                 02
  services in the business transaction
  Value - The scenario explicity supports the financial products              03
  in business transaction
  Title/ Ownership - The scenario explicity supports the right of             04
  possession in business transaction
  License/ Right - The scenario explicity supports the right of               05
  permission in business transaction
CL.13 Exchange Value Type                                              1285
  Currency – ISO/IEC 4211                                                     01
CL.14 Pricing Type                                                     1320



                                                                                              35
                      Classification Attributes                         Scenario
     Other - the scenario explicitly supports business transactions            00
     of other pricing type than those specified below
     Buyer’s Quote - the scenario explicitly supports business                 01
     transactions of buyer’s quote type pricing, i.e., price is
     determined by the buyer
     Seller’s Quote - the scenario explicitly supports business                02
     transactions of seller’s quote type pricing, i.e., the price is
     determined by the seller
     Individual Quote - the scenario explicitly supports business              03
     transactions of individual quote type pricing, i.e., the seller
     provides an offer price to a specific buyer in response to a
     request for a quote
     Closed Bid - the scenario explicitly supports business                    04
     transactions of closed bid type pricing (allow only sellers in a
     club). A bid is against a buyer’s specification
     Open Bid - the scenario explicitly supports           business            05
     transactions of bid type pricing from any seller
     Auction - the scenario explicitly supports business transactions          06
     of auction type pricing
     Reverse Auction - the scenario explicitly supports business               07
     transactions of reverse auction type pricing
     Price Matching - the scenario explicitly supports business                08
     transactions of price matching type pricing, i.e., generally
     multiple buyers interact with multiple sellers, where agreement
     on price is dynamically reached.g., stock market
CL.15 Non-pricing Negotiation Terms                                     1330
     Other - the scenario supports non-pricing negotiation terms               00
     other than those specified below
     Negotiable Delivery Terms - the scenario explicitly                       01
     supports/does not support the negotiation of delivery terms
     Negotiable Delivery Lot - the scenario explicitly supports/does           02
     not support the negotiation of delivery lot
     Negotiable Packaging - the scenario explicitly supports/does              03
     not support the negotiation of packaging of merchandize
     None - the scenario does not support any non-pricing                      99
     negotiation terms other than the above mentioned
CL.16 Sales Channel Type                                                1340
     Other - the scenario supports sales channel types other than              00
     those specified below
     Direct - the scenario explicitly supports business transactions           01
     of direct sales channel type
     Consignment - the scenario explicitly supports business                   02
     transactions of consignment sales channel type



36
                                                                ISO/IEC CD 15944-2 :2003




                   Classification Attributes                        Scenario
CL.17 INCO Terms Delivery Type                                      1360
  Other - the scenario explicitly supports delivery term types             00
  other than those specified below
  EXW - the scenario explicitly supports EXW (Ex Works) of                 01
  INCO Terms
  FCA - the scenario explicitly supports FCA (Free Carrier) of             02
  INCO Terms
  FAS - the scenario explicitly supports FAS (Free Alongside               03
  Ship) of INCO Terms
  FOB - the scenario explicitly supports FOB (Free on Board) of            04
  INCO Terms
  CFR - the scenario explicitly supports CFR (Cost and Freight)            05
  of INCO Terms
  CIF - the scenario explicitly supports CIF (Cost, Insurance and          06
  Freight) of INCO Terms
  CPT - the scenario explicitly supports CPT (Carriage Paid To)            07
  of INCO Terms
  CIP - the scenario explicitly supports CIP (Carriage and                 08
  Insurance Paid To) of INCO Terms
  DAF - the scenario explicitly supports DAF (Delivered At                 09
  Frontier) of INCO Terms
  DES - the scenario explicitly supports DES (Deliverd Ex Ship)            10
  of INCO Terms
  DEQ - the scenario explicitly supports DEQ (Delivered Ex                 11
  Quay) of INCO Terms
  DDU - the scenario explicitly supports DDU (Delivered Duty               12
  Unpaid) of INCO Terms
  DDP - the scenario explicitly supports DDP (Delivered Duty               13
  Paid) of INCO Terms
CL.18 Transport Type                                                1362
  Other - the scenario explicitly supports transport types other           00
  than those specified below
  Fixed/Physical – need definition                                         01
  Fixed/Electronic – need definition                                       02
  Mobile/Physical – need definition                                        03
  Mobile/Electronic – need definition                                      04
CL.19 Payment Term Type                                             1365
  Other - the scenario explicitly supports other payment term              00
  types than those specified below




                                                                                           37
                      Classification Attributes                         Scenario
     Single Payment - the scenario explicitly supports a single                01
     payment
     Multiple Payments - the scenario explicitly supports multiple             02
     payments
CL.20 Payment Method                                                    1370
     Other - the scenario explicitly supports other payment methods            00
     than those specified below
     Credit - the scenario explicitly supports credit type payments            01
     Debit - the scenario explicitly supports debit type payments              02
     Cash - the scenario explicitly supports cash type payments                03
     Funds transfer - the scenario explicitly supports funds transfer          04
     type payments
     Counter product - “barter”                                                05
CL.21 Settlement Type                                                   1380
     Other - the scenario explicitly supports a type of settlement             00
     other than those specified below
     Advanced Payment - the scenario explicitly supports the                   01
     advanced payment type settlement
     Deferred Payment - the scenario explicitly supports the                   02
     deferred payment type settlement
     Payment on Delivery - the scenario explicitly supports the                03
     payment on delivery type settlement
     Incremental Payment - the scenario explicitly supports the                04
     incremental payment type settlement
CL.22 Warranty Type                                                     1405
     Other - the scenario explicitly supports other warranty types             00
     than those specified below
     Warranty - the scenario explicitly supports the warranty of               01
     merchandize
     Refundable - the scenario explicitly supports the refund of               02
     merchandize
     None - the scenario does not explicitly support a warranty type           99
CL.23 Successiveness Type                                               1450
     Other - the scenario explicitly supports other successive                 00
     business transaction types than those specified below
     Successive - the scenario supports successive transactions                01
     eliminating redundant business negotiation processes already
     established in a previous transaction. A framework agreement
     exists between the parties that governs subsequent scenarios




38
                                                   ISO/IEC CD 15944-2 :2003




             Classification Attributes                 Scenario
Autonomous - the scenario stands alone as a business          02
transaction, i.e., “One-off”




                                                                              39
1083


1084   9    Scenario specification attributes
1085   Draft Rule Scenario specification attributes ensure that all the information required for the
1086   Business Operational View (BOV) of an Open-edi Scenario, its components and all attributes
1087   required to be specified, (and registered for re-use) are captured in a systematic and explicit
1088   manner.

1089   Scenario specification attributes are numbered as SS.n, and reference Open-edi scenario
1090   component ID codes in Table 2, most of which are carried over from ISO/IEC 15944-1, 9.2.3,
1091   Consolidated template of attributes of Open-edi scenarios, roles and information bundles.
1092   Scenario specification attributes are repeated in the consolidated Registration Matrix of Annex B..
1093   Registration of scenario specification attributes is optional, as determined by a Decision Code of
1094   1, (i.e., YES) or 2 (i.e., NO) in Template 9.2.3 of ISO/IEC 15944-1. A scenario specification
1095   attribute shall be registered if its Decision Code is 1 in Template 9.2.3.




       40
                                                                                                                      ISO/IEC CD 15944-2 :2003




1096                                                      Table 2 Scenario Specification Attributes

                      Scenario Specification Attributes                    Scenario        Role            Information      Semantic
                                                                                                           Bundle           Component
                                                                           Open-edi Scenario Component ID Code/Coded Domain Value

       SS.1   International Standard Identifier                                2005
       SS.2   Identifier                                                       2010               3005         4010              5010
       SS.3   Name                                                             2020               3010         4020              5020
       SS.4   Purpose, SC Definition                                           2030               3015         4030              5030
       SS.5   OeS Set of Roles, OeS Business Requirements, Role                2040         3020, 3025
              Business Goals, Rules and Constraints
       SS.6   OeS Set of Information Bundles                                   2050
       SS.7   Set of Requirements/Demands on Open-edi Parties               2500, 2060            3050
       SS.8   External Constraints on Business Requirements, i.e., Laws        2070               3035         4050
              and Regulations
       SS.9   Inheritance Identifier(s) and Cross References                   2080               3030
       SS.10 Security Service Requirements                                     2090               3040         4100              5040
       SS.11 Communication - Quality of Service Requirements                   2100               3045
       SS.12 OeS Role Requirements and Constraints                             2120
       SS.13 Person Qualification Type                                                     2125
         Mandatory - the scenario explicitly requires the mandatory                                   01
         qualification of Person
         Preferred - the scenario explicitly supports the preferred                                   02
         qualification of Person
         None - the scenario does not             explicitly support any                              99
         qualification of Person




                                                                                                                                                 41
                 Scenario Specification Attributes                  Scenario      Role          Information   Semantic
                                                                                                Bundle        Component
SS.14 OeS Dependency among Roles in a Scenario                             2130
SS.15 OeS Dependency among Information Bundles in a                        2140
      Scenario
SS.16 OeS Dependency among Semantic Components of                          2150
      Different Information Bundles
SS.17 Processing Mode                                               2600
     Other – the scenario explicitly supports other processing               00
     modes than those specified below
     Real-time - the scenario is processed in real-time mode                 01
     Batch - the scenario is processed in batch mode                         02
SS.18 Interoperability Demands among Roles                                               3060
SS.19 Role States                                                                        3065
SS.20 Role Transitions                                                                   3070
SS.21 Role Events                                                                        3075
SS.22 Role Actions                                                                       3080
SS.23 Role Internal Function                                                             3085
SS.24 Demands on Open-edi Support Infrastructure                           2600          3090       4300
SS.25 Business Rules Controlling Content of IBs                                                     4040
SS.26 IB contents                                                                                   4060
SS.27 IB recorded information retention – business rules and                                        4070
      constraints
SS.28 IB recorded information retention – external constraints on                                   4080
      business requirements, i.e., laws and regulations




42
                                                                                      ISO/IEC CD 15944-2 :2003




               Scenario Specification Attributes         Scenario   Role   Information      Semantic
                                                                           Bundle           Component
SS.29 IB time validity characteristics                                         4085
SS.30 Relationship of semantic components within an IB                         4090
SS.31 IB Information for Interoperability                                      4200




                                                                                                                 43
       COMMITTEE DRAFT INTERNATIONAL STANDARD                                                                CD 15944-2 :2003




1097   10 Registration authority and operations

1098   10.1 Registration authority for Open-edi scenarios

1099   10.1.1 Appointment

1100   CANDADIAN CONTRIBUTION EXPECTED.The JTC1 OeRO for Open-edi scenarios shall be
1101   appointed by the OeRA in accordance with the procedure for the appointment of JTC1
1102   Registration Authorities defined in the JTC1 Directives.

1103   10.1.2 Qualification

1104   CANADIAN CONTRIBUTION EXPECTED. Any organization seeking appointment, as the JTC1
1105   OeRO for Open-edi scenarios shall demonstrate that it meets the qualifications required of JTC1
1106   RAs as defined in the JTC1 Directives, with the following condition.

1107        It shall confirm that it has sufficient resources to operate an Internet web site in support of this
1108        International standard.

1109   10.1.3 OeRO establishment

1110   CANADIAN CONTRIBUTION EXPECTED. The JTC1 OeRO for Open-edi scenarios shall operate
1111   under contract with the OeRA.

1112   The following conditions are applied for a OeRO establishment :

1113        A national member body itself or its commissioned agents, national or regional, can be a
1114        OeRO candidate for JTC1 OeRO

1115        A national OeRO should be qualified and internationally acceptable and have a right to
1116        delegate its roles to commissioned national or regional agents

1117        An OeRO basically exists for the national or the regional domain area (i.e., generalized
1118        through jurisdictional domains), however a allied OeRO between/among countries is a
1119        possible candidate

1120        The national member body should be required to indicate a newly established OeRO to JTC1
1121        SC32

1122   10.1.4 Duties

1123   The JTC1 OeRO for Open-edi scenarios shall :

1124        Act and handle all aspects of registration administration in accordance with this International
1125        standard and good business practice.

1126        Receive and review applications and maintain an accurate register




       44
                                                                           ISO/IEC CD 15944-2 :2003



1127      Make pubic access to complete details of all register entries available and provide
1128      information’s as appropriate.

1129   10.2 Applicant for registry

1130   Any organization or individual may submit an application of a scenario to the JTC1 OeRO for
1131   Open-edi scenario.

1132   10.3 Application procedure for registration

1133   An application of registry starts with the submission of a new open-edi scenario application for
1134   registration and terminates with the registration acceptance. The submission shall conform to the
1135   following requirements :

1136      Identification and authentication of applicant and confirmation of required conformance to this
1137      International Standard

1138      Language adaptability

1139   Use of English for the minimum required description is mandatory, however additional descriptive
1140   information in an OeRO-authorized language may be permitted by the OeRO.

1141   An application for register of an Open-edi scenario shall be rejected if:

1142      The scenario to be registered already exists in a register

1143      The scenario is not executable or referable

1144      The scenario contains non-publishable information (e.g., classified) or intellectual property
1145      right (IPR) restrictions.

1146      The scenario contains objectionable information from a public order and morals viewpoint

1147   Pre registration procedure

1148      The OeRO shall call for public comments before registration, however the OeRO has no duty
1149      to answer to each comment.

1150      Announcement of registration

1151      Accepted scenario applications is announced to public after the termination of 6 month public
1152      comment due date.

1153   Post registration procedure

1154      OeRO shall make access available via electronic mechanism

1155   10.4 Operation of registration authority

1156   The following items have to be carefully examined and developed as the procedure for
1157   registration operation within the OeRO:

1158      Response and notification of application of entries



                                                                                                      45
1159        Validation and routine review of entries and comments on new applications

1160        Defect notification

1161        Deletion of register entries


1162   11 Maintenance of the register
1163   The OeRO shall take appropriate measures to ensure that the information within the register is
1164   adequately maintained and is publicly accessible without unreasonable delay. Appropriate
1165   measures shall be taken to protect the register.

1166   11.1 Confidentiality of information held within the register

1167   Register entries shall not contain secret, proprietary or non-publishable material. The OeRO shall
1168   make all information within all entries publicly available.

1169   11.2 Publication of the register

1170   The JTC1 OeRO under the terms of this standard shall maintain a register of all Open-edi
1171   scenarios and its packages that it has accepted for registration. The minimum key items
1172   registered (the OeRO can decide and publicly announce) shall be maintained and published in
1173   the English language. Technical definitions and Informative contents of the register or individual
1174   register entries may be provided in other languages according to the RA recommendations.

1175   The OeRO shall provide access at a reasonable cost to all information identified above for all
1176   registries via electronic networks.

1177   11.3 Dispute resolution

1178   If there is a dispute between an applicant and OeROs, the OeRO shall make reasonable efforts
1179   to resolve the dispute. The OeRO may consult with other OeROs and/or the technical group
1180   responsible for the technical standard.

1181   11.4 Modification, deletion, obsolesce of the registered scenario

1182   11.4.1 Modification and deletion

1183   An OeRO shall accept requests to modify and delete a registered scnario only from the original
1184   applicant of the scenario. OeRO management shall deny any other request for scenario
1185   modification and deletion.

1186   11.4.2 Obsolescence

1187   An OeRO may be able to obsolete a registered scenario with a six-month ’wait and warn’ period if
1188   the following conditions occur :

1189        ten years elapsed since the scenario was registered

1190        no scenario update activity by applicant Persons or user access




       46
                                                                                            ISO/IEC CD 15944-2 :2003




1191     Annex A (normative): Consolidated list of terms and definitions with
1192        cultural adaptability : ISO English and ISO French lanuguage
1193                                  equivalency


1194   Temporary Notes:

1195   Note 1: The structure and format of the draft Annex A "Matrix" for ISO/IEC 15944-2 is based on that found in
1196           ISO/IEC 15944-1:2002. The purpose here is to facilitate the preparation as part of the FCD version of
1197           ISO/IEC 15944-2 its "Annex A (Normative) Consolidated list of terms and definitions with cultural
1198           adaptability: ISO English and ISO French language equivalency". For the purpose of convenience we have,
1199           where applicable, used separate rows between the definition itself and "Notes".

1200   Note 2: In this Annex A Matrix, we have also converted, where applicable, "organization(s)" to "Person(s)" where the
1201           ISO/IEC FCD 14662 standard is referenced. This Annex A Matrix represents a coordinated response to
1202           Canadian ballot comments on ISO/IEC CD 15944-2 and ISO/IEC FCD 14662 ballot comments.

1203   Note 3: The ISO English part of this Annex A Matrix should be considered as part of Canada's ballot comments of
1204           ISO/IEC CD 15944-2 and contains the proposed changes and additions to Clause 3.

1205   Note 4: The Annex A Matrix contains an added "Column 4x" in which are identified words found in the definition in
1206           col. 4 which are candidates for conversion into "bold" to indicate that they are defined terms in the ISO/IEC
1207           15944-2 standard. The Annex A Matrix contains an equivalent ISO French Column 6x" as a stakeholder for
1208           similar requirements from ISO French equivalency perspective.

1209   Note 5: Columns "4x" and "6x" titled "Candidate bold Terms" thus serve as a systematic working methodology for
1210           facilitating ISO/IEC 15944-2 reaching the FCD ballot stage as well as serving as quality control checks.
1211           Note: These "Candidate bold Terms" are cited in the singular.

1212   Note 6: Canada commits itself to preparing the currently missing ISO French terms and definitions. Canada will
1213           undertake this work based on the new version of ISO/IEC 15944-2 document resulting from the CD ballot
1214           resolution Editing Meeting, i.e., as part of the work required to bring ISO/IEC 15944-2 to FCD ballot
1215           document status.

1216   Note 7: In a nutshell, this Annex A Matrix is intended to serve as the base source document for the contents in
1217           ISO/IEC FCD 15944-2 for both:

1218                              Clause 3 "Terms and Definitions"; and,

1219                              "Annex A (Normative) Consolidated list of terms and definitions with cultural adaptability:
1220                               ISO English and ISO French language equivalency".

1221                      This can be accomplished by deleting Columns "4x" and "6x" in this Annex A Matrix and prior to
1222                      that utilizing the contexts of these two columns to ensure that at the words in the definitions in this
1223                      standard which represent defined terms in this standard displayed in bold in both Clause 3 of FCD
1224                      15944-2 and its Annex A (Normative).




                                                                                                                            A-1
1225   A.1 Introduction
1226   Users of this ISO/IEC 15944-2 standard may not have ready access to all standards referenced in either
1227   the ISO English language version or the ISO French language equivalent where available.

1228   This standard maximizes the use of existing standards where and whenever possible including relevant
1229   and applicable existing terms and definitions. This Annex A contains the consolidated list of the ISO
1230   English and ISO French language paired terms and definitions used in this standard including those
1231   terms and definitions introduced in this standard. The source is primarily Clause 3, Terms and
1232   Definitions, although some terms are defined in other clauses of ISO/IEC 15944-2.


1233   A.2 ISO English and ISO French
1234   This standard recognizes that the use of English and French as natural languages is not uniform or
1235   harmonized globally. (Other examples include use of Arabic, German, Portuguese, Russian, Spanish,
1236   etc., as natural languages in various jurisdictions).

1237   Consequently, the terms "ISO English" and "ISO French" are utilized here to indicate the ISO's
1238   specialized use of English and French as natural languages in the specific context of international
1239   standardization, i.e., as a "special language".


1240   A.3 Cultural adaptability and quality control

1241   ISO/IEC JTC1 has added "cultural adaptability" as the third strategic direction which all standards
1242   development work should support. The two other existing strategic directions are "portability" and
1243   "interoperability". Not all ISO/IEC JTC1 standards are being provided in more than one language, i.e., in
1244   addition to "ISO/IEC English," in part due to resource constraints.

1245   Terms and definitions are an essential part of a standard. This Annex serves to support the "cultural
1246   adaptability" aspects of standards as required by ISO/IEC JTC1. Its purpose is to ensure that if, for
1247   whatever reason, an ISO/IEC JTC1 standard is developed in one ISO/IEC "official" language only, at the
1248   minimum the terms and definitions are made available in more than one language. 6 A key benefit of
1249   translation of terms and definitions is that such work at providing bilingual/multilingual equivalency:

1250          should be considered a "quality control check" in that establishing an equivalency in another
1251           language ferrets out "hidden" ambiguities in the source language. Often it is only in the translation
1252           that ambiguities in the meaning, i.e., semantics, of the term/definition are discovered. Ensuring
1253           bilingual/multilingual equivalency of terms/definition should thus be considered akin to a minimum
1254           "ISO 9000-like" quality control check; and,

1255          is considered a key element in the widespread adoption and use of standards world-wide (especially
1256           by users of this standard who include those in various industry sectors, within a legal perspective,
1257           policy makers and consumer representatives, other standards developers, IT hardware and service
1258           providers, etc.).



           6
           Other ISO/IEC member bodies are encouraged to provide bilingual/multilingual equivalencies of terms/definitions
       for the language(s) in use in their countries.




       A-2
                                                                                ISO/IEC CD 15944-2 :2003




1259   A.4 Organization of Annex A consolidated list is in matrix form
1260   The terms/definitions are organized in matrix form in alphabetical order (English language). The columns
1261   in the matrix are as follows:

1262

             Col. No.           Use

             1                  ID as per ISO/IEC 15944-2 (3.n)

             2                  Source. International standard referenced or ISO/IEC 15944-2.

             3                  ISO English Language - Term

             4                  ISO English Language - Definition

             5                  ISO French Language - Term *

             6                  ISO French Language - Definition

1263

1264   The primary reason for organizing the columns in this order is to facilitate the addition of equivalent
1265   terms/definitions in other languages as added sets of paired columns, (e.g., Spanish, Japanese, German,
1266   Russian, etc.).

1267

1268   *       Use of an asterisk (*) in Column 5 indicates that the ISO standard referenced (other than ISO/IEC
1269           15944-2) in Column (5) does not have an ISO French language version. For these terms and
1270           definitions, ISO/IEC 15944-2 is providing the ISO French language equivalent

1271




                                                                                                            A-3
1272   A.5 Consolidated Annex A matrix
1273   ANNEX A TABLE NEEDS TO BE UPDATED TO INCLUDE ALL NEW TERMS IN CLAUSE 3

                Identification           ISO English Language                   ISO French Language
       Term           Source           Term           Definition             Term            Definition
        ID

        (1)           (2)             (3)                    (4)              (5)                  (6)
         1 adapted from WG1/N115 address         a set of data elements Adresse       série d'éléments de
                                                 that specifies a location            données servant à
                                                 to which an information              préciser l'emplacement
                                                 item(s), a business                  où on peut envoyer ou
                                                 object(s), a material                recevoir un élément
                                                 object(s) and/or a                   d'information, un objet
                                                 person(s) can be sent to             matériel, un objet
                                                 or received from                     d'affaires, ou une
                                                                                      personne
        *                          address        NOTE A location can adresse (suite) NOTE Une emplacement
                                   (cont'd)       be specified as either a            peut être specifier comme
                                                  physical or electronic              une emplacement
                                                  address.                            physique ou une adresse
                                                                                      électronique.
        2     ISO/IEC 14662        administration a member of a set of
                                   attribute      attributes to uniquely
                                                  identify an Open-edi
                                                  scenario, role,
                                                  information bundle, or
                                                  semantic component
                                                  and the relevant
                                                  Person responsible for
                                                  its maintenance
        *                          administration NOTE Administration
                                   attribute      attributes are used to
                                   (cont’d.)      specify information
                                                  pertaining to version,
                                                  replacement, status,
                                                  change history and
                                                  association as
                                                  appropriate for a
                                                  scenario, role,
                                                  information bundle, or
                                                  semantic component.
        2     ISO/IEC CD 15944-2   applicant      a Person which
              N0847 (3.1)                         requests the
                                                  assignment of a
                                                  register entry and
                                                  entry label




       A-4
                                                                           ISO/IEC CD 15944-2 :2003




         Identification              ISO English Language                       ISO French Language
Term           Source              Term           Definition                 Term            Definition
 ID

 (1)             (2)                 (3)                (4)                    (5)                (6)
  *                           applicant     NOTE A Person here
                              (cont'd)      as applicant can be an
                                            individual, organization
                                            or public administration.
 3     ISO/IEC 2382-17:1999   attribute     a characteristic of an    attribut        caractéristique d'un objet
       (??)                                 object or entity                          ou d'une entité

       ISO/IEC 11179-3:2002
       (3.1.3)
 4     ISO/IEC FCD            business      a series of processes, affaires           série de processus,
       14662:2002 N0830                     each having a clearly                     ayant chacun une finalité
       (3.1.2?)                             understood purpose,                       clairement définie,
                                            involving more than one                   impliquant plus d'une
                                            Person, realized                          Personne, réalisés par
                                            through the exchange of                   échange d'informations et
                                            information and directed                  tendant à
                                            towards some mutually                     l'accomplissement d'un
                                            agreed upon goal,                         objectif accepté par
                                            extending over a period                   accord mutuel pour une
                                            of time                                   certaine période de temps
 5     ISO/IEC FCD            Business      a perspective of         Vue              vue perspective sur les
       14662:2002 N0830       Operational   business transactions opérationnelle      transactions d'affaires,
       (3.1.3?)               View (BOV)    limited to those aspects des affaires     restreinte à ceux des
                                            regarding the making of (BOV, Business    aspects relatifs à la prise
                                            business decisions and Operational        par les Personnes de
                                            commitments among View)                   décisions et
                                            Persons, which are                        d'engagements
                                            needed for the                            concernant leurs affaires
                                            description of a                          qui sont nécessaires pour
                                            business transaction                      décrire une transaction
                                                                                      d'affaires




                                                                                                        A-5
         Identification            ISO English Language                        ISO French Language
Term           Source            Term           Definition                  Term            Definition
 ID

 (1)           (2)                (3)                    (4)                   (5)                (6)
  6 ISO/IEC FCD             business         a predefined set of       transaction   ensemble prédéterminé
     14662:2002 N0830       transaction      activities and/or         d'affaires    d'activités menées par
     (3.1.4?)                                processes of Persons                    des Personnes et/ou de
                                             which is initiated by a                 procédures qu'elles
                                             Person to accomplish                    suivent, déclenché par
                                             an explicitly shared                    une Personne qui vise à
                                             business goal and                       atteindre dans les affaires
                                             terminated upon                         un but expressément
                                             recognition of one of the               partagé, terminé
                                             agreed conclusions by                   lorsqu'est observée une
                                             all the involved Persons                des conclusions
                                             although some of the                    convenues par toutes les
                                             recognition may be                      Personnes prenantes,
                                             implicit.                               bien que cette observation
                                                                                     puisse être partiellement
                                                                                     implicite
       ISO/IEC CD 15944-2   classification a member of a set of
       N0847 (3.25)         attribute      attributes required to
                                           distinguish the
                                           functionality and
                                           adaptability of an Open-
                                           edi scenario
 *                          classification NOTE Classification
                            attribute      attributes are used to
                            (cont’d.)      provide convenient
                                           keys for retrieval of
                                           scenarios to the extent
                                           that they can be
                                           specified.
 7     ISO/IEC CD 15944-2   coded domain a domain for which (1)
       N0847 (3.4)                         the boundaries are
                                           defined and explicitly
                                           stated as a rulebase of
                                           a Source Authority;
                                           and, (2) each entity
                                           which qualifies as a
                                           member of that domain
                                           is identified through one
                                           or more codes, one of
                                           which must be an ID
                                           code




A-6
                                                                     ISO/IEC CD 15944-2 :2003




         Identification           ISO English Language                   ISO French Language
Term           Source           Term           Definition             Term            Definition
 ID

 (1)           (2)                 (3)               (4)               (5)                (6)
  * [based on 18022 &       coded domain NOTE 1 A coded
     18038 work]            (cont'd)     domain in turn can
                                         consist of two or more
                                         coded domains, i.e.,
                                         through the application
                                         of the inheritance
                                         principle of object
                                         classes.

                                         NOTE 2 In object
                                         methodology, entities
                                         which are members of a
                                         coded domain are
                                         referred to as instances
                                         of a class.
 8     ISO/IEC CD 15944-2   coded domain a Person, usually an
       N0847 (3.5)          Source       organization, which
                            Authority    sets the rules governing
                                         a coded domain
 *                          coded domain NOTE 1 For widely
                            Source       used coded domains
                            Authority    the coded domain
                            (cont'd)     Source Authority is
                                         often a jurisdiction.

                                          NOTE 2 Specific
                                          sectors, (e.g., banking,
                                          transport, geomatics,
                                          agriculture, etc.), may
                                          have particular coded
                                          domain Source
                                          Authority(ies) whose
                                          coded domains are
                                          used in many other
                                          sectors.

                                          NOTE 3 A coded
                                          domain Source
                                          Authority usually also
                                          functions as a
                                          Registration Authority
                                          but can use an agent,
                                          i.e., another Person, to
                                          execute the registration
                                          function on its behalf.




                                                                                                A-7
       Identification              ISO English Language                  ISO French Language
Term         Source              Term           Definition            Term            Definition
 ID

 (1)          (2)               (3)                     (4)             (5)                     (6)
  9 ISO/IEC 15944-1:2002    commitment    the making or accepting engagement      création ou acceptation
     (3.9)                                of a right, obligation,                 d'un droit, d'une
                                          liability or responsibility             obligation, d'une dette ou
                                          by a Person that is                     d'une responsabilité par
                                          capable of enforcement                  une Personne qui est
                                          in the jurisdiction in                  apte à appliquer la
                                          which the commitment                    juridiction conformément
                                          is made                                 à laquelle l'engagement
                                                                                  est pris
 10 ISO 5217:2000 (1.1.3.01) communication transfer of meaning by communication
                                           means of transmission
                                           of signals
 11 ISO/IEC CD 15944-2       composite     an identifier functioning
    N0847 (3.6)              identifier    as a single unique
                                           identifier consisting of
                                           one or more other
                                           identifiers, and/or one
                                           or more other data
                                           elements, whose
                                           interworking are rule-
                                           based




A-8
                                                                  ISO/IEC CD 15944-2 :2003




       Identification         ISO English Language                    ISO French Language
Term         Source         Term           Definition              Term            Definition
 ID

 (1)           (2)             (3)                (4)               (5)                (6)
  *                     composite    NOTE 1 Most widely
                        identifier   used composite
                        (cont'd)     identifiers consist of the
                                     combinations of:

                                     -   ID of the overall
                                         identification/numb
                                         ering schema,
                                         (e.g., ISO/IEC
                                         6532, ISO/IEC
                                         7812, ISO/IEC
                                         7506, UPC/EAN,
                                         ITU-R E.164, etc.),
                                         which is often
                                         assumed;

                                     -   the ID of the
                                         issuing
                                         organization (often
                                         based on a block
                                         numeric numbering
                                         schema); and,

                                     -   the ID of the
                                         entities forming
                                         part of members of
                                         each issuing
                                         organization.

                                     NOTE 2 Identifiers (in
                                     business transactions)
                                     are for the most part
                                     composite identifiers.




                                                                                             A-9
        Identification               ISO English Language                     ISO French Language
Term          Source               Term           Definition               Term            Definition
 ID

 (1)            (2)                  (3)                (4)                    (5)                (6)
 12 ISO/IEC CD 15944-2        computational the expression of a        intégrité     expression d'un norme
     N0847 (3.7)              integrity     standard in a form that informatique     sous une forme qui
                                            ensures precise                          assure la description
                                            description of behaviour                 précise du comportement
                                            and semantics in a                       et de la sémantique d'une
                                            manner that allows for                   façon qui permet un
                                            automated processing                     traitement automatique,
                                            to occur, and the                        ainsi que l'évolution gérée
                                            managed evolution of                     de ces normes d'une
                                            such standards in a                      manière qui permet une
                                            way that enables                         introduction dynamique
                                            dynamic introduction by                  par la génération suivante
                                            the next generation of                   de systèmes
                                            information systems                      informatiques
  * [original source: ISO/IEC computational NOTE Open-edi              intégrité     NOTE [French equivalent
    JTC1 Report on the        integrity     standards have been informatique         needs to be verified and
    Business Team on          (cont'd)      designed to be able to (suite)           NOTE added
    Electronic Commerce                     support computational
    Clause 6.2 (JTC1                        integrity requirements
    N5437)]                                 especially from a
                                            registration and re-use
                                            of business objects
                                            perspective.
 13 ISO/IEC 15944-1:2002 constraint         a rule, explicitly stated, contrainte    règle, énoncée
    (3.11)                                  that prescribes, limits,                 explicitement, qui prescrit,
                                            governs or specifies any                 limite, régit ou spécifie
                                            aspect of a business                     tout aspect d’une
                                            transaction                              transaction d'affaires




A-10
                                                                    ISO/IEC CD 15944-2 :2003




       Identification           ISO English Language                     ISO French Language
Term         Source           Term           Definition               Term            Definition
 ID

 (1)           (2)               (3)              (4)                   (5)                  (6)
  *                       constraint   NOTE 1 Constraints        contrainte    NOTE 1 Les contraintes
                          (cont'd)     are specified as rules (suite)          sont spécifiées comme
                                       forming part of                         des règles faisant partie
                                       components of Open-                     de composantes de
                                       edi scenarios, i.e., as                 scénarios d'EDI-ouvert, c.-
                                       scenario attributes,                    à-d. d'attributs de
                                       roles, and/or information               scénarios, de rôles, et/ou
                                       bundles.                                de faisceaux
                                                                               d'information.
                                       NOTE 2 For constraints
                                       to be registered for                    NOTE 2 Les contraintes
                                       implementation in                       doivent avoir des
                                       Open-edi, they must                     identificateurs uniques et
                                       have unique and                         non-ambigus afin d'être
                                       unambiguous                             enregistrées pour
                                       identifiers.                            application dans l'EDI-
                                                                               ouvert.
                                       NOTE 3 A constraint
                                       may be agreed to                        NOTE 3 Une contrainte
                                       among parties                           peut faire l'objet d'un
                                       (condition of contract)                 accord entre des parties
                                       and is therefore                        (clause du contrat), et est
                                       considered an "internal                 par conséquent
                                       constraint". Or a                       considérée comme
                                       constraint may be                       « contrainte interne ». Ou
                                       imposed on parties,                     une contrainte peut être
                                       (e.g., laws, regulations,               imposée à des parties
                                       etc.), and is therefore                 (par ex. des lois, des
                                       considered an "external                 règlements, etc.), et est
                                       constraint"                             par conséquent
                                                                               considérée comme une
                                                                               « contrainte externe ».
 14 CA comment on ISO/IEC Contact      an instance of a role of
    CD 15944-2 N0847                   a Person to whom an
    (6.A.9) (Adapted from              information item(s), a
    WG1 N115 and ISO/IEC               material object(s), a
    FDIS 11179-3:2002                  business object(s),
    (3.3.26)                           and/or natural persons
                                       (as either individual(s),
                                       or organization
                                       Person(s) can be sent
                                       to or received from in a
                                       specified context




                                                                                              A-11
       Identification           ISO English Language                ISO French Language
Term         Source           Term           Definition          Term            Definition
 ID

 (1)           (2)              (3)                (4)            (5)                (6)
  *                      Contact       NOTE 1 A Person here
                         (cont'd)      as a Contact can be an
                                       individual, an
                                       organization (or
                                       organization part or
                                       organization Person).

                                      NOTE 2 Contact is
                                      capitalized to
                                      distinguish it from the
                                      many ordinary uses of
                                      the word
 15 ISO/IEC CD 15944-2   Contact      the use of a specified
    N0847 (6.2.A.9.4)    facsimile    telephone address
                         number       designated for facsimile
                                      transmission purpose
                                      and utilized by the
                                      Person to register a
                                      scenario or scenario
                                      component
 16 ISO/IEC CD 15944-2   Contact      the physical address
    N0847 (6.2.A.2)      mailing      utilized by a Person
                         address      applying to register a
                                      scenario or scenario
                                      component
 17 ISO/IEC CD 15944-2   Contact name name by which a
    N0847 (6.2.A.1)                   Person wishes to be
                                      designated as a
                                      Contact
 *                       Contact name NOTE Where an
                         (cont'd)     organization is the
                                      applicant, it may
                                      designate an
                                      organization Person, an
                                      agent, or a third party
                                      as its Contact name in
                                      applying to register a
                                      scenario or scenario
                                      component
 18 ISO/IEC CD 15944-2   Contact      a specified telephone
    N0847 (6.2.A.9.3)    telephone    address utilized by the
                         number       Person applying to
                                      register a scenario or
                                      scenario component




A-12
                                                                                ISO/IEC CD 15944-2 :2003




         Identification               ISO English Language                          ISO French Language
Term           Source               Term           Definition                    Term            Definition
 ID

 (1)            (2)              (3)                        (4)                    (5)                  (6)
 19 WG1 N115, adapted from Contact title       title of the position held
     ISO/IEC FDIS 11179-                       by an organization
     3:2002 (3.3.29)                           Person as a Contact
 20 ISO/IEC 14662:1997     Decision            the model of that part of    Application à   modèle de la partie d'un
     (4.2.1)               Making              an Open-edi system           pouvoir de      système d'EDI-ouvert qui
                           Application         that makes decisions         décision (DMA, prend les décisions
                           (DMA)               corresponding to the         Decision Making correspondant au rôle ou
                                               role(s) that the Open-       Application)    aux rôles que joue le
                                               edi Party plays, as well                     partenaire d'EDI-ouvert;
                                               as originating, receiving                    elle est aussi source,
                                               and managing data                            récepteur et gestionnaire
                                               values contained in                          des valeurs des données
                                               instantiated                                 contenues dans les
                                               information bundles,                         instances de faisceaux
                                               which is not required to                     d'informations; elle n'a
                                               be visible to the other                      pas à être rendue visible
                                               Open-edi Party(ies)                          au(x) autre(s)
                                                                                            partenaire(s) d'EDI-
                                                                                            ouvert
 21 ISO/IEC 14662:1997         Decision       the set of requirements       Interface       ensemble des exigences
    (4.2.2)                    Making         that permit a Decision        d'application à permettant à une
                               Application    Making Application to         pouvoir de      application à pouvoir de
                               Interface (DMA interact with the Open-       décision        décision d'interagir avec
                               Interface)     edi Support                                   l'infrastructure de support
                                              Infrastructure                                d'EDI-ouvert
 22 ISO/IEC CD 15944-2         de facto       a natural language
    N0847 (3.8)                language       used in a jurisdiction
                                              which has the
                                              properties and
                                              behaviours of an
                                              official language in
                                              that jurisdiction without
                                              having formally been
                                              declared as such by
                                              that jurisdiction
 *     [based on 18038 work]   de facto       NOTE A de facto
                               language       language of a
                               (cont'd)       jurisdiction is often
                                              established through
                                              long term use and
                                              custom.
 23 ISO/IEC 1087-1:2000        definition     representation of a       définition          représentation d'un
    (3.3.1)                                   concept by a descriptive                      concept par un énoncé
                                              statement which serves                        descriptif permettant de la
                                              to differentiate it from                      différencier des concepts
                                              related concepts                              associés




                                                                                                           A-13
       Identification              ISO English Language                       ISO French Language
Term         Source              Term           Definition                 Term            Definition
 ID

 (1)          (2)                 (3)                 (4)                  (5)                        (6)
 24 ISO 1087-1:2000 (3.4.1) designation    representation of a     designation           représentation d'un
                                           concept by a sign which                       concept par un signe qui
                                           denotes it                                    le dénomme
 *                          designation    NOTE In terminology designation               NOTE Dans le travail
                            (cont'd)       work three types of     (suite)               terminologique on
                                           designations are                              distingue trois types de
                                           distinguished: symbols,                       désignation: les symboles,
                                           appellations and terms.                       les appellations et les
                                                                                         termes.
 25 ISO/IEC CD 15944-2      e-mail address a valid instance of an
    N0847 (6.2.A.9.5)                      electronic address
                                           based on a X.400,
                                           X.500 and/or IP
                                           directory
                                           schema/service
 26 ISO/IEC CD 15944-2      electronic     an address utilized in a
    N0847 (6.2.A.9)         address        recognized electronic
                                           addressing scheme,
                                           (e.g., telephone, telex,
                                           IP, etc.), to which
                                           information item(s)
                                           and/or business
                                           objects can be sent to
                                           or received from a
                                           Contact
 27 ISO/IEC FCD             Electronic     the automated              Echange de         échange automatisé de
    14662:2002 N0830        Data           exchange of any            Données            données structurées et
    (3.1.5?)                Interchange    predefined and             Informatisé        prédéfinies pour traiter
                            (EDI)          structured data for        (EDI, Electronic   des affaires entre les
                                           business purposes          Data               systèmes d'information de
                                           among information          Interchange)       deux ou plusieurs
                                           systems of two or more                        Personnes
                                           Persons
 *                          Electronic     NOTE This definition     Echange de           NOTE [French language
                            Data           inlcudes all categories  Données              equivalent of note,
                            Interchange    of electronic business   Informatisé          missing ????, noted
                            (EDI) cont'd   transactions.            (EDI, Electronic     02.09.04]
                                                                    Data
                                                                    Interchange)
                                                                    suite
 28 ISO/IEC 2382-17:1999    entity         any concrete or abstract entité               tout objet ou association
    (17.02.05)                             thing that exists, did                        d'objets, concret ou
                                           exist, or might exist,                        abstrait, existant, ayant
                                           including associations                        existé ou pouvant exister
                                           among these things




A-14
                                                                          ISO/IEC CD 15944-2 :2003




       Identification             ISO English Language                         ISO French Language
Term         Source             Term           Definition                   Term            Definition
 ID

 (1)           (2)                (3)                 (4)                     (5)                 (6)
  *                        entity (cont'd) EXAMPLE A person,          entité (suite)   EXEMPLE Personne,
                                           object, event, idea,                        événement, idée,
                                           process, etc.                               processus, etc.

                                         NOTE An entity exists                         NOTE Une entité existe
                                         whether data about it                         que l'on dispose de
                                         are available or not.                         données à son sujet ou
                                                                                       non.
 29 ISO/IEC CD 15944-2     entry label   the name information
    N0847 (3.2)                          uniquely associated
                                         with the identification of
                                         a registered Open-edi
                                         scenario or sub
                                         component of scenario
 30 ISO/IEC 15944-1:2002   external      a constraint which         contrainte         contrainte qui l'emporte
    (3.23)                 constraint    takes precedence over externe                 sur les contraintes
                                         internal constraints in                       internes dans une
                                         a business                                    transaction d'affaires, c.-
                                         transaction, i.e., is                         à-d. qui est externe à
                                         external to those agreed                      celles convenues entre
                                         upon by the parties to a                      les parties dans une
                                         business transaction                          transaction d'affaires
 *                         external      NOTE 1 Normally                               NOTE 1 Normalement ,
                           constraint    external constraints are                      les contraintes externes
                           (cont'd)      created by law,                               découlent des lois,
                                         regulation, orders,                           règlements, décrets,
                                         treaties, conventions or                      conventions, ou autres
                                         similar instruments.                          instruments semblables.

                                         NOTE 2 Other sources                          NOTE 2 D'autres sources
                                         of external constraints                       de contraintes externes
                                         are those of a sectorial                      sont de nature sectorielle,
                                         nature, those which                           qui relèvent d'une
                                         pertain to a particular                       juridiction particulière, ou
                                         jurisdiction or a mutually                    de conventions d'affaires
                                         agreed to common                              convenues mutuellement,
                                         business conventions,                         (par ex. INCOTERMS, les
                                         (e.g., INCOTERMS,                             échanges, etc.).
                                         exchanges, etc.).
                                                                                       NOTE 3 Des contraintes
                                         NOTE 3 External                               externes peuvent
                                         constraints can apply to                      s'exercer sur la nature des
                                         the nature of the good,                       biens, des services, et/ou
                                         service and/or right                          au droit accordé dans une
                                         provided in a business                        transaction d'affaires.
                                         transaction.




                                                                                                      A-15
       Identification         ISO English Language                  ISO French Language
Term         Source         Term           Definition            Term            Definition
 ID

 (1)           (2)             (3)               (4)              (5)                 (6)
  *                     external     NOTE 4 External                      NOTE 4 Des contraintes
                        constraint   constraints can demand               externes peuvent exiger
                        (cont'd)     that a party to a                    qu'une partie dans une
                                     business transaction                 transaction d'affaires
                                     meet specific                        réponde aux exigences
                                     requirements of a                    spécifiques d'un rôle.
                                     particular role.
                                                                          EXEMPLE 1 Seul un
                                     EXAMPLE 1 Only a                     médecin diplômé peut
                                     qualified medical doctor             prescrire une ordonnance
                                     may issue a prescription             pour un médicament
                                     for a controlled drug.               contrôlé.

                                     EXAMPLE 2 Only an                    EXEMPLE 2 Seul un
                                     accredited share dealer              courtier en actions
                                     may place transactions               accrédité peut effectuer
                                     on the New York Stock                des transactions à la
                                     Exchange.                            bourse de New York.

                                     EXAMPLE 3                            EXEMPLE 3 Seule une
                                     Hazardous wastes may                 entreprise attitrée peut
                                     only be conveyed by a                transporter des déchets
                                     licensed enterprise.                 dangereux.
 *                      external     NOTE 5 Where the                     NOTE 5 Lorsque les
                        constraint   information bundles                  faisceaux d'information, y
                        (cont'd)     (IBs), including their               compris leurs
                                     Semantic Components                  composantes
                                     (SCs) of a business                  sémantiques d'une
                                     transaction are also to              transaction d'affaires
                                     form the whole of a                  constituent l'ensemble
                                     business transaction,                d'une transaction
                                     (e.g., for legal or audit            d'affaires (par ex. à des
                                     purposes), all                       fins juridiques ou
                                     constraints must be                  comptables), toutes les
                                     recorded.                            contraintes doivent être
                                                                          enregistrées.
                                     EXAMPLE There may
                                     be a legal or audit                  EXEMPLE Il peut exister
                                     requirement to maintain              une exigence juridique ou
                                     the complete set of                  comptable de conserver la
                                     recorded information                 totalité des documents
                                     pertaining to a business             enregistrés relatifs à une
                                     transaction, i.e., as the            transaction d'affaires, c.-à-
                                     information bundles                  d. les faisceaux
                                     exchanged, as a                      d'information échangés,
                                     "record".                            ou les «enregistrements».




A-16
                                                                       ISO/IEC CD 15944-2 :2003




       Identification         ISO English Language                         ISO French Language
Term         Source         Term           Definition                   Term            Definition
 ID

 (1)           (2)             (3)                 (4)                   (5)                      (6)
  *                     external       NOTE 6 A minimum                             NOTE 6 Une contrainte
                        constraint     external constraint                          externe minimum
                        (cont'd)       applicable to a business                     applicable à une
                                       transaction often                            transaction d'affaires
                                       requires one to                              exige souvent de
                                       differentiate whether the                    distinguer si une
                                       Person, i.e., that is a                      Personne, c.-à-d. une
                                       party to a business                          partie dans une
                                       transaction, is an                           transaction d'affaires, est
                                       "individual",                                un « individu », une
                                       "organization", or                           « organisation », ou une
                                       "public administration".                     « administration
                                       For example, privacy                         publique ». Par ex., les
                                       rights apply only to a                       droits de protection de la
                                       Person as an                                 vie privée ne s'appliquent
                                       "individual".                                qu'à une Personne en tant
                                                                                    qu' « individu ».
 31 ISO/IEC FCD         Formal         a specification method      Technique de     méthode de spécification
    14662:2002 N0830    Description    based on a description      description      fondée sur un langage de
    (?3.1.6)            Technique      language using              formelle (FDT,   spécification faisant appel
                        (FDT)          rigorous and                Formal           à des règles rigoureuses
                                       unambiguous rules           description      et non ambiguës tant
                                       both with respect to        Technique)       pour le développement
                                       developing expressions                       d'expressions dans le
                                       in the language (formal                      langage (syntaxe
                                       syntax) and interpreting                     formelle) que pour
                                       the meaning of these                         l'interprétation de la
                                       expressions (formal                          signification de ces
                                       semantics)                                   expressions (sémantique
                                                                                    formelle)
 32 ISO/IEC FCD         Functional     a perspective of         Vue                 vue perspective sur les
    14662:2002 N0830    Service View   business transactions fonctionnelle          transactions d'affaires,
    (?3.1.7)            (FSV)          limited to those         des services        restreinte à ceux des
                                       information technology (FSV)                 aspects relatifs au
                                       interoperability aspects                     fonctionnement
                                       of IT Systems needed                         informatique coopératif
                                       to support the execution                     entre systèmes
                                       of Open-edi                                  d'information qui sont
                                       transactions                                 nécessaires à l'exécution
                                                                                    des transactions d'EDI-
                                                                                    ouvert




                                                                                                  A-17
         Identification          ISO English Language                  ISO French Language
Term           Source          Term           Definition            Term            Definition
 ID

 (1)           (2)                (3)                (4)             (5)                (6)
 33 ISO/IEC CD 15944-2     human        a representation of the
     N0847 (3.10)          interface    unambiguous and IT-
                           equivalent   enabled semantics of
                                        an IT interface
                                        equivalent (in a
                                        business transaction),
                                        often the ID code of a
                                        coded domain, in a
                                        formalized manner
                                        suitable for
                                        communication to and
                                        understanding by
                                        humans
 *     [based on 18022 &   human        NOTE 1 Human
       18038 work]         interface    interface equivalents
                           equivalent   can be linguistic or non-
                           (cont'd)     linguistic in nature.

                                        NOTE 2 In most cases
                                        there will be multiple
                                        human interface
                                        equivalent
                                        representations as
                                        required to meet
                                        localization
                                        requirements, i.e. those
                                        of a linguistic nature,
                                        jurisdictional nature
                                        and/or sectorial nature.

                                        NOTE 3 Human
                                        interface equivalents
                                        include representations
                                        in various forms or
                                        formats, (e.g., in
                                        addition to written text
                                        those of an audio,
                                        symbol (and icon)
                                        nature, glyphs, image,
                                        etc.)




A-18
                                                                         ISO/IEC CD 15944-2 :2003




       Identification             ISO English Language                        ISO French Language
Term         Source             Term           Definition                  Term            Definition
 ID

 (1)          (2)                 (3)                    (4)                  (5)                     (6)
 34 ISO/IEC 15944-1:2002   identifier (in   an unambiguous,           identificateur     valeur non ambiguë,
     (3.27)                business         unique and a              (dans une          unique et linguistiquement
                           transaction)     linguistically neutral    transaction        neutre, résultant de
                                            value, resulting from the d'affaires)        l'application d'un
                                            application of a rule-                       processus d'identification
                                            based identification                         à base de règles.
                                            process. Identifiers
                                            must be unique within                        Les identificateurs doivent
                                            the identification                           être uniques dans le
                                            scheme of the issuing                        système d'identification de
                                            authority                                    l'autorité émettrice
 35 ISO/IEC 14662:1997     Information      the formal description of Faisceau           description formelle de la
    (4.1.2.2)              Bundle (IB)      the semantics of the      d'informations     valeur sémantique des
                                            information to be         (IB, Information   informations échangées
                                            exchanged by Open- Bundle)                   entre partenaires d'EDI-
                                            edi Parties playing                          ouvert jouant un rôle dans
                                            roles in an Open-edi                         un scénario d'EDI-ouvert
                                            scenario
 36 ISO/IEC 14662:1997     Information      a set of one or more      système            ensemble constitué d'un
    (3.1.8)                Technology       computers, associated d'information (IT      ou de plusieurs
                           System (IT       software, peripherals, System)               ordinateurs, avec leurs
                           System)          terminals, human                             logiciels associés, de
                                            operations, physical                         périphériques, de
                                            processes, information                       terminaux, d'opérateurs
                                            transfer means, that                         humains, de processus
                                            form an autonomous                           physiques et de moyens
                                            whole, capable of                            de transfert d'information,
                                            performing information                       formant un tout autonome
                                            processing and/or                            capable de traiter
                                            information transfer                         l'information et/ou de la
                                                                                         transmettre
 37 ISO/IEC 15944-1:2002   internal         a constraint which     contrainte            contrainte qui fait partie
    (3.33)                 constraint       forms part of the      interne               de l'engagement
                                            commitment(s)                                convenu mutuellement
                                            mutually agreed to                           entre les parties d'une
                                            among the parties to a                       transaction d'affaires
                                            business transaction




                                                                                                        A-19
       Identification           ISO English Language                       ISO French Language
Term         Source           Term           Definition                 Term            Definition
 ID

 (1)           (2)              (3)                 (4)                  (5)                      (6)
  *                      internal      NOTE Internal              contrainte        NOTE Les contraintes
                         constraint    constraints are self-      interne (suite)   internes sont volontaires.
                         (cont'd)      imposed. They provide                        Elles présentent une vue
                                       a simplified view for                        simplifiée de modélisation
                                       modelling and re-use of                      et de réutilisation des
                                       scenario components of                       composantes de scénario
                                       a business transaction                       d'une transaction
                                       for which there are no                       d'affaires sans contraintes
                                       external constraints or                      ou restrictions externes
                                       restrictions to the nature                   quant à la conduite d'une
                                       of the conduct of a                          transaction d'affaires
                                       business transaction                         autres que celles
                                       other than those                             convenues mutuellement
                                       mutually agreed to by                        entre l'acheteur et le
                                       the buyer and seller.                        vendeur.
 38 ISO/IEC CD 15944-2   IT-enablement the transformation of a habilitation TI      transformation des
    N0847 (3.12)                       current standard utilized                    normes actuelles utilisées
                                       in business                                  dans les transactions
                                       transactions, (e.g.,                         d'affaires (par exemple,
                                       code tables), from a                         les tables de codes) de
                                       manual to                                    mode manuel en mode
                                       computational                                informatique, afin de
                                       perspective so as to be                      pouvoir assurer une
                                       able to support                              intégrité informatique et
                                       commitment exchange                          les engagement
                                       and computational                            échangés
                                       integrity
 39 ISO/IEC CD 15944-2   IT interface  a computer processable
    N0847 (3.13)         equivalent    identification of the
                                       unambiguous
                                       semantics of a scenario,
                                       scenario attribute
                                       and/or scenario
                                       component(s)
                                       pertaining to a
                                       commitment exchange
                                       in a business
                                       transaction which
                                       supports
                                       computational
                                       integrity




A-20
                                                                    ISO/IEC CD 15944-2 :2003




       Identification           ISO English Language                    ISO French Language
Term         Source           Term           Definition              Term            Definition
 ID

 (1)           (2)              (3)                  (4)              (5)                (6)
  *                      IT interface   NOTE 1 IT interface
                         equivalent     equivalents have the
                         (cont'd)       properties of identifiers
                                        (in business
                                        transaction) and are
                                        utilized to support
                                        semantic interoperability
                                        in commitment
                                        exchange.

                                        NOTE 2 An IT interface
                                        equivalent at times is a
                                        composite identifier.

                                        NOTE 3 An IT interface
                                        equivalent as a
                                        composite identifier can
                                        consist of the identifier
                                        of a coded domain plus
                                        an ID Code of that
                                        coded domain.

                                        NOTE 4 An IT Interface
                                        Value is independent of
                                        its encoding in
                                        programming
                                        languages or APIs.
 40 ISO/IEC CD 15944-2   JTC 1          an organization
    N0847 (3.14)         registration   appointed by the ISO
                         authority      and/or IEC Councils for
                                        the registration of
                                        entities? objects? in
                                        accordance with a JTC
                                        1 Procedure Standard

                                        [needs further work]




                                                                                           A-21
         Identification             ISO English Language                  ISO French Language
Term           Source             Term           Definition            Term            Definition
 ID

 (1)           (2)                 (3)                   (4)            (5)                (6)
 41 ISO/IEC                 jurisdiction    a distinct legal and/or
     JTC1/SC32/WG1N0210R                    regulatory framework
     2002-02-15 (supercedes                 which is a source of
     JTC1/BT-EC                             external constraints
                                            on Persons, their
       ISO/IEC CD 15944-2                   behaviour and the
       N0847 - CA comments                  making of
                                            commitments among
                                            Persons including any
                                            aspect of a business
                                            transaction
 *     [based on 18022 &     jurisdiction   NOTE 1 The pivot
       18038 work]           (cont'd)       jurisdiction is a United
                                            Nations (UN)
                                            recognized (or
                                            candidate) member
                                            state. Each state,
                                            (a.k.a. country) may
                                            have sub-administrative
                                            divisions as recognized
                                            jurisdictions, (e.g.,
                                            provinces, territories,
                                            cantons, länder, etc.),
                                            as decided by that
                                            state.

                                            NOTE 2 Several levels
                                            and categories of
                                            jurisdictions may exist
                                            within a jurisdiction.




A-22
                                                                     ISO/IEC CD 15944-2 :2003




       Identification             ISO English Language                   ISO French Language
Term         Source             Term           Definition             Term            Definition
 ID

 (1)           (2)                (3)                 (4)              (5)                     (6)
  *                        jurisdiction   NOTE 3 Jurisdictions
                           (cont'd)       can combine to form
                                          new jurisdictions
                                          through bilateral,
                                          multilateral and/or
                                          international
                                          agreements.

                                          EXAMPLE Included
                                          here, for example, are
                                          the European Union,
                                          NAFTA, WTO, WCO,
                                          ICAO, WHO, Red
                                          Cross, the ISO, the IEC,
                                          the ITU, etc.

                                         NOTE 4 Aspect of
                                         business transaction
                                         includes the making,
                                         selling, transfer of
                                         goods, services and/or
                                         rights (and resulting
                                         liabilities) and
                                         associated information.
 42 ISO 5127-1:2001        language      system of signs for
    (1.1.2.01)                           communication,
                                         usually consisting of a
                                         vocabulary and rules
 *                         language      NOTE In this standard,
                           (cont'd)      language refers to
                                         "natural languages" or
                                         "special languages" but
                                         not "programming
                                         languages".
 43 ISO 639-2:1998 (3.2)   language code combination of          codet de langue   combinaison de
                                         characters used to                        caractères utilisées pour
                                         represent a language                      représenter une langue
                                         or languages                              ou des langues
 *                         language code NOTE In this ISO/IEC codet de langue      NOTE [French
                           (cont'd)      15944-2 standard, the (suite)             equivalent required
                                         ISO 639-2T                                02.09.04]
                                         (terminology) three
                                         alpha-code, shall be
                                         used




                                                                                                 A-23
       Identification             ISO English Language                    ISO French Language
Term         Source             Term           Definition              Term            Definition
 ID

 (1)           (2)               (3)                   (4)                (5)                  (6)
 44 adapted form WG1 N115 location         a place, either physical emplacement   lieu, physique ou
                                           or electronic, that can                électronique, pouvant être
                                           be defined as an                       défini par une adresse
                                           address
 45 ISO 1087:1990 (5.3.1.3) name           designation of an         nom          désignation d'un objet
                                           object by a linguistic                 par une unité linguistique
                                           expression
 46 ISO 5217:2000 (1.1.2.02) natural       language which is or
                             language      was in active use in a
                                           community of people,
                                           and the rules of which
                                           are mainly deduced
                                           from the usage
 47 ISO/IEC 11179-1:1999    object class   a set objects. A set of
    (3.45)                                 ideas, abstractions, or
                                           things in the real world
                                           that can be identified
                                           with explicit boundaries
                                           and meaning and
                                           whose properties and
                                           behavior follow the
                                           same rules
 48 ISO/IEC CD 15944-2      official       an external constraint
    N0847 (3.16)            language       in the form of a natural
                                           language specified by a
                                           jurisdiction for official
                                           use by Persons forming
                                           part of and/or subject to
                                           that jurisdiction for use
                                           in communication(s)
                                           either (1) with that
                                           jurisdiction; and/or, (2)
                                           among such Persons,
                                           where such
                                           communications are
                                           recorded information
                                           involving
                                           commitment(s)




A-24
                                                                     ISO/IEC CD 15944-2 :2003




       Identification             ISO English Language                   ISO French Language
Term         Source             Term           Definition             Term            Definition
 ID

 (1)           (2)                 (3)              (4)                (5)                (6)
  * [based on 18022 &      official      NOTE 1 Unless official
     18038 work, and WG1   language      language requirements
     N210R]                (cont'd)      state otherwise,
                                         Persons are free to
                                         choose their mutually
                                         acceptable natural
                                         language and/or special
                                         language for
                                         communications as well
                                         as exchange of
                                         commitments.

                                         NOTE 2 An official
                                         language(s) can be
                                         mandated for formal
                                         communications as well
                                         as provision of goods
                                         and services to Persons
                                         subject to that
                                         jurisdiction and for use
                                         in the legal and other
                                         conflict resolution
                                         system(s) of that
                                         jurisdiction, etc. Where
                                         applicable, it may be
                                         required in the exercise
                                         of rights and obligations
                                         of individuals in that
                                         jurisdiction.




                                                                                            A-25
       Identification          ISO English Language                  ISO French Language
Term         Source          Term           Definition            Term            Definition
 ID

 (1)           (2)              (3)                (4)             (5)                (6)
  *                     official      NOTE 3 Where an
                        language      official language of a
                        (cont'd)      jurisdiction has a
                                      controlled vocabulary of
                                      the nature of a
                                      terminology, it may well
                                      have the characteristics
                                      of a special language.
                                      In such cases, the
                                      terminology to be used
                                      shall be specified.

                                      NOTE 4 For an official
                                      language, the writing
                                      system(s) to be used
                                      shall be specified,
                                      where the spoken use
                                      of a natural language
                                      has more than one
                                      writing system.

                                      EXAMPLE 1 The
                                      spoken language of use
                                      of an official language
                                      may at times have more
                                      than one writing system.
                                      For example, three
                                      writing systems exist for
                                      the Inuktitut language.
                                      Canada uses two of
                                      these writing systems,
                                      namely, a Latin-1 based
                                      (Roman), the other is
                                      syllabic-based. The
                                      third is used in Russia
                                      and is Cyrillic based.




A-26
                                                                  ISO/IEC CD 15944-2 :2003




       Identification          ISO English Language                   ISO French Language
Term         Source          Term           Definition             Term            Definition
 ID

 (1)           (2)              (3)              (4)                (5)                (6)
  *                     official      EXAMPLE 2 Another
                        language      spoken language with
                        (cont'd)      two writing systems is
                                      that of Serbian and
                                      Croatian. They are the
                                      same spoken language
                                      but the former is written
                                      using the Cyrillic
                                      alphabet and the latter
                                      as the Latin-1 (Roman)
                                      alphabet.

                                      NOTE 5 A jurisdiction
                                      may have more than
                                      one official language
                                      but these may or may
                                      not have equal status.

                                      EXAMPLE Canada has
                                      two official languages,
                                      Switzerland has three,
                                      while the Union of
                                      South Africa has eleven
                                      official languages.
 *                      official      NOTE 6 The BOV
                        language      requirement of the use
                        (cont'd)      of a specific language
                                      will place that
                                      requirement on any
                                      FSV supporting service.

                                      EXAMPLE A BOV
                                      requirement of Arabic,
                                      Chinese, Russian,
                                      Japanese, Korean, etc.,
                                      as an official language
                                      requires the FSV
                                      support service to be
                                      able to handle the
                                      associated character
                                      sets.

                                      NOTE 7 A jurisdiction
                                      decides whether of not
                                      it has an official
                                      language.




                                                                                         A-27
       Identification           ISO English Language                      ISO French Language
Term         Source           Term           Definition                Term            Definition
 ID

 (1)            (2)             (3)                  (4)                  (5)                   (6)
 49 ISO/IEC CD 15944-2   Open-edi       an unambiguously          objet d'affaires
     N0847 (3.3)         business       identified, specified,
                         object         referenceable,
                                        registered and re-
                                        useable Open-edi
                                        scenario or scenario
                                        component of a
                                        business transaction
 50 ISO/IEC 14662:1997   Open-edi       a specification method Technique de          méthode de spécification,
    (4.1.1)              Description    such as a Formal          description        technique de
                         Technique      Description               d'EDI-ouvert       description formelle, ou
                         (OeDT)         Technique, another                           toute autre technique
                                        methodology having the                       ayant les caractéristiques
                                        characteristics of a                         d'une technique de
                                        Formal Description                           description formelle, ou
                                        Technique, or a                              combinaison de ces
                                        combination of such                          techniques, permettant de
                                        techniques as needed                         spécifier formellement les
                                        to formally specify BOV                      concepts de la BOV sous
                                        concepts, in a computer                      forme calculable par un
                                        processible form                             ordinateur
 51 ISO/IEC FCD          Open-edi Party a Person that             Partenaire         Personne participant à
    14662:2002 N0830     (OeP)          participates in Open-     d'EDI-ouvert       l'EDI-ouvert
    (3.1.11?)                           edi.                      (OeP, Open-edi
                                                                  Party)
 *                       Open-edi Party NOTE Often in this        Partenaire         NOTE Dans la norme
                         (OeP) cont'd ISO/IEC 15944-1             d'EDI-ouvert       ISO/CEI 15944-1, souvent
                                        standard referred to      (OeP, Open-edi     mentionnée de façon
                                        generically as "party" or Party) suite       générique comme
                                        "parties" for any entity                     « partie » ou « parties »
                                        modelled as a Person                         pour toute entité
                                        as playing a role in                         modélisée comme une
                                        Open-edi scenarios.                          Personne jouant un rôle
                                                                                     dans les scénarios d'EDI-
                                                                                     ouvert.
 52 ISO/IEC CD 15944-2   Open-edi         the information within a
    N0847 (3.21)         registry entry   registry relating to a
                                          specific Open-edi
                                          scenario or component
                                          of scenario including
                                          linkage information to a
                                          scenario content




A-28
                                                                         ISO/IEC CD 15944-2 :2003




       Identification            ISO English Language                        ISO French Language
Term         Source            Term           Definition                  Term            Definition
 ID

 (1)           (2)              (3)                   (4)                  (5)                     (6)
 53 ISO/IEC FCD            Open-edi       a formal specification of scénario d'EDI-   spécification formelle
     14662:2002 N0830      scenario       a class of business       ouvert            d'une classe de
     (3.1.12?)                            transactions having the                     transactions d'affaires
                                          same business goal                          partageant le même
                                                                                      objectif d'affaires
 54 ISO 639-2T             Open-edi       The ISO 639-2T
                           Scenario       language code for the
                           Language       natural language used
                           Code           for specifying an Open-
                                          edi Scenario


 55 ISO/IEC 6523-1: 1998   organization   a unique framework of organisation          cadre unique d'autorité
    (3.1)                                 authority within which a                    dans lequel une ou
                                          person or persons act,                      plusieurs personnes
                                          or are designated to act,                   agissent ou sont
                                          towards some purpose                        désignées pour agir afin
                                                                                      d'atteindre un certain but
 *                         organization   NOTE The kinds of          organisation     NOTE Les types
                           (cont'd)       organizations covered      (suite)          d'organisations couverts
                                          by this International                       par la présente partie de
                                          Standard include the                        l'ISO/CEI 6523
                                          following examples:                         comprennent par exemple
                                                                                      les éléments suivants:
                                          EXAMPLE 1 An
                                          organization                                EXEMPLE 1
                                          incorporated under law.                     Organisations constituées
                                                                                      suivant des formes
                                          EXAMPLE 2 An                                juridiques prévues par la
                                          unincorporated                              loi.
                                          organization or activity
                                          providing goods and/or                      EXEMPLE 2 Autres
                                          services including:                         organisations ou activités
                                                                                      fournissant des biens
                                          1) partnerships;                            et/ou des services, tels
                                                                                      que

                                                                                      1) sociétés en
                                                                                         participation;




                                                                                                    A-29
       Identification            ISO English Language                      ISO French Language
Term         Source            Term           Definition                Term            Definition
 ID

 (1)           (2)                (3)                (4)                  (5)                (6)
  *                        organization   2) social or other non- organisation   2) organismes sociaux
                           (cont'd)          profit organizations (suite)           ou autres à but non
                                             or similar bodies in                   lucratif dans lesquels
                                             which ownership or                     le droit de propriété
                                             control is vested in                   ou le contrôle est
                                             a group of                             dévolu à un groupe
                                             individuals;                           de personnes;

                                          3) sole proprietorships                3) entreprises
                                                                                    individuelles;
                                          4) governmental
                                             bodies                              4) administrations et
                                                                                    organismes de l'état
                                          EXAMPLE 3 Groupings
                                          of the above types of                  EXEMPLE 3
                                          organizations where                    Regroupements des
                                          there is a need to                     organisations des types
                                          identify these in                      ci-dessus, lorsqu'il est
                                          information interchange.               nécessaire de les
                                                                                 identifier pour l'échange
                                                                                 d'informations.
 56 ISO/IEC 15944-1:2002   Person         an entity, i.e., a natural Personne    entité, c-à-d. une
    (3.47)                                or legal person,                       personne physique ou
                                          recognized by law as                   morale, reconnue par la
                                          having legal rights and                loi comme ayant des
                                          duties, able to make                   droits et des devoirs,
                                          commitment(s),                         capable de faire des
                                          assume and fulfil                      engagements, d'assumer
                                          resulting obligation(s),               et de remplir les
                                          and able of being held                 obligations résultantes, et
                                          accountable for its                    capable d'être tenue
                                          action(s)                              responsable de ses
                                                                                 actions




A-30
                                                                    ISO/IEC CD 15944-2 :2003




       Identification             ISO English Language                  ISO French Language
Term         Source             Term           Definition            Term            Definition
 ID

 (1)           (2)                (3)                 (4)               (5)                 (6)
  *                        Person        NOTE 1 Synonyms for Personne (suite) NOTE 1 Parmi les
                           (cont'd)      "legal person" include               synonymes de «personne
                                         "artificial person", "body           morale», on trouve
                                         corporate", etc.,                    «personne juridique»,
                                         depending on the                     «personne fictive»,
                                         terminology used in                  «corporation», etc., selon
                                         competent jurisdictions.             la terminologie utilisée par
                                                                              les juridictions
                                         NOTE 2 Person is                     compétentes.
                                         capitalized to indicate
                                         that it is being utilized            NOTE 2 « Personne »
                                         as formally defined in               prend la majuscule pour
                                         the standards and to                 indiquer que ce terme est
                                         differentiate it from its            utilisé tel que défini
                                         day-to-day use.                      officiellement dans les
                                                                              normes et pur le
                                         NOTE 3 Minimum and                   différencier de son usage
                                         common external                      ordinaire.
                                         constraints applicable to
                                         a business transaction               NOTE 3 Les exigences
                                         often require one to                 minima et communes
                                         differentiate among                  applicables aux
                                         three common subtypes                transaxtions d'affaires
                                         of Person, namely                    obligent souvent à faire
                                         "individual",                        une différence entre les
                                         "organization", and                  trois sous-catégories
                                         "public administration".             communes de « Personne
                                                                              », notamment « individu »,
                                                                              « organisation », «
                                                                              administration publique».
 57 ISO/IEC 15944-1:2002   persona       the set of data elements persona     série d'éléments de
    (3.51)                               and their values by                  données et leurs valeurs
                                         which a Person wishes                selon lesquelles une
                                         to be known and thus                 Personne désire être
                                         identified in a business             connue et ainsi identifiée
                                         transaction                          dans une transaction
                                                                              d'affaires




                                                                                              A-31
         Identification               ISO English Language                     ISO French Language
Term           Source               Term           Definition               Term            Definition
 ID

 (1)         (2)                     (3)                 (4)                 (5)                    (6)
 58 WG1 N115                   physical      an address that is        adresse
                               address       used/recognized by a      physique
       ISO/IEC CD 15944-2                    postal authority and/or
       N0847 (6.2.                           courier service to
                                             deliver information
       A.9)                                  item(s), material
                                             object(s), or business
                                             object(s) to a Contact
                                             at either an actual
                                             address or a pick-up
                                             point address, (e.g.,
                                             P.O. Box, rural route,
                                             etc.)
 59 ISO/IEC CD 15944-2         principle     a fundamental, primary    principe         hypothèse fondamentale
    N0847 (3.16)                             assumption and quality                     et primaire, et qualité qui
                                             which constitutes a                        constitue une source
                                             source of action                           d'action pour déterminer
                                             determining particular                     des objectifs ou des
                                             objectives or results                      résultats particuliers
 *     [based on 18038 work]   principle     NOTE 1 A principle is     principe (suite) NOTE 1 Un principe est
                               (cont'd)      usually enforced by                        normallement...[translation
                                             rules that affect its                      missing]
                                             boundaries.
                                                                                        NOTE 2 Un principe
                                             NOTE 2 A principle is                      s'appuie généralement sur
                                             usually supported                          une ou plusieurs règles.
                                             through one or more
                                             rules.
 60 ISO/IEC 15944-1:2002       process       a series of actions or   processus         série d'actions ou
    (3.53)                                   events taking place in a                   d'événements qui se
                                             defined manner leading                     produisent d'une manière
                                             to the accomplishment                      définie et qui aboutissent
                                             of an expected result                      à un résultat attendu
 61 ISO/IEC 15944-1:2002       recorded      any information that is information        toute information
    (3.56)                     information   recorded on or in a      enregistrée       enregistrée sur ou dans
                                             medium irrespective of                     un support quelle que soit
                                             form, recording medium                     sa forme, le support de
                                             or technology utilized,                    stockage ou la
                                             and in a manner                            technologie utilisés, et de
                                             allowing for storage and                   façon à permettre son
                                             retrieval                                  stockage et son extraction




A-32
                                                                        ISO/IEC CD 15944-2 :2003




       Identification           ISO English Language                        ISO French Language
Term         Source           Term           Definition                  Term            Definition
 ID

 (1)           (2)              (3)                 (4)                   (5)                    (6)
  *                      recorded       NOTE 1 This is a          information      NOTE 1 Cette définition
                         information    generic definition and is enregistrée      est générique et
                         (cont'd)       independent of any        (suite)          indépendante de toute
                                        ontology, (e.g., those of                  ontologie (par exemple le
                                        "facts" versus "data"                      point de vue des «faits»
                                        versus "information"                       par rapport aux
                                        versus "intelligence"                      «données», à
                                        versus "knowledge",                        «l'information», aux
                                        etc.).                                     «renseignements», à la
                                                                                   «connaissance», etc.
 *                       recorded       NOTE 2 Through the          information    NOTE 2 Dans l'utilisation
                         information    use of the term             enregistrée    du terme «information»,
                         (cont'd)       "information," all          (suite)        tous les attributs de ce
                                        attributes of this term                    terme sont hérités dans
                                        are inherited in this                      cette définition.
                                        definition.
 *                       recorded       NOTE 3 This definition      information    NOTE 3 Cette définition
                         information    covers:                     enregistrée    couvre les élément
                         (cont'd)                                   (suite)        suivants :
                                        (i) any form of
                                            recorded                               (i) toute forme
                                            information, means                         d'information
                                            of recording, and                          enregistrée, tout
                                            any medium on                              moyen
                                            which information                          d'enregistrement, et
                                            can be recorded;                           tout support sur
                                            and,                                       lequel l'information
                                                                                       peut être enregistrée;
                                         (ii)    all types of                          et,
                                        recorded information
                                        including all data types,                  (ii)     tous types
                                        instructions or software,                  d'information enregistrée,
                                        databases, etc.                            y compris tous les types
                                                                                   de données, instructions
                                                                                   ou logiciels, bases de
                                                                                   données, etc.
 62 ISO/IEC CD 15944-2   registration   a rule-based process,
    N0847 (3.20)                        explicitly stated,
                                        involving the use of one
                                        or more data elements,
                                        whose value (or
                                        combination of values)
                                        are used to identify
                                        uniquely the results of
                                        assigning a registry
                                        entry




                                                                                                 A-33
       Identification            ISO English Language                        ISO French Language
Term         Source            Term           Definition                  Term            Definition
 ID

 (1)          (2)                (3)                  (4)                   (5)                    (6)
 63 ISO/IEC 15944-1:2002   Registration   a Person responsible       organisme        Personne responsable du
     (3.57)                Authority (RA) for the maintenance of     d'enregistrement maintien d'un ou de
                                          one or more                                 plusieurs schémas
                                          Registration Schemas                        d'enregistrement, y
                                          including the                               compris l'attribution d’un
                                          assignment of a unique                      identificateur unique
                                          identifier for each                         pour chaque entité
                                          recognized entity in a                      reconnue d'un schéma
                                          Registration Schema                         d'enregistrement
 64 ISO/IEC 14662:1997     role           a specification which      rôle             spécification qui modélise
    (4.1.2.1)                             models an external                          le comportement externe
                                          intended behaviour (as                      attendu d'un partenaire
                                          allowed within a                            d'EDI-ouvert dans le
                                          scenario) of an Open-                       cadre permis par un
                                          edi Party                                   scenario
 65 ISO/IEC CD 15944-2     rule           a statement governing      règle            énoncé régissant une
    N0847 (3.23)                          conduct, procedure,                         conduite, une procédure,
                                          conditions and relations                    des conditions ou des
                                                                                      rapports




A-34
                                                                       ISO/IEC CD 15944-2 :2003




       Identification              ISO English Language                    ISO French Language
Term         Source              Term           Definition              Term            Definition
 ID

 (1)           (2)                 (3)                  (4)              (5)                   (6)
  * [based on 18038 work]   rule (cont'd)   NOTE 1 Rules specify règle (suite)    NOTE 1 Les règles
                                            conditions that must be               spécifient les rapports
                                            complied with. These                  entre les objets et leurs
                                            may include relations                 attributs.
                                            among objects and their
                                            attributes.                           NOTE 2 Les règles sont
                                                                                  de nature obligatoire ou
                                            NOTE 2 Rules are of a                 conditionnelle.
                                            mandatory or
                                            conditional nature.                   NOTE 3 Les règles
                                                                                  spécifient formellement
                                            NOTE 3 In Open-edi                    les engagements et le(s)
                                            rules formally specify                rôle(s) des parties
                                            the commitment(s) and                 concernées, et le(s)
                                            role(s) of the parties                comportement(s) prévu(s)
                                            involved, and the                     des parties concernées
                                            expected behaviour(s)                 tels que perçus par
                                            of the parties involved               d'autres parties
                                            as seen by other parties              concernées par des
                                            involved in (electronic)              transactions
                                            business transactions.                (électroniques) d'affaires.
                                            Such rules are applied                Ces règles s'appliquent
                                            to:                                   aux éléments suivants:

                                            -   content of the                    -   contenu des flux
                                                information flows in                  d'information sous
                                                the form of precise                   forme de signification
                                                and computer-                         précise et traitable
                                                processable                           par ordinateur, c-à-d.
                                                meaning, i.e. the                     la sémantique des
                                                semantics of data;                    données; et,
                                                and,
                                                                                  -   l'ordre et le
                                            -   the order and                         comportement des
                                                behaviour of the                      flux d'informaiton
                                                information flows                     eux-mêmes
                                                themselves.




                                                                                                 A-35
       Identification           ISO English Language                      ISO French Language
Term         Source           Term           Definition                Term            Definition
 ID

 (1)           (2)              (3)                  (4)                (5)                  (6)
  *                      rule (cont'd)   NOTE 4 Rules must be                   NOTE 4 Les règles
                                         clear and explicit                     doivent être suffisamment
                                         enough to be                           claires et explicites pour
                                         understood by all                      être comprises par toutes
                                         parties to a business                  les parties d'une
                                         transaction. Rules also                transaction d'affaires. En
                                         must be capable of                     même temps, les règles
                                         being able to be                       doivent pouvoir être
                                         specified using a using                spécifiees en utilisant une
                                         a Formal Description                   ou des technique(s) de
                                         Technique(s) (FDTs).                   description formelle(s)
                                                                                (FDT).
                                         EXAMPLE A current
                                         and widely used FDT is                 EXEMPLE L'une des
                                         "Unified Modelling                     techniques de description
                                         Language (UML)".                       formelles actuellement et
                                                                                couramment utilisées est
                                                                                l'UML (Langage de
                                                                                modélisation unifié ou
                                                                                Unified Modelling
                                                                                Language).
 66 ISO/IEC CD 15944-2   rulebase       a set of rules which
    N0847 (new draft)                   interwork and which
                                        together form an
                                        autonomous whole
 *                       rulebase       NOTE One considers a
                         (cont'd)       rulebase to be to rules
 67 ISO/IEC CD 15944-2   scenario       as database is to data.
    N0847 (3.24)         administration a set of attributes to
                         attribute      uniquely identify the
                                        scenario and the
                                        relevant Person
                                        responsible for the
                                        maintenance
 68 ISO/IEC 14662:1997   scenario       the formal specification attribut de    spécification formelle
    (4.1.2.3)            attribute      of information, relevant scénario       d'une information d'intérêt
                                        to an Open-edi                          pour la globalité d'un
                                        scenario as a whole,                    scénario d'EDI-ouvert,
                                        which is neither specific               qui ne ressortit
                                        to roles nor to                         spécifiquement ni aux
                                        information bundles                     rôles ni aux faisceaux
                                                                                d'informations




A-36
                                                                       ISO/IEC CD 15944-2 :2003




       Identification           ISO English Language                       ISO French Language
Term         Source           Term           Definition                 Term            Definition
 ID

 (1)           (2)            (3)                    (4)                 (5)                (6)
 70 ISO/IEC CD 15944-2   scenario        a reusable set of
     N0847 (3.26)        component       functional components
                                         combined together to
                                         satisfy a set of identified
                                         Open-
 71 ISO/IEC CD 15944-2   scenario        a set of recorded
    N0847 (3.27)         content         information containing
                                         registry entry
                                         identifiers, labels and
                                         their associated
                                         definitions and related
                                         information posted (or
                                         reposted) in any
                                         registry for business
                                         objects
 72 ISO/IEC CD 15944-2   scenario        a set of attributes to
    N0847 (3.28)         contents        specify the scenario
                         attribute       contents

                         scenario        a member of a set of
                         specification   attributes to specify the
                         attribute       scenario content in a
                                         registry

 *                       scenario        NOTE Scenario
                         specification   specification attributes
                         attribute       ensure that all the
                         (cont’d.)       information required for
                                         the Business
                                         Operational View
                                         (BOV) of an Open-edi
                                         Scenario, its
                                         components and all
                                         attributes required to be
                                         specified, (and
                                         registered for re-use)
                                         are captured in a
                                         systematic and explicit
                                         manner.




                                                                                              A-37
       Identification          ISO English Language                    ISO French Language
Term         Source          Term           Definition              Term            Definition
 ID

 (1)           (2)            (3)                 (4)                 (5)                     (6)
 73 ISO/IEC 14662:1997   Semantic     a unit of recorded        Composant       unité d'information
     (4.1.2.2)           Component    information               sémantique      enregistrée définie de
                         (SC)         unambiguously             (SC, Semantic   manière non ambiguë
                                      defined in the context of Component)      dans le contexte de
                                      the business goal of                      l'objectif d'affaires de la
                                      the business                              transaction d'affaires
                                      transaction
                                                                                Un SC peut être atomique
                                      NOTE A SC may be                          ou composé d'autres SC.
                                      atomic or composed of
                                      other SCs.
 74 ISO/IEC CD 15944-2   Source       a Person recognized by
    N0847 (new draft)    Authority    other Persons as the
                                      authoritative source for
                                      a set of constraints
 *                       Source       NOTE 1 A Person as a
                         Authority    Source Authority for
                         (cont'd)     internal constraints may
                                      be an individual or
                                      organization.

                                      NOTE 2 A Person as
                                      Source Authority for
                                      external constraints
                                      may be an organization
                                      or public administration.

                                      EXAMPLE In the field
                                      of air travel and
                                      transportation, IATA as
                                      a Source Authority, is
                                      an "organization" while
                                      ICAO as a Source
                                      Authority, is a "public
                                      administration".

                                      NOTE 3 A Person as
                                      an individual shall not
                                      be a Source Authority
                                      for external constraints.




A-38
                                                                                 ISO/IEC CD 15944-2 :2003




                Identification                ISO English Language                   ISO French Language
       Term           Source                Term           Definition             Term            Definition
        ID

        (1)            (2)                    (3)               (4)                (5)                 (6)
        75 ISO/IEC CD 15944-2           telephone    a valid instance of an
            N0847 (6.2.A.9)             address      electronic address in a
                                                     directory
              ITU-T Rec. E.164 (1997)                schema/service based
                                                     on ITU Rec. E164, i.e.,
                                                     a string or combination
                                                     of     decimal    digits,
                                                     symbols, and additional
                                                     information        which
                                                     identifies the specific
                                                     termination point(s) of a
                                                     connection in a public
                                                     network(s) or, where
                                                     applicable,            in
                                                     interconnected private
                                                     network(s)


        76 ISO/IEC 15944-1:2002         unambiguous the level of certainty  non-ambigu      niveau de certitude et
           (3.66)                                   and explicitness                        d'explicité exigé dans la
                                                    required in the                         complétude de la
                                                    completeness of the                     sémantique d'une
                                                    semantics of the                        information enregistrée
                                                    recorded information                    et échangée dans le but
                                                    interchanged                            d'une transaction
                                                    appropriate to the goal                 d'affaires
                                                    of a business
                                                    transaction
1274




                                                                                                          A-39
                                                                                                                        ISO/IEC CD 15944-2 :2003




1275                                            Annex B (normative): Registration matrix


1276   Administration and scenario specification attributes of Open-edi Scenarios and their components are consolidated in this normative annex.
1277   Reference is made to Open-edi Scenario Component ID Codes in the ISO/IEC 15944-1, 9.2.3, Consolidated template of attributes of Open-edi
1278   scenarios, roles and information bundles. It should be noted that relatively few administration attributes reference Open-edi Scenario Component
1279   ID Codes, because administration attributes serve registration administration purposes only, and are not considered to be descriptive
1280   characteristics of a scenario or scenario component. The application of such administration attributes to scenario, role, information bundle, or
1281   semantic component is indicated by X in the registration matrix.

1282   Two of the scenario specification attributes are coded domains corresponding to their Open-edi Scenario Component ID Code. For example, the
1283   coded domain for Processing Model, having an Open-edi Scenario Component ID Code of 2600 consists of 00 for Other, 01 for Real-time and 02
1284   for Batch.

1285

                                   Attributes                             Scenario          Role             Information       Semantic
                                                                                                             Bundle            Component
       Administration Attributes                                                        Open-edi Scenario Component ID Code

       A.1
       A.1 Identifier                                                     X                 X                X                 X
       A.2 Version Number                                                 X                                  X                 X
       A.3 Registration Name                                              2020              3010             4020              5020
       A.4 Change Type                                                    X                                  X                 X
       A.5 Change Date                                                    X                                  X                 X
       A.6 Change Description                                             X                                  X                 X
       A.7 Application Number                                             X                                  X                 X
       A.8 Application Date                                               X                                  X                 X




                                                                                                                                                   B-1
                            Attributes         Scenario   Role   Information   Semantic
                                                                 Bundle        Component
A.9 Applicant Name                             X                 X             X
A.10   Reference                               X                 X             X
A.11   Registration Contact Name               X                 X             X
A.12   Registration Contact Mailing Address    X                 X             X
A.13   Registration Contact Telephone Number   X                 X             X
A.14   Registration Contact Facsimile Number   X                 X             X
A.15   Registration Contact email Address      X                 X             X
A.16   Author                                  X                 X             X
A.17   Expected User Community                 X
A.18   Related Regulation                      2070
A.19   Intellectual Property Right             X
A.20   Restriction                             X
A.21   Inheritance                             2080       3030
A.22   Cross-References                        2080       3030   2140          2150, 4090
A.23   OeS Language Code                       X
A.24   OeDT Used                               X
A.25   Repository Location                     X                 X             X
A.26   Registrar                               X                 X             X
A.27   Registration Authority                  X                 X             X
A.28   Replacement Description                 X                 X             X
A.29   Replacement Date                        X                 X             X




B-2
                                                                                                    ISO/IEC CD 15944-2 :2003




                           Attributes                                Scenario       Role   Information    Semantic
                                                                                           Bundle         Component
A.30   Registration Entry Status                                     X                     X              X
A.31   Registration Entry Status Start Date                          X                     X              X
A.32   Registration Entry Status Change Reason                       X                     X              X
A.33   Registration Entry Status Change Reference                    X                     X              X
A.34   Registration Entry Status Comment                             X                     X              X
A.35   Remarks                                                       X                     X              X
A.36   Other Informative Information                                 X                     X              X
Scenario Classification Attributes                                   Scope Tag ID
                                                                     Code/Coded
SCENARIO CLASSIFICATION ATTRIBUTES WILL                       BE
                                                                     Domain Value
DELETED FROM ANNEX B ONCE ANNEX X IS IN PLACE
CL.1   Market Type                                                   1065
   Open Market Model - a trade model, conforming to the                     01
   description of Basic Trade Model, which is performed in an
   unbounded market under the Open-edi environment.
   Closed Market Model – a trade model where buyer(s) and                   02
   seller(s) accept the entry terms of market in advance and then
   commence the actual business transaction in the market under
   the Open-edi environment.
CL.2   Settlement Type                                               1070
   Immediate Settlement Model - a trade model where the entire              01
   business transaction process, such as planning, identification,
   negotiation, delivery of goods or services and payment, is
   completed in real-time under the Open-edi environment




                                                                                                                               B-3
                            Attributes                                 Scenario    Role   Information   Semantic
                                                                                          Bundle        Component
  Separate Settlement Model - a trade model where the                         02
  business transaction is performed under the Open-edi
  environment, and where the delivery of the good, service,
  and/or right and/or payment is separated from the agreement
  process
CL.3   Participation Type                                              1060
  Bilateral Trade Model - a trade model where buyer(s) and                    01
  seller(s) are directly involved in the business transaction
  without any involvement of any intermediary party.
  Mediated Trade Model - a trade model where a third party                    02
  mediates a specified role(s) or function(s) as mutually agreed
  to by the buyer(s) and seller(s) for a certain business
  transaction.
CL.4   Agent Type                                                      1110
  Buyer’s Agent - the scenario explicitly supports the role type of           01
  buyer’s agent in business transactions
  Seller’s Agent - the scenario explicitly supports the role type of          02
  Seller’s agent in business transactions
  None - he scenario does not support any role type of agent in               99
  a business transaction
CL.5   Third Party Constraint Type                                     1130
  Internal Constraint - use of a third party is by mutual                     01
  agreement of the buyer and seller
  External Constraint - use of a third party is mandated                      02
  None - the scenario does not support any role type of a third               99
  party
CL.6   Third Party Role Type                                           1135




B-4
                                                                                                  ISO/IEC CD 15944-2 :2003




                           Attributes                                 Scenario    Role   Information    Semantic
                                                                                         Bundle         Component
  Other - the scenario explicitly supports the other role types              00
  than those specified below in business transactions
  Mediator – the scenario explicitly supports the role type of               01
  mediator in business transactions
  Guarantor - the scenario explicitly supports the role type of              02
  guarantor in business transactions
  Escrow - the scenario explicitly supports the role type of                 03
  escrow in business transactions
  Notary - the scenario explicitly supports the role type of notary          04
  in business transactions
  None - the scenario does not explicitly supports any role type             99
  of third party in business transactions
CL.7   Catalog Provision                                              1225
  Provided - the scenario explicitly supports catalogue provision            01
  of merchandize in business transaction
  None - the scenario does not support catalogue provision of                99
  merchandize in business transaction
CL.8   Order Type                                                     1230
  Other - the scenario explicitly supports other order types than            00
  those specified below
  Pre-order - the scenario explicitly supports query/response                01
  interactions related to product/service availability, terms and
  conditions, etc.
  Purchase - the scenario explicitly supports the purchase type              02
  order process in business transaction




                                                                                                                             B-5
                           Attributes                                 Scenario    Role   Information   Semantic
                                                                                         Bundle        Component
  Change - the scenario supports the ability of the buyer to                 03
  amend a purchase type order
  Cancel - the scenario supports the ability of the buyer to cancel          04
  a purchase type or change type order
  Contract - the scenario explicitly supports the contract type              05
  order process in business transaction
CL.9   Offer Type                                                     1235
  Other - the scenario explicitly supports other offer types than            00
  those specified below
  Proposal - the scenario explicitly supports the proposal type              01
  offer process in business transactions
  Consign - the scenario explicitly supports the consign type                02
  offer process in business transactions
CL.10 Manufacturing Type                                              1245
  Other - the scenario explicitly supports other manufacturing               00
  types than those specified below
  Predefined - the scenario explicitly supports the readymade                01
  type products or packaged services provision in business
  transactions
  Definable - the scenario explicitly supports the order made                02
  type products or customized services provision in business
  transactions
  Off-the-shelf - the scenario explicitly supports standardized              03
  products ready for turn-key operation
  Configurable - the scenario explicitly supports products that              04                        `
  may require the buyer to specify configurable options with the
  seller during Process Negotiation




B-6
                                                                                                   ISO/IEC CD 15944-2 :2003




                           Attributes                                  Scenario    Role   Information    Semantic
                                                                                          Bundle         Component
CL.11 Liability/Risk Management                                        1247
  Other - The scenario supports a protection type other than                  00
  insurance or deposit
  Insurance - The scenario supports the insurance protection                  01
  type. Either the buyer or the seller may insure the payment for
  the goods or the value of the goods delivered
  Deposit - The scenario supports the deposit protection type.                02
  The buyer deposits money either with the seller or with a third
  party
  None - The scenario does not explicitly support any liability/risk          99
  management of business transaction
CL.12 Economic Resource Type                                           1280
  Other - The scenario explicitly supports other value resource               00
  than those specified below
  Good - The scenario explicitly supports the physical type                   01
  products in the business transaction
  Service - The scenario explicitly supports the provision of                 02
  services in the business transaction
  Value - The scenario explicity supports the financial products              03
  in business transaction
  Title/ Ownership - The scenario explicity supports the right of             04
  possession in business transaction
  License/ Right - The scenario explicity supports the right of               05
  permission in business transaction
CL.13 Exchange Value Type                                              1285
  Currency – ISO/IEC 4211                                                     01




                                                                                                                              B-7
                          Attributes                                 Scenario    Role   Information   Semantic
                                                                                        Bundle        Component
CL.14 Pricing Type                                                   1320
  Other - the scenario explicitly supports business transactions            00
  of other pricing type than those specified below
  Buyer’s Quote - the scenario explicitly supports business                 01
  transactions of buyer’s quote type pricing, i.e., price is
  determined by the buyer
  Seller’s Quote - the scenario explicitly supports business                02
  transactions of seller’s quote type pricing, i.e., the price is
  determined by the seller
  Individual Quote - the scenario explicitly supports business              03
  transactions of individual quote type pricing, i.e., the seller
  provides an offer price to a specific buyer in response to a
  request for a quote
  Closed Bid - the scenario explicitly supports business                    04
  transactions of closed bid type pricing (allow only sellers in a
  club). A bid is against a buyer’s specification
  Open Bid - the scenario explicitly supports           business            05
  transactions of bid type pricing from any seller
  Auction - the scenario explicitly supports business transactions          06
  of auction type pricing
  Reverse Auction - the scenario explicitly supports business               07
  transactions of reverse auction type pricing
  Price Matching - the scenario explicitly supports business                08
  transactions of price matching type pricing, i.e., generally
  multiple buyers interact with multiple sellers, where agreement
  on price is dynamically reached.g., stock market
CL.15 Non-pricing Negotiation Terms                                  1330




B-8
                                                                                                ISO/IEC CD 15944-2 :2003




                          Attributes                                Scenario    Role   Information    Semantic
                                                                                       Bundle         Component
  Other - the scenario supports non-pricing negotiation terms              00
  other than those specified below
  Negotiable Delivery Terms - the scenario explicitly                      01
  supports/does not support the negotiation of delivery terms
  Negotiable Delivery Lot - the scenario explicitly supports/does          02
  not support the negotiation of delivery lot
  Negotiable Packaging - the scenario explicitly supports/does             03
  not support the negotiation of packaging of merchandize
  None - the scenario does not support any non-pricing                     99
  negotiation terms other than the above mentioned
CL.16 Sales Channel Type                                            1340
  Other - the scenario supports sales channel types other than             00
  those specified below
  Direct - the scenario explicitly supports business transactions          01
  of direct sales channel type
  Consignment - the scenario explicitly supports business                  02
  transactions of consignment sales channel type
CL.17 INCO Terms Delivery Type                                      1360
  Other - the scenario explicitly supports delivery term types             00
  other than those specified below
  EXW - the scenario explicitly supports EXW (Ex Works) of                 01
  INCO Terms
  FCA - the scenario explicitly supports FCA (Free Carrier) of             02
  INCO Terms
  FAS - the scenario explicitly supports FAS (Free Alongside               03
  Ship) of INCO Terms




                                                                                                                           B-9
                           Attributes                               Scenario    Role   Information   Semantic
                                                                                       Bundle        Component
  FOB - the scenario explicitly supports FOB (Free on Board) of            04
  INCO Terms
  CFR - the scenario explicitly supports CFR (Cost and Freight)            05
  of INCO Terms
  CIF - the scenario explicitly supports CIF (Cost, Insurance and          06
  Freight) of INCO Terms
  CPT - the scenario explicitly supports CPT (Carriage Paid To)            07
  of INCO Terms
  CIP - the scenario explicitly supports CIP (Carriage and                 08
  Insurance Paid To) of INCO Terms
  DAF - the scenario explicitly supports DAF (Delivered At                 09
  Frontier) of INCO Terms
  DES - the scenario explicitly supports DES (Deliverd Ex Ship)            10
  of INCO Terms
  DEQ - the scenario explicitly supports DEQ (Delivered Ex                 11
  Quay) of INCO Terms
  DDU - the scenario explicitly supports DDU (Delivered Duty               12
  Unpaid) of INCO Terms
  DDP - the scenario explicitly supports DDP (Delivered Duty               13
  Paid) of INCO Terms
CL.18 Transport Type                                                1362
  Other - the scenario explicitly supports transport types other           00
  than those specified below
  Fixed/Physical – need definition                                         01
  Fixed/Electronic – need definition                                       02




B-10
                                                                                                 ISO/IEC CD 15944-2 :2003




                           Attributes                                Scenario    Role   Information    Semantic
                                                                                        Bundle         Component
  Mobile/Physical – need definition                                         03
  Mobile/Electronic – need definition                                       04
CL.19 Payment Term Type                                              1365
  Other - the scenario explicitly supports other payment term               00
  types than those specified below
  Single Payment - the scenario explicitly supports a single                01
  payment
  Multiple Payments - the scenario explicitly supports multiple             02
  payments
CL.20 Payment Method                                                 1370
  Other - the scenario explicitly supports other payment methods            00
  than those specified below
  Credit - the scenario explicitly supports credit type payments            01
  Debit - the scenario explicitly supports debit type payments              02
  Cash - the scenario explicitly supports cash type payments                03
  Funds transfer - the scenario explicitly supports funds transfer          04
  type payments
  Counter product - “barter”                                                05
CL.21 Settlement Type                                                1380
  Other - the scenario explicitly supports a type of settlement             00
  other than those specified below
  Advanced Payment - the scenario explicitly supports the                   01
  advanced payment type settlement




                                                                                                                        B-11
                           Attributes                                Scenario      Role           Information    Semantic
                                                                                                  Bundle         Component
   Deferred Payment - the scenario explicitly supports the                    02
   deferred payment type settlement
   Payment on Delivery - the scenario explicitly supports the                 03
   payment on delivery type settlement
   Incremental Payment - the scenario explicitly supports the                 04
   incremental payment type settlement
CL.22 Warranty Type                                                  1405
   Other - the scenario explicitly supports other warranty types              00
   than those specified below
   Warranty - the scenario explicitly supports the warranty of                01
   merchandize
   Refundable - the scenario explicitly supports the refund of                02
   merchandize
   None - the scenario does not explicitly support a warranty type            99
CL.23 Successiveness Type                                            1450
   Other - the scenario explicitly supports other successive                  00
   business transaction types than those specified below
   Successive - the scenario supports successive transactions                 01
   eliminating redundant business negotiation processes already
   established in a previous transaction. A framework agreement
   exists between the parties that governs subsequent scenarios
   Autonomous - the scenario stands alone as a business                       02
   transaction, i.e., “One-off”
Scenario Specification Attributes                                    Open-edi Scenario Component ID Code/Coded Domain Value
SS.1   International Standard Identifier                                    2005




B-12
                                                                                                          ISO/IEC CD 15944-2 :2003




                           Attributes                              Scenario      Role          Information      Semantic
                                                                                               Bundle           Component
SS.2   Identifier                                                      2010             3005       4010              5010
SS.3   Name                                                            2020             3010       4020              5020
SS.4   Purpose, SC Definition                                          2030             3015       4030              5030
SS.5   OeS Set of Roles , OeS Business Requirements, Role              2040      3020, 3025
       Business Goals, Rules and Constraints
SS.6   OeS Set of Information Bundles                                  2050
SS.7   Set of RequirementsDemands on Open-edi Parties               2500, 2060          3050
SS.8   External Constraints on Business Requirements, i.e., Laws       2070             3025       4050
       and Regulations
SS.9   Inheritance Identifier(s) and Cross References                  2080             3030
SS.10 Security Service Requirements                                    2090             3040       4100              5040
SS.11 Communication - Quality of Service Requirements                  2100             3045
SS.12 OeS Role Requirements and Constraints                            2120
SS.13 Person Qualification Type                                                  2125
  Mandatory - the scenario explicitly requires the mandatory                              01
  qualification of Person
  Preferred - the scenario explicitly supports the preferred                              02
  qualification of Person
  None - the scenario does not           explicitly support any                           99
  qualification of Person
SS.14 OeS Dependency among Roles in a Scenario                         2130
SS.15 OeS Dependency among Information Bundles in a                    2140
      Scenario




                                                                                                                                 B-13
                            Attributes                              Scenario      Role          Information   Semantic
                                                                                                Bundle        Component
SS.16 OeS Dependency among Semantic Components of                          2150
      Different Information Bundles
SS.17 Processing Mode                                               2600
   Other – the scenario explicitly supports other processing                 00
   modes than those specified below
   Real-time - the scenario is processed in real-time mode                   01
   Batch - the scenario is processed in batch mode                           02
SS.18 Interoperability Demands among Roles                                               3060
SS.19 Role States                                                                        3065
SS.20 Role Transitions                                                                   3070
SS.21 Role Events                                                                        3075
SS.22 Role Actions                                                                       3080
SS.23 Role Internal Function                                                             3085
SS.24 Demands on Open-edi Support Infrastructure                           2600          3090       4300
SS.25 Business Rules Controlling Content of Ibs                                                     4040
SS.26 IB contents                                                                                   4060
SS.27 IB recorded information retention – business rules and                                        4070
      constraints
SS.28 IB recorded information retention – external constraints on                                   4080
      business requirements, i.e., laws and regulations
SS.29 IB time validity characteristics                                                              4085
SS.30 Relationship of semantic components within an IB                                              4090
SS.31 IB Information for Interoperability                                                           4200




B-14
                                                                               ISO/IEC CD 15944-2 :2003




1286     Annex C (informative): Concept of classification attributes for
1287                              scenarios


1288   ANNEX C WILL BE RETAINED AS AN INFORMATIVE ANNEX, EVENTUALLY TO BE IN PART
1289   4, ONCE ANNEX X IS IN PLACE, REVISIONS AS MARKED BELOW ARE RECOMMENDED

1290   It is desired to be able to commence E-Commerce by simply choosing a particular one from the
1291   standardized set of scenarios and applying it to the intended business transaction. In the context,
1292   the standard Open-edi scenario is supposed to be a generic class of various specific scenarios.
1293   In addition, if the generic scenario class were successfully obtained, it could consist of a small
1294   number of mandatory attributes and many conditional and/or optional attributes.

1295   Although such a standardization idea for Open-edi scenarios seems to be a straightforward
1296   solution, it is likely to be difficult to distinguish a particular scenario from the others. In particular,
1297   the scenario description with many conditional attributes may be so complex that the semantics
1298   could not be clearly compiled even if an excellent OeDT is employed. In addition, for those
1299   scenarios having the same attributes but with slightly different domains and the combinatorial, it is
1300   not evident whether they all have to be interpreted as single scenario type or not. Even if each
1301   scenario could be formally identified, having a unique identifier, many scenarios that are actually
1302   identical for semantics may be redundantly registered as standard scenarios. The more confusion
1303   expands the more difficulty of discrimination increases.

1304   One of the effective solutions to avoid the confusion is to establish a classification scheme based
1305   on well-defined criteria, which may reduce the complexity of conditional attributes as much as
1306   possible.

1307   C.1 Classification idea of open-edi scenarios

1308   The classification for Open-edi scenarios should meet the following requirements:

1309   Simplicity: the classification is plainly and unambiguously defined.

1310   Selectivity: the classification is disjoint and non-redundant.

1311   Inclusiveness: the classification is an all-inclusive of Open-edi scenarios.

1312   Stability: the classification is stable for the environmental changes.

1313   Reality: the classification is realistic for the real business world.

1314   According to the requirements mentioned above, the classification scheme should be conceived
1315   from the fundamentals of business transactions in the real world such as market, party,
1316   merchandise and payment, not being tied to the existing classification ideas. For the purpose, the
1317   following three factors are considered as the typical example of key attributes for the classification
1318   of Open-edi scenarios. This classification approach could be extensively applied to complex
1319   scenarios in real business world when additional classification factors are taken into account.

1320   C.1.1 Market Type on business boundary

1321   In the real business world, the typical E-Commerce transactions consist of the following business
1322   processes.



                                                                                                              C-1
1323   A buyer finds a relevant seller(s) through the network by using a certain services and/or tools,
1324   such as a portal site and/or a search engine.

1325   The buyer negotiates the business terms and conditions with the seller(s).

1326   The buyer receives the merchandise and pays the amount of price to the seller(s) according to
1327   the business terms and conditions.

1328   Although the business transaction mentioned above does not explicitly describe the market
1329   environment, in the real business world, many business transactions are performed through the
1330   relevant markets. For example, in a typical case of financial transactions, which mainly trades a
1331   value and/or credit with other persons without the physical delivery of cash or security, the
1332   financial markets have significant roles in the business transactions. In such a well-defined
1333   market, the buyers and sellers could be free from the individual negotiation efforts of the principal
1334   terms and conditions for their business transactions. They would participate in the defined
1335   market, accepting the principle terms and conditions at the registration in advance.

1336   Other scenario context, such as authentication procedure, may be also greatly changed
1337   depending on whether the defined market exists or not. It seems to be much easier to discuss the
1338   classification of Open-edi scenarios if the market type, defined or unbounded, is taken into
1339   account. The market type is particularly meaningful in identifying the boundary of business
1340   transaction such as the trigger and completion terms.

1341   C.1.2 Settlement Type in business process

1342   From the viewpoint of a business process, another consideration is that the delivery of
1343   merchandise and payment are simultaneously settled through the network, or separately
1344   performed through different channels. In the case of simultaneous settlement, the business
1345   transaction could be immediately completed if the merchandise and the payment are both valid
1346   and acceptable for all of the participants. On the other hand, if the delivery and payment are
1347   separately performed through different channels respectively, the business transaction could not
1348   be completed until their acceptance and settlement would be confirmed at a later time.

1349   In order to bridge the time difference and/or spatial gap of the delivery and payment, the concrete
1350   identification of the business transaction and the authentication of either or both of participants
1351   are required for establishing the credit and debit relationship among them relevant to the
1352   business transaction. It also implies the difference of scenario constructs depending on the
1353   settlement type.

1354   C.1.3 Participation Type of role (business party)

1355   Regarding the role of Open-edi, the participation type, direct or mediated is meaningfully
1356   distinguished. In many cases, a business transaction is completed when the delivery and
1357   settlement are both confirmed between the buyer and seller. However, in some cases of business
1358   transactions, such as a real estate transaction through an escrow company, the third participant
1359   other than the buyer and seller is involved in the business transaction. In that case, the
1360   transaction is completed only when the escrow has confirmed the delivery and settlement
1361   according to the terms and conditions of the specific business transaction. Each participation type
1362   may have its own scenario construct respectively.

1363   C.2 Trade model based on the classification ideas

1364   The simplest business process shown in Fig.C.2-1 is the basic trade model, from which we start
1365   the discussion of trade models derived from the classification ideas mentioned in C.2.1.


                                                       MARKET
       C-2
                                                                            ISO/IEC CD 15944-2 :2003




1366
1367
                                                Negotiation
1368                        Seller                                                    Buyer
                                                   Merchandise
                          (Supplier)                                               (Consumer)
1369
                                                     Payment
1370

1371                                         Fig. C.2-1 Basic Trade Model

1372   The brief description of this Basic Trade Model is as follows:

1373   Beginning of Trade: either, or both buyer and seller find the negotiable counter party by
1374   appropriate approaches in a market.

1375   Trade Scenario: either or both buyer and seller show explicitly or implicitly an acceptable
1376   scenario to the counter party, and negotiate the terms and conditions of the business transaction.
1377   In general, the way of acceptance of a particular scenario may be a part of the terms and
1378   conditions.

1379   Completion of Trade: the trade will complete when both the delivery of merchandise and
1380   payment are successfully finished.

1381   Authentication of Participants: For the confirmation of the settlement of credit and/or debit
1382   between the buyer and seller, the authentication of buyer or seller is mandatory in the case that
1383   the payment or delivery is performed later than the agreement. If both delivery and payment are
1384   performed later than the agreement, the authentication of both participants is mandatory. On the
1385   contrary, if the delivery and payment are simultaneously and immediately performed as well as
1386   the agreement, no authentication is required.

1387   C.2.1 Trade model by Market Type

1388   Two trade models are derived from the classification of the market type.

1389   Open Market Model:
1390   a trade model, conforming to the description of Basic Trade Model, which is performed in
1391   unbounded market under the Open-edi environment

1392   In this trade model, the buyer and seller begin the business transaction from seeking their counter
1393   party by appropriate services and/or tools such as a portal site and search engine. The business
1394   scenario to be applied to the transaction is decided upon the individual case. The buyer or seller
1395   may simply accept the scenario proposed by the counter party, or they are mutually negotiating.

1396   In order to save the negotiation efforts, it is possible that the buyer or seller is seeking the
1397   counterpart specifying a specific scenario in the search criteria at the beginning of the business
1398   transaction. However, generally speaking, this type of business scenario should explicitly or
1399   implicitly include, as a part of scenario, the negotiation process of the terms and conditions. Thus,
1400   the Unbounded Trade Model necessarily requires the coincident agreement of scenario
1401   acceptance and the contents of terms and conditions under the scenario acceptance.




                                                                                                        C-3
1402   Closed Market Model:
1403   a trade model where buyer(s) and seller(s) accept the entry terms of market in advance and then
1404   commence the actual business transaction in the market under the Open-edi environment.

1405   Market administrator ;
1406   a role that is responsible for the administration of defined market for Open-edi transactions.

1407   The market administrator may be a buyer, seller or the third party. In any case, the scenario type
1408   to be applied to this trade model is explicitly established by the market administrator. The buyer
1409   and seller participate in the market through an explicit or implicit registration procedure in
1410   advance. There may be two types of registration scheme; i.e. an explicit registration is required
1411   for either of buyer or seller while the other implicitly participates in the market, or the explicit
1412   registration is required for both.

1413   The significance of the Closed Market Model is that the business scenario applied to the market
1414   is defined at the individual market. It makes the buyers and sellers free from the negotiation
1415   efforts of principal terms and conditions to be applied for the individual transaction. In this trade
1416   model, although the authentication of buyer and/or seller is not necessarily required, it may not be
1417   excluded that the registration procedure of market requires the authentication of participants in
1418   advance. The authentication at registration could save the repeating efforts in the individual
1419   business transactions.

1420   C.2.2 Trade model by Settlement Type

1421   Two trade models are derived from the classification of the settlement type.

1422   Immediate Settlement Model:
1423   a trade model where the entire business transaction process, i.e. planning, identification,
1424   negotiation, actualization (delivery and payment), is completed in real-time under the Open-edi
1425   environment.

1426   One of the typical cases is downloading a software product or music from the vendor site, and
1427   paying with e-money or debit account. This trade model is almost equivalent to a casual
1428   procurement of merchandise, which is done by cash at a store on the street. The procurement
1429   can be completed at the moment when it has been confirmed that the merchandise is acceptable
1430   for the buyer and the payment is valid for the seller. The identification of transaction and/or
1431   authentication of buyer and/or seller are not required. Rather, from the viewpoint of privacy
1432   protection, such a trade model should not be excluded from the Open-edi environment.

1433   Separate Settlement Model:
1434   a trade model where the business transaction is performed under the Open-edi environment, and
1435   where the delivery of merchandise and/or payment are separated from the agreement process.

1436   In this trade model, a special consideration should be taken on the scenario construct to bridge
1437   the time difference and/or spatial gap among agreement, delivery and payment.

1438   In this trade model, at the first, an explicit identification of the transaction is required for mapping
1439   the agreement to the delivery and/or payment performed separately. Secondary, the
1440   authentication of buyer and/or seller is required to confirm the relationship of credit and debit
1441   among participants that is kept through the transaction process from agreement to delivery and
1442   payment. Thirdly, the transition of transaction status should be identified to be able to track the
1443   completion of individual activities through the transaction process.

1444   C.2.3 Trade model by Participation Type




       C-4
                                                                            ISO/IEC CD 15944-2 :2003



1445   Two trade models are derived from the classification of the participation type.

1446   Bilateral Trade Model:
1447   a trade model where buyer(s) and seller(s) are directly involved in the business transaction
1448   without any involvement of any intermediary party.

1449   In this trade model, the business relationship is basically closed between the two parties. The
1450   transaction is completed when the credit and/or debit settled between the buyer and seller.

1451   Mediated (Multilateral) Trade Model:
1452   a trade model where a third party mediates a specified role(s) or function(s) as mutually agreed to
1453   by the buyer(s) and seller(s) for a certain business transaction.

1454   One of the typical transactions is the business transaction of real estate that an Escrow company
1455   mediates the buyer and seller. In this trade model, the role of the third party may have many
1456   variations. The transaction scenario is required to explicitly denote the role and responsibility of
1457   the third party participating to the business transaction. And, the business transaction should also
1458   satisfy the terms and conditions for the completion, which are relevant to the third party, not only
1459   the settlement of the debit/credit between the buyer and seller.

1460   C.3 Classification of open-edi scenarios

1461   The classification attributes mentioned in the previous section, Market Type, Payment Type and
1462   Participation Type are mutually disjoint. Applying each of them to an axis of three dimensions, the
1463   classification of Open-edi scenarios is obtained such that the requirement of scenario constructs
1464   is summarized in Table C.2-1.


1465


1466                        Table C.2-1 Scenario Classification and Constructs

            Class                  Classification Attributes                        3.79 Scenario Construct


                          Market         Settlement      Participation


        O-I-B          Open            Immediate        Bilateral        -Basic Bilateral Trade Scenario
        O-I-M          Open            Immediate        Mediated         -Basic Mediated Trade Scenario
        O-S-B          Open            Separate         Bilateral        -Bilateral Agreement Scenario

                                                                         -Separate Delivery Scenario

                                                                         -Separate Payment Scenario

                                                                         -Authentication Scenario
        O-S-M          Open            Separate         Mediated         -Mediated Agreement Scenario

                                                                         -Separate Delivery Scenario
                                                                         -Separate Payment Scenario



                                                                                                           C-5
                                                                    -Authentication Scenario
        C-I-B         Closed         Immediate      Bilateral       -Membership Registration Scenario

                                                                    -Defined Bilateral Trade Scenario
        C-I-M         Closed         Immediate      Mediated        -Membership Registration Scenario
                                                                    -Defined Mediated Trade Scenario
        C-S-B         Closed         Separate       Bilateral       -Membership Registration Scenario

                                                                    -Defined Bilateral Agreement Scenario
                                                                    -Separate Delivery Scenario

                                                                    -Separate Payment Scenario

                                                                    -Defined Authentication Scenario
        C-S-M         Closed         Separate       Mediated        -Membership Registration Scenario

                                                                    -Defined Mediated Agreement Scenario

                                                                    -Separate Delivery Scenario

                                                                    -Separate Payment Scenario

                                                                    -Defined Authentication Scenario

1467

1468   O-I-B Class:
1469   a scenario class of business transactions, which is attributed by Open Market, Immediate
1470   Settlement and Bilateral Participation.

1471   This scenario class consists of single Basic Bilateral Trade Scenario that is conforming to the
1472   Basic Trade Model under the Open-edi environment.

1473   O-I-M Class:
1474   a scenario class of business transactions, which is attributed by Open Market, Immediate
1475   Settlement and Mediated Participation.

1476   This scenario class consists of single Basic Mediated Trade Scenario, which is a complete set of
1477   mediated trade processes under the Open-edi environment.

1478   O-S-B Class:
1479   a scenario class of business transactions, which is attributed by Open Market, Separate
1480   Settlement and Bilateral Participation.

1481   This scenario class consists of the following four components: Bilateral Agreement Scenario,
1482   Separate Delivery Scenario, Separate Payment Scenario and Authentication Scenario.

1483   O-S-M Class:
1484   a scenario class of business transactions, which is attributed by Open Market, Separate
1485   Settlement and Mediated Participation.




       C-6
                                                                           ISO/IEC CD 15944-2 :2003



1486   This scenario class consists of the following four components: Mediated Agreement Scenario,
1487   Separate Delivery Scenario, Separate Payment Scenario and Authentication Scenario.

1488   C-I-B Class:
1489   a scenario class of business transactions, which is attributed by Closed Market, Immediate
1490   Settlement and Bilateral Participation.

1491   This scenario class consists of the following two components: Membership Registration Scenario
1492   and Closed Bilateral Trade Scenario.

1493   C-I-M Class:
1494   a scenario class of business transactions, which is attributed by Closed Market, Immediate
1495   Settlement and Mediated Participation.

1496   This scenario class consists of the following two components: Membership Registration Scenario
1497   and Closed Mediated Trade Scenario.

1498   C-S-B Class:
1499   a scenario class of business transactions, which is attributed by Closed Market, Separate
1500   Settlement and Bilateral Participation.

1501   This scenario class consists of the following five components: Membership Registration Scenario,
1502   Closed Bilateral Agreement Scenario, Separate Delivery Scenario, Separate Payment Scenario
1503   and Closed Authentication Scenario.

1504   C-S-M Class:
1505   a scenario class of business transactions, which is attributed by Closed Market, Separate
1506   Settlement and Mediated Participation.

1507   This scenario class consists of the following five components: Membership Registration Scenario,
1508   Closed Mediated Agreement Scenario, Separate Delivery Scenario, Separate Payment Scenario
1509   and Closed Authentication Scenario.

1510   C.3.1 Scenario components

1511   As mentioned in Table C.2-1, the scenario components are quite different depending on scenario
1512   classes. Those scenario components are described as follows:

1513   Basic Bilateral Trade Scenario:

1514   This scenario includes all processes of a transaction to begin and complete a Basic Bilateral
1515   Trade.

1516   At the beginning of trade, either or both the buyer and seller find the negotiable counter party, by
1517   appropriate approaches.

1518   Then, either or both the buyer and seller show explicitly or implicitly an acceptable scenario to the
1519   counterpart, and negotiate the terms and conditions of business transaction. The way of
1520   acceptance of a particular scenario may be a part of the terms and conditions.

1521   The trade will complete when both the delivery of merchandise and payment are coincidentally
1522   and successfully finished.




                                                                                                        C-7
1523   No authentication of buyer and seller is required because the delivery and payment are
1524   simultaneously and immediately performed as well as the agreement of transaction.

1525   Basic Mediated Trade Scenario:

1526   This scenario includes all processes of a transaction to begin and complete a Basic Mediated
1527   Trade.

1528   At the beginning of trade, either or both the buyer and seller find the negotiable counter party by
1529   appropriate approaches or through an appropriate mediator.

1530   Then, either or both the buyer and seller show explicitly or implicitly an acceptable scenario to the
1531   counterpart, and negotiate the terms and conditions of business transaction under the mediation
1532   of mediator(s). The way of acceptance of a particular scenario may be a part of the terms and
1533   conditions.

1534   The trade will complete when both the delivery of merchandise and payment are coincidentally
1535   and successfully finished and confirmed by the participants according to the terms and conditions
1536   agreed upon the business transaction.

1537   No authentication of buyer and seller may be required because the delivery and payment are
1538   simultaneously and immediately performed as well as the agreement of transaction. The mediator
1539   is required a certain authentication to qualify the ability of mediation. The qualification depends on
1540   the role of mediator.

1541   Closed Bilateral Trade Scenario:

1542   This scenario is the core of C-I-B scenario and includes all processes of a transaction to begin
1543   and complete a Closed Bilateral Trade of which the principal terms and conditions the participants
1544   accepted in advance.

1545   Before participating to the trade, the buyer and/or seller are required to make a membership
1546   registration to the defined market and to accept the principal terms and conditions of trade.

1547   Either or both the buyer and seller begin the individual transaction according to the direction
1548   provided by the market administrator.

1549   The trade will complete when both the delivery of merchandise and payment are coincidentally
1550   and successfully finished and confirmed by the participants according to the terms and conditions
1551   defined in the market and/or agreed upon the business transaction.

1552   The qualification of membership is required for the participants. But no authentication of buyer
1553   and seller may be required because the delivery and payment are simultaneously and
1554   immediately performed as well as the agreement of transaction.

1555   Closed Mediated Trade Scenario:

1556   This scenario is the core of C-I-M scenario and includes all processes of a transaction to begin
1557   and complete a Closed Mediated Trade of which the principal terms and conditions the
1558   participants accepted in advance.

1559   Before participating to the trade, the buyer, seller and/or mediator are required to make a
1560   membership registration to the defined market and to accept the principal terms and conditions of
1561   trade.




       C-8
                                                                        ISO/IEC CD 15944-2 :2003



1562   Either or both the buyer and seller begin and negotiate the individual transaction under the
1563   mediation of an appropriate mediator according to the direction provided by the market
1564   administrator.

1565   The trade will complete when both the delivery of merchandise and payment are coincidentally
1566   and successfully finished and confirmed by the participants according to the terms and conditions
1567   defined in the market and/or agreed upon the business transaction.

1568   The qualification of membership is required for the participants. But no authentication of buyer
1569   and seller may be required because the delivery and payment are simultaneously and
1570   immediately performed as well as the agreement of transaction.

1571   Bilateral Agreement Scenario:

1572   This scenario is the agreement part of O-S-B scenario, which precedes the delivery of
1573   merchandise and/or payment of the transaction.

1574   At the beginning, either or both the buyer and seller find the negotiable counter party, by
1575   appropriate approaches. Then, either or both of them show explicitly or implicitly an acceptable
1576   scenario to the counter party, and negotiate the terms and conditions of business transaction.
1577   The way of acceptance of a particular scenario may be a part of the terms and conditions.

1578   In the agreement, it is explicitly described that the delivery and/or payment are separately
1579   performed later. A unique identification of the transaction is required for mapping the agreement
1580   to the delivery and/or payment performed separately. And, the identification should be unique in
1581   the global scope because the open market could not have a well-defined boundary.

1582   The transaction will complete when both the delivery and payment are successfully finished and
1583   confirmed by the participants according to the Separate Delivery Scenario and Separate Payment
1584   Scenario.

1585   Closed Bilateral Agreement Scenario:

1586   This scenario is the agreement part of C-S-B scenario, which precedes the delivery of
1587   merchandise and/or payment of the transaction.

1588   Before participating to the trade, the buyer and/or seller are required to make a membership
1589   registration to the specific market and to accept the principal terms and conditions of trade.

1590   Either or both the buyer and seller begin the individual transaction according to the direction
1591   provided by the market administrator.

1592   In the agreement, it is explicitly described that the delivery and/or payment are separately
1593   performed later. A unique identification of the transaction is required for mapping the agreement
1594   to the delivery and/or payment performed separately. And, the identification should be unique in
1595   the market boundary.

1596   The transaction will complete when both the delivery and payment are successfully finished and
1597   confirmed by the participants according to the terms and conditions defined in the market and/or
1598   to the Separate Delivery Scenario and Separate Payment Scenario.

1599   Mediated Agreement Scenario:




                                                                                                    C-9
1600   This scenario is the agreement part of O-S-M scenario, which precedes the delivery of
1601   merchandise and/or payment of the transaction.

1602   Either or both the buyer and seller begin and negotiate the individual transaction under the
1603   mediation of an appropriate mediator according to the direction provided by the market
1604   administrator.

1605   The trade will complete when both the delivery and payment are and successfully finished and
1606   confirmed by the participants according to the Separate Delivery Scenario and Separate Payment
1607   Scenario.

1608   In the agreement, it is explicitly described that the delivery and/or payment are separately
1609   performed later. I addition, a unique identification of the transaction is required for mapping the
1610   agreement to the delivery and/or payment performed separately. And, the identification should be
1611   unique in the global scope because the open market could not have a well-defined boundary.

1612   The transaction will complete when both the delivery and payment are successfully finished and
1613   confirmed by the participants according to the Separate Delivery Scenario and Separate Payment
1614   Scenario.

1615   Closed Mediated Agreement Scenario:

1616   This scenario is the agreement part of C-S-M scenario, which precedes the delivery of
1617   merchandise and/or payment of the transaction.

1618   Either or both the buyer and seller begin and negotiate the individual transaction under the
1619   mediation of an appropriate mediator according to the direction provided by the market
1620   administrator.

1621   In the agreement, it is explicitly described that the delivery and/or payment are separately
1622   performed later. A unique identification of the transaction is required for mapping the agreement
1623   to the delivery and/or payment performed separately. And, the identification should be unique in
1624   the market boundary.

1625   The transaction will complete when both the delivery and payment are successfully finished and
1626   confirmed by the participants according to the terms and conditions defined in the market and/or
1627   to the Separate Delivery Scenario and Separate Payment Scenario.

1628   Separate Delivery Scenario:

1629   This scenario is the delivery part of O-S-B, O-S-M, C-S-B and C-S-M scenarios, which is
1630   separately performed after the agreement of transaction.

1631   When the delivery of merchandize is separately performed from the agreement of the transaction,
1632   the specific terms and conditions of delivery should be explicitly described. The delivery status
1633   should be explained in the scenario, as the completion of delivery is a mandatory factor for the
1634   completion of the transaction as a whole.

1635   Furthermore, the delivery scenario should keep a stable reference to the precedent agreement
1636   scenario to denote the relationship between the separated activities of a transaction.

1637   Separate Payment Scenario:

1638   This scenario is the payment part of O-S-B, O-S-M, C-S-B and C-S-M scenarios, which is
1639   separately performed after the agreement of transaction.



       C-10
                                                                            ISO/IEC CD 15944-2 :2003



1640   When the payment is separately performed after the agreement of the transaction, the payment
1641   scenario is required to explicitly describe the specific terms and conditions of payment.

1642   The payment status should also be explained in the scenario, as the completion of payment is a
1643   mandatory factor for the completion of the transaction as a whole.

1644   Furthermore, the payment scenario should keep a stable reference to the precedent agreement
1645   scenario to denote the relationship between the separated activities of a transaction.

1646   Authentication Scenario:

1647   This scenario is the authentication part of O-S-B and O-S-M scenarios, which identifies and
1648   confirms the agreement and/or the participants relevant to the transaction.

1649   When the delivery of merchandise and/or payment is separately performed after the agreement of
1650   the transaction, the authentication scenario is required to explicitly identify and confirm the credit
1651   and debit relationship between participants involved in the transaction. The identification should
1652   be unique in the global scope because the open market could not have a well-defined boundary.

1653   The authentication scenario should also keep a stable reference to the relevant agreement
1654   scenario to denote the relationship among the transaction, the agreement and/or the participants.

1655   Closed Authentication Scenario:

1656   This scenario is the authentication part of C-S-B and C-S-M scenarios, which identifies and
1657   confirms the agreement and/or the participants relevant to the transaction.

1658   When the delivery of merchandise and/or payment is separately performed after the agreement of
1659   the transaction, the authentication scenario is required to explicitly identify and confirm the credit
1660   and debit relationship between participants involved in the transaction.

1661   The market administrator provides the authentication scheme of the market. The identification
1662   should be unique in the market boundary.

1663   The authentication scenario should also keep a stable reference to the relevant agreement
1664   scenario to denote the relationship among the transaction, the agreement and/or the participants.

1665   C..3.2 Assumption for scenario classification

1666   For the simplicity of discussion, this scenario classification idea has many assumptions. In the
1667   real business world, those assumptions should be further compiled to reflect the practical aspects
1668   of business transactions.

1669   Continuous Transaction:
1670   a series of transactions of which the terms and conditions are constant.

1671   No discrimination is supposed between a continuous transaction and a spot transaction. The
1672   continuous transaction is considered as a repetition of spot transactions of which the terms and
1673   conditions are constant or only a variable part is changing.

1674   Services Transaction:
1675   a business transaction where services are procured.




                                                                                                       C-11
1676   The business transaction of services is assumed to be basically same as of goods even if it may
1677   have different attributes relevant to the delivery procedure and the status confirmation.

1678   Auction Transaction:
1679   a business transaction relevant to auction.

1680   An auction transaction is supposed to be a variation of mediated transaction, which requires the
1681   competitive participation of two or more buyers for a sale of merchandise.

1682   Bidding Transaction:
1683   a business transactions relevant to biddingt.

1684   A bidding transaction is supposed to be a variation of bilateral transaction, which requires the
1685   competitive participation of two or more sellers for a procurement of merchandise.

1686   Credit Payment Transaction:
1687   a business transaction that is settled by a credit card or debit card.

1688   A transaction settled by a credit card requires a provision of credit and the authentication of
1689   buyer. Thus the transaction type is differed from the transaction by cash, and is supposed to be a
1690   kind of Separate Payment Model.

1691   Regulatory Constraints:

1692   Actual business transactions may have many types of regulatory constraints than the normative
1693   rules explicitly or implicitly involved in the transactions. Each of them is partially or entirely applied
1694   to a specific market type, participant type, merchandise type, delivery type and/or payment type.
1695   In addition, some of them are particularly effective in a certain country or region and/or in a
1696   certain period. However, the scenario classification is considered to be independent from the
1697   regulatory constraints.




       C-12
                                                              ISO/IEC CD 15944-2 :2003




Annex X (Normative) Classification Concepts



X.1 Introduction

Classification concepts are more properly and completely dealt with in Part 4 – “Open-
edi Ontology Model”. However, work on completing Part 4 is still in progress. In the
meantime, a number of primitive trade model classification concepts which will form
part of Part 4 have been identified and are already included in Part 2.

Some primitive classification concepts and the rules governing them were already
identified and specified in Part 1, 6.6. “Primitive classification and identification of
Open-edi scenarios,” and in Clause 7 “Guidelines for scoping Open-edi scenerios.”
Some of these primitive classification concepts are already included in the Part 1, 7.3.2
“Template” (with their “Scope Tag ID Codes”), namely,



       1060        Bilateral Transaction Model

       1061        Mediated Transaction Model

       1065           Defined Market Model

       1066         Undefined market Model

       1070        Immediate Settlement Model

       1071        Separate Settlement Model



Additional primitive classification concepts are identified in this Annex X. It is
anticipated that these will be integrated into the Part 4 “Open-edi Ontology Model”. As
such they are already presented here from a registration perspective.

X.2 Registration Aspects

Classification concepts provide for either selection from an exhaustive list of sub-types,
choices or options for each as specified in table format, or by specification when the list
for a concept is not fully predefined. The approach taken here, as elsewhere in this
multipart standard, is to specify predefined subtypes (or choices) for concepts as coded
domains for use by applicants. Here the set of choices is either finite, i.e. exhaustive, or
provision is made for allowing “other”. In the latter case, when the applicant chooses
“other”, where this is allowed, clear and precise language must be used for Open-edi
business object registration.



                                                                                         X-1
Classification concepts of the Trade Model are numbered sequentially as CL.n 7, and
reference Scope Tag ID Codes in Table X.1, many of which are carried over from
ISO/IEC 15944-1, 6.6.4 “Classification and components of Open-edi scenarios.”

Registration of classification concepts is optional, as determined by a Decision Code of
1, (= YES) or 2 (= NO) in Template 7.3.2 of ISO/IEC 15944-1.

Rule nnn: A classification concept shall be registered if the Decision Code is 1 in
Template in Template 7.3.2 of ISO/IEC 15944-1.

X.3 Classification Concepts

X.3.1 Trade Models by Type

Rule nnn: The Open-edi Trade Model has three primitive types, namely, market
type, settlement type, and participation type

They are defined as follows:

CL.1     Participation Type (1060 & 1061)8

participation type
a classification concept of participation of Open-edi parties where party(ies) as buyer(s) or
seller(s) act either bilaterally or intermediaries are involved in an Open-edi transaction9.

CL.2     Market Type (1065 & 1066)

market type
a classification concept of market where the market is defined (bounded) or undefined
(unbounded) for specific types of business transactions or communities under the Open-edi
environment10.

CL.3     Settlement Type (1070 & 1071)

settlement type
a classification concept of settlement where all aspects of the business transaction are settled
immediately or separately11.




7 This is an interim numbering systems which will be revisited during Part 4 development work.

8 Numbers in “(        )” are the Scope Tag ID Codes as found in the ISO/IEC 15944-1, Clause 7.3.2
Template.
9 See further Part 1, 6.6.3.3 and Annex H.

10 See further Part 1, 6.6.3.1 and Annex H.

11 See further Part 1, 6.6.3.2 and Annex H.




X-2
                                                                          ISO/IEC CD 15944-2 :2003




X.3.2 Role Type – Agent and Third Party12

CL.4 Agent Type (1110 (1111 & 1112))
agent type
a classification concept of agent role for Open-edi parties where the agent acts behalf of a buyer
or a seller

[Note: To be rethought in that an “agent” can act on behalf of any Person (and Person subtype),
and role player, etc.]

CL.5 Third Party Constraint Type (1130 (1131 & 1132))
third party constraint type
a classification concept of involvement of third party for an Open-edi transaction where the
involvement of third party is defined by mutual agreement of the buyer and seller, or mandated by
an external constraint ( e.g. enforced by regulatory framework irrespective the agreement).


CL.6 Role Type of Third Party (1135)*13
third party role type
a classification concept of role of third party involved in an Open-edi transaction where the third
party has an independent responsibility to commence the transaction, but not acting as an agent
of buyer or seller

Note: A Third Party by definition of Part 1 does not act as an agent of a buyer or seller.

X.3.3 Sub-Process Types14

CL.7 Catalogue Provision (1225)
catalog provision
a classification concept of information provision of product from seller to buyer for an Open-edi
transaction where the seller provides catalog of product to the buyer or not.

CL.8 Initiation Type (1230 & 1235)
initiation type
a classification concept of offer relevant to Open-edi transaction where the initiation is the
responsibility of the seller or buyer

CL.9 Offer Type (124015)


12 See further Part 1, Clause 6.2.5 “Person and delegation to “agent” and/or “third party””

13 Use of an “*” indicates that this “classification concept” is an addition to the Scoping attributes already
identified in Part 1, Clause 7.3.2 Template.
14 For the Process Component of the Business Transaction Model see further Part 1, Clause 6.3 “Rules
governing the process component” and also Annex F(informative) Business Transaction Model: Process
Component”.



                                                                                                          X-3
offer type
a classification concept pertaining to whteher the offer is of a proposal, consign or other nature.

CL.10 Order Type (1241)*
order type
a classification concept of order activity of Open-edi transaction where the order is origination of
procurement , modification, or cancellation of existing order.

CL.11 Successiveness Type (1242)*
successiveness type
a classification concept of Open-edi transaction where a framework agreement exists between
the parties for subsequent transactions to eliminate redundant business negotiation once
established, or not (e.g. repeat orders, “automated” rule-driven re-ordering).

CL.12 Manufacturing Type (1245)*
manufacturing type
a classification concept of arrangement for product in an Open-edi transaction where the
availability of product is pre-defined, or fully or partially configurable.

CL.13 Liability/Risk Management (1247)*
liability/risk management
a classification concept of protection instrument against economic risk which may arise in an
Open-edi transaction where the lost value is insured or recovered with the deposit, or not.

CL.14 Economic Resource Type (1275)*
economic resource type
a classification concept of product and the counter value from a viewpoint of financial accounting
in enterprise

CL.15 Exchange Value Type (1305)
exchange value
a classification concept of counter value against product of Open-edi transaction where the value
is denoted with a currency unit of legal tender, i.e. a monetary payment is involved

CL.16 Pricing Type (1320)*
pricing type
a classification concept of pricing method of product among Open-edi parties

CL.17 Non-pricing Negotiation Terms (1325)*
non-pricing negotiation terms
a classification concept of negotiation terms other than pricing of product of Open-edi transaction


15 Note: Part 1, page 71 has a typing error in that it contains text of “Predefined Market Model” for Scope
Tag ID Code 1240. This text should not be there. “Defined Market Model” = Scope Tag ID Code 1065



X-4
                                                                    ISO/IEC CD 15944-2 :2003



CL.18 Sales Channel Type (1330)*
sales channel type
a classification concept of sales method of product for Open-edi transaction where the product is
directly delivered by the seller or consigned party

CL.19 INCO Terms Delivery Type (1365)*
INCO term delivery type
a classification concept of delivery terms of Open-edi transaction defined by International
Commercial Terms

CL.20 Transport Type (1366)*
transport type
a classification concept of transport of fixed or mobile, physical or electronic, or other nature

CL.21 Payment Lot Type (1367)*
payment lot type
a classification concept of payment lot for a Open-edi transaction where the payment is
performed in single lot by the certain due date or not, there are multiple payments

CL.22 Payment Method (1368)*
payment method
a classification concept of payment instrument for an Open-edi transaction

CL.23 Payment Timing Type (1369)*
payment timing
a classification concept of settlement of payment against product of Open-edi transaction where
the payment is performed after, before, or on delivery

CL.24 Warranty Type (1405)
warranty type
a classification concept of warranty terms for a “failed” product of Open-edi transaction where the
transaction applies warranty and is in the form of repair, replace, substitute, refund, compensate
or other.




                                                                                                    X-5
Table X.1 Classification Concepts

                    Classification Concepts                             Scenario
                                                                        Scope Tag ID
                                                                        Code/Coded
                                                                        Domain Value




CL.1    Participation Type
Bilateral Trade Model- a trade model where only buyer and seller        1060
are directly involved in a business transaction
Mediated Transaction Model- a trade model where a third party           1061
mediates a specified role(s) or function(s) as mutually agreed to
by the buyer(s) and seller(s) for a certain business transaction
CL.2    Market Type
   Undefined Model - a trade model, conforming to the                   1065
   description of Basic Trade Model, which is performed in an
   unbounded market under the Open-edi environment.
   Defined Market Model – a trade model where buyer(s) and
   seller(s) accept the entry terms of market in advance and then       1066
   commence the actual business transaction in the market under
   the Open-edi environment.
CL.3 Settlement Type
   Immediate Settlement Model - a trade model where the entire          1070
   business transaction process, such as planning, identification,
   negotiation, delivery of goods or services and payment, is
   completed in real-time under the Open-edi environment
   Separate Settlement Model - a trade model where the
   business transaction is performed under the Open-edi
   environment, and where the delivery of the good, service,
   and/or right and/or payment is separated from the agreement          1071
   process
CL.4 Agent Type                                                         1110
   Buyer’s Agent - the scenario explicitly supports the role type of           01
   buyer’s agent in business transactions
   Seller’s Agent - the scenario explicitly supports the role type of          02
   Seller’s agent in business transactions
   None - the scenario does not support any role type of agent in              99
   a business transaction
CL. 5 Third Party Constraint Type                                       1130
   Internal Constraint - use of a third party is by mutual                     01
   agreement of the buyer and seller
   External Constraint - use of a third party is mandated                      02



X-6
                                                                   ISO/IEC CD 15944-2 :2003




                       Classification Concepts                         Scenario
   None - the scenario does not support any role type of a third              99
   party
CL.6 Third Party Role Type                                             1135
   Other - the scenario explicitly supports the other role types              00
   than those specified below in business transactions
   Mediator – the scenario explicitly supports the role type of               01
   mediator in business transactions
   Guarantor - the scenario explicitly supports the role type of              02
   guarantor in business transactions
   Escrow - the scenario explicitly supports the role type of                 03
   escrow in business transactions
   Notary - the scenario explicitly supports the role type of notary          04
   in business transactions
   None - the scenario does not explicitly supports any role type             99
   of third party in business transactions
CL.7 Catalog Provision                                                 1225
   Provided - the scenario explicitly supports catalogue provision            01
   of merchandize in business transaction
   None - the scenario does not support catalogue provision of                99
   merchandize in business transaction
CL.8 Initiation Type
    Buyer Initiated – the buyer initiates        Open-edi business     1230
transaction
    Seller Initiated – the seller initiates the Open-edi business      1235
transaction
CL.9 Offer Type                                                        1240
   Other - the scenario explicitly supports other offer types than            00
   those specified below
   Proposal - the scenario explicitly supports the proposal type              01
   offer process in business transactions
   Consign - the scenario explicitly supports the consign type                02
   offer process in business transactions
CL.10 Order Type                                                       1241
   Other - the scenario explicitly supports other order types than            00
   those specified below
   Pre-order - the scenario explicitly supports query/response                01
   interactions related to product/service availability, terms and
   conditions, etc.
   Purchase - the scenario explicitly supports the purchase type              02
   order process in business transaction



                                                                                              X-7
                    Classification Concepts                            Scenario
   Change - the scenario supports the ability of the buyer to                 03
   amend a purchase type order
   Cancel - the scenario supports the ability of the buyer to cancel          04
   a purchase type or change type order
   Contract - the scenario explicitly supports the contract type              05
   order process in business transaction
CL.11 Successiveness Type                                              1242
   Other - the scenario explicitly supports other successive                  00
   business transaction types than those specified below
   Continuous - the scenario supports continuous repeating                    01
   transactions eliminating redundant business negotiation
   processes already established in a previous transaction. A
   framework agreement exists between the parties that governs
   subsequent scenarios
   Autonomous - the scenario stands alone as a business                       02
   transaction, i.e., “One-off” or ”spot” transactions
   Definable - the scenario explicitly supports the order made                02
   type products or customized services provision in business
   transactions
   Off-the-shelf - the scenario explicitly supports standardized              03
   products ready for turn-key operation
   Configurable - the scenario explicitly supports products that              04
   may require the buyer to specify configurable options with the
   seller during Process Negotiation
CL.24 Manufacturing Type                                               1245
   Other - the scenario explicitly supports other manufacturing               00
   types than those specified below
   Predefined - the scenario explicitly supports the readymade                01
   type products or packaged services provision in business
   transactions
   Definable - the scenario explicitly supports the order made                02
   type products or customized services provision in business
   transactions
   Off-the-shelf - the scenario explicitly supports standardized              03
   products ready for turn-key operation
   Configurable - the scenario explicitly supports products that              04
   may require the buyer to specify configurable options with the
   seller during Process Negotiation
CL.13 Liability/Risk Management                                        1247
   Other - The scenario supports a protection type other than                 00
   insurance or deposit




X-8
                                                                    ISO/IEC CD 15944-2 :2003




                     Classification Concepts                            Scenario
   Insurance - The scenario supports the insurance protection                  01
   type. Either the buyer or the seller may insure the payment for
   the goods or the value of the goods delivered
   Deposit - The scenario supports the deposit protection type.                02
   The buyer deposits money either with the seller or with a third
   party
   None - The scenario does not explicitly support any liability/risk          99
   management of business transaction
CL.14 Economic Resource Type                                            1275
   Other - The scenario explicitly supports other value resource               00
   than those specified below
   Good - The scenario explicitly supports the physical type                   01
   products in the business transaction
   Service - The scenario explicitly supports the provision of                 02
   services in the business transaction
   Value - The scenario explicity supports the financial products              03
   in business transaction
   Title/ Ownership - The scenario explicity supports the right of             04
   possession in business transaction
   License/ Right - The scenario explicity supports the right of               05
   permission in business transaction
CL.15 Exchange Value Type                                               1305
   Currency – subset of ISO 4217                                               01
CL.16 Pricing Type                                                      1320
   Other - the scenario explicitly supports business transactions              00
   of other pricing type than those specified below
   Buyer’s Quote - the scenario explicitly supports business                   01
   transactions of buyer’s quote type pricing, i.e., price is
   determined by the buyer
   Seller’s Quote - the scenario explicitly supports business                  02
   transactions of seller’s quote type pricing, i.e., the price is
   determined by the seller
   Individual Quote - the scenario explicitly supports business                03
   transactions of individual quote type pricing, i.e., the seller
   provides an offer price to a specific buyer in response to a
   request for a quote
   Closed Bid - the scenario explicitly supports business                      04
   transactions of closed bid type pricing (allow only sellers in a
   club). A bid is against a buyer’s specification
   Open Bid - the scenario explicitly supports             business            05
   transactions of bid type pricing from any seller




                                                                                               X-9
                    Classification Concepts                           Scenario
   Auction - the scenario explicitly supports business transactions          06
   of auction type pricing
   Reverse Auction - the scenario explicitly supports business               07
   transactions of reverse auction type pricing
   Price Matching - the scenario explicitly supports business                08
   transactions of price matching type pricing, i.e., generally
   multiple buyers interact with multiple sellers, where agreement
   on price is dynamically reached.g., stock market
CL.17 Non-pricing Negotiation Terms                                   1325
   Other - the scenario supports non-pricing negotiation terms               00
   other than those specified below
   Negotiable Delivery Terms - the scenario explicitly                       01
   supports/does not support the negotiation of delivery terms
   Negotiable Delivery Lot - the scenario explicitly supports/does           02
   not support the negotiation of delivery lot
   Negotiable Packaging - the scenario explicitly supports/does              03
   not support the negotiation of packaging of merchandize
   None - the scenario does not support any non-pricing                      99
   negotiation terms other than the above mentioned
CL.18 Sales Channel Type                                              1330
   Other - the scenario supports sales channel types other than              00
   those specified below
   Direct - the scenario explicitly supports business transactions           01
   of direct sales channel type
   Consignment - the scenario explicitly supports business                   02
   transactions of consignment sales channel type
CL.19 INCO Terms Delivery Type                                        1365
   Other - the scenario explicitly supports delivery term types              00
   other than those specified below
   EXW - the scenario explicitly supports EXW (Ex Works) of                  01
   INCO Terms
   FCA - the scenario explicitly supports FCA (Free Carrier) of              02
   INCO Terms
   FAS - the scenario explicitly supports FAS (Free Alongside                03
   Ship) of INCO Terms
   FOB - the scenario explicitly supports FOB (Free on Board) of             04
   INCO Terms
   CFR - the scenario explicitly supports CFR (Cost and Freight)             05
   of INCO Terms
   CIF - the scenario explicitly supports CIF (Cost, Insurance and           06
   Freight) of INCO Terms




X-10
                                                                   ISO/IEC CD 15944-2 :2003




                   Classification Concepts                           Scenario
  CPT - the scenario explicitly supports CPT (Carriage Paid To)              07
  of INCO Terms
  CIP - the scenario explicitly supports CIP (Carriage and                   08
  Insurance Paid To) of INCO Terms
  DAF - the scenario explicitly supports DAF (Delivered At                   09
  Frontier) of INCO Terms
  DES - the scenario explicitly supports DES (Deliverd Ex Ship)              10
  of INCO Terms
  DEQ - the scenario explicitly supports DEQ (Delivered Ex                   11
  Quay) of INCO Terms
  DDU - the scenario explicitly supports DDU (Delivered Duty                 12
  Unpaid) of INCO Terms
  DDP - the scenario explicitly supports DDP (Delivered Duty                 13
  Paid) of INCO Terms
CL.20 Transport Type                                                 1366
  Other - the scenario explicitly supports transport types other             00
  than those specified below
  Fixed/Physical – need definition                                           01
  Fixed/Electronic – need definition                                         02
  Mobile/Physical – need definition                                          03
  Mobile/Electronic – need definition                                        04
CL.21 Payment Lot Type                                               1367
  Other - the scenario explicitly supports other payment term                00
  types than those specified below
  Single Payment - the scenario explicitly supports a single                 01
  payment
  Multiple Payments - the scenario explicitly supports multiple              02
  payments
CL.22 Payment Method                                                 1368
  Other - the scenario explicitly supports other payment methods             00
  than those specified below
  Credit - the scenario explicitly supports credit type payments             01
  Debit - the scenario explicitly supports debit type payments               02
  Cash - the scenario explicitly supports cash type payments                 03
  Funds transfer - the scenario explicitly supports funds transfer           04
  type payments
  Counter product - “barter”                                                 05
CL.23 Payment Timing Type                                            1380



                                                                                          X-11
                   Classification Concepts                            Scenario
  Other - the scenario explicitly supports a type of settlement              00
  other than those specified below
  Advanced Payment - the scenario explicitly supports the                    01
  advanced payment type settlement
  Deferred Payment - the scenario explicitly supports the                    02
  deferred payment type settlement
  Payment on Delivery - the scenario explicitly supports the                 03
  payment on delivery type settlement
  Incremental Payment - the scenario explicitly supports the                 04
  incremental payment type settlement
CL.24 Warranty Type                                                   1405
  Other - the scenario explicitly supports other warranty types              00
  than those specified below
  Repair - the scenario explicitly supports the repair of product            01
  Replace - the scenario explicitly supports the replacement of              02
  product
  Substitute - the scenario explicitly supports the substitution of          03
  product
  Refund –the scenario explicitly supports “refund” as part of               04
  warranty
  Compensate – the scenario explicitly supports a compensation               05
  of some form
  None - the scenario does not explicitly support a warranty type            99




X-12

								
To top