ITU-T T 510-1993 General Overview of the T 510-Series Recommendations - Telematic Services Terminal Equipments and Protocols for Telematic Services (Study Group VIII) 16 pp《T 510系列.pdf

《ITU-T T 510-1993 General Overview of the T 510-Series Recommendations - Telematic Services Terminal Equipments and Protocols for Telematic Services (Study Group VIII) 16 pp《T 510系列.pdf》由会员分享，可在线阅读，更多相关《ITU-T T 510-1993 General Overview of the T 510-Series Recommendations - Telematic Services Terminal Equipments and Protocols for Telematic Services (Study Group VIII) 16 pp《T 510系列.pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、ITU-T RECHN*T*SLO 93 4862591 O594076 O92 INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU TELEMATIC SERVICES TERMINAL EQUIPMENTS AND PROTOCOLS FOR TELEMATIC SERVICES T.51 O (03193) GENERAL OVERVIEW OF THE T.51 O-SERIES RECOMMENDATIONS ITU-T Recommendation T

2、.51 O (Previously “CCITT Recommendation”) ITU-T RECMN*To53O 93 9 4862593 0594077 T29 U FOREWORD The IT Telecommunication Standardization Sector (IT-T) is a permanent organ of the International Telecom- munication Union. The ITIJ-T is responsible for studying technical, operating and tariff questions

3、 and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, established the topics for study by the -T Study Groups which, in their turn, produce Recommendation

4、s on these topics. ITU-T Recommendation T.510 was prepared by the IT-T Study Group VI11 (1988-1993) and was approved by the WTSC (Helsinki, March 1-12, 1993). NOTES 1 As a consequence of a reform process within the International Telecommunication Union (ITU), the CCITT ceased to exist as of 28 Febru

5、ary 1993. In its place, the IT Telecommunication Standardization Sector (ITU-T) was created as of 1 March 1993. Similarly, in this reform process, the CCIR and the IFRB have been replaced by the Radiocommunication Sector. In order not to delay publication of this Recommendation, no change has been m

6、ade in the text to references containing the acronyms “CCITT, CCIR or IFRB” or their associated entities such as Plenary Assembly, Secretariat, etc. Future editions of this Recommendation will contain the proper terminology related to the new ITU structure. 2 telecommunication administration and a r

7、ecognized operating agency. In this Recommendation, the expression “Administration” is used for conciseness to indicate both a O IT 1994 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and mi

8、crofilm, without permission in writing from the ITU. CONTENTS 1 Scope 2 Field of application 3 References 4 Definitions 5 Introduction to the definition of implementation requirements (IRs) 6 Requirements classification 7 8 Specification of implementation requirements . 9 Implementation support stat

9、ement (ISS) Annex A - Relationships between the DAPs, Implementation Requirements and Terminal Characteristics . Implementation model and actual implementation Recommendation T.510 (03/93) Page 1 1 1 1 2 3 4 7 9 11 1 ITU-T RECNN*T=5LO 93 q862591 0594079 8T1 Recommendation T.5 10 GENERAL OVERVIEW OF

10、THE T.510-SERIES RECOMMENDATIONS (Helsinki, 1993) 1 Scope The T.5 1 O-Series Recommendations contains the specifications for implementation requirements (IR) in correspondence with the T.500-Series Recommendations. This Recommendation provides the necessary definitions required for the establishment

11、 of Recommendations within the T.5 10-Series. This Recommendation gives the guidelines on how to describe the requirements to DAP implementations to be used by an application. Specific requirements of telematic services are not covered by this series of Recommendations. This Recommendation defines a

12、n abstract implementation model in order to structure the IRs and to qualify the function units depending on the classes of requirements. This Recommendation defines the structure and the notation which have to be used for the description of IRs and how the tables can be used for support statement p

13、urposes. 2 Field of application This Recommendation may be used as an introduction to the Recommendations of the T.5 10-Series. This Recommendation describes how the IRs are to be defined in the T.510-Series Recommendations and how they are to be interpreted. 3 References - - - Rec. T.400-Series Rec

14、ommendations Document Transfer, Access and Manipulation. Rec. T.500-Series Recommendation Document Application Profiles. Rec. T.560-Series Recommendation Terminal Characteristics. 4 Definitions The terms between double quote marks are defined in this clause. application: The word “Application” is us

15、ed as the generic term to represent the set of features, combining communication and document processing, on which end-users may perform operations. The “Applications” may depend on working methods and on allowed processing of documents. Examples of “Applications” are : open interchange of processab

16、le documents, cooperative working, etc. conversion process: The “Conversion” process is used to convert an ODA based format into another format (standardized format or proprietary format), and vice versa. This process should map the “Function Units” composing an ODA document to the corresponding fea

17、tures performed by the other format, if any. DAP minimum implementation requirements (DMIR): For each DAP, the DMIR identifies the set of requirements that all the “Implementations” should conform to, regardless of the “Applications”. This DMIR corresponds to the common kernel of requirements which

18、will be implemented, and therefore will ensure interworking between “Applications” selecting the same DAP. externalizatiodinternalization process: The “Externalization” process is used to encode the ODA based file into an ODIF data stream by using the coding rules expressed by ODIF (Recommendation T

19、.415). Conversely, the “Internalization” process is used to decode an ODIF data stream into an ODA based file. Recommendation T.510 (OW3) 1 ITU-T RECflN*T*SlO 93 H 4862593 0594080 533 fail-back A “Fall-back” is a guideline for an alternative processing of a “Function Unit” that may be used by a part

20、icular process when the latter is unable to process directly that “Function Unit”. “Fall-backs” may only be used when they are allowed by Is and solely by “Implementations” acting as receivers. function unit (FU): The “Function Units” are DAP constituent constraints, or combination of constraints, t

21、hat will be used to specify DAP IRs. “Function Units” sometimes correspond exactly to end-user known document processing features. generation: An “Implementation” supports the “Generation” of a particular “Function Unit” if it can issue a data steam carrying the corresponding DAP constituent constra

22、ints. imaging: When acting as a receiver, an “Implementation” supports the “lmaging” of a particular “Function Unit” if the received “Function Unit” can be further processed by an imaging process according to the imaging information given by the constituents constraints forming that function unit. i

23、mplementation: An “Implementation” is an actual realization (combination of hardware andor software) that satisfies all or part of the requirements of a particular “Application” in terms of communication as well as in terms of document processing. implementation support statement (ISS): The ISS is a

24、 proforma to be used by vendors to state which IRs are actually supported by their “Implementation”. layout: When acting as a receiver, an “Implementation” supports the “Layout” of a particular “Function Unit” if the received “Function Unit” can be further processed by a layout process according to

25、the layout information given by the constituents constraints forming that Function Unit. point of control and observation (PCO): A “Point of Control and Observation” is a point available to the user (or the tester) where data can be manipulated andor observed. This point acts as a point of control w

26、hen it is used to input some data in the “Implementation” in order to control the test procedure. On the contrary, this point acts as a point of observation when, after having performed some control on the “Implementation” under test, it is used to observe the behaviour of this “Implementation”. It

27、is through the PCOs that the user will see the “Function Units”. quaifier: A “Qualifier” is a term used to specify the level of requirement attached to a particular “Function Unit” depending on the nature of the process to be performed. For example, the processing of a particular “Function Unit” may

28、 be required for the generation process while it may be oprional for another process. reception: An “Implementation” supports the “Reception” of a particular “Function Unit” when it can interpret the corresponding constituents constraints and perform the appropriate processing. retention: When actin

29、g as a receiver, an “Implementation” supports the “Retention” of a particular “Function Unit” if this received “Function Unit” can be further accessed and processed without loss of semantic information. terminal characteristics: ”Terminal Characteristics” represent the complete technical description

30、 of an equipment which has to be developed to satisfy any particular CCITT service defined by Study Group 1. This includes the selection of appropriate “Implementation” specifications depending on the “Applications” allowed by the service. Also, “Terminal Characteristics” may specify additional serv

31、ice dependent characteristics to “Applications” and their corresponding “Implementations”. 5 Introduction to the definition of implementation requirements (IRs) The Document Application Profiles (DAPs) are described in the T.SOO-Series Recommendations. The prime purpose of a DAP is to define a set o

32、f data streams as a subset of all the data streams allowed by the ODA Standard. This is achieved by constraining the constituents and amibute values that may be contained in the data streams that conform to the DAP. For each DAP, there is need to specify the corresponding LRs. These requirements are

33、 concerned with the abiiity of implementations to generate data streams that conform to a DAF and their ability to correctly interpret the information contained in received data streams so that it can be used by the application or presented to a user. 2 Recommendation T.510 (03/93) ITU-T RECMN*T*SLO

34、 93 4862591 0594081 45T U IRs may be of two types, namely requirements which are application independent and those which are application dependent. The application independent requirements are defined in the T.5 10-Series Recommendations in conjunction with the relevant DAPs. As one given DAP may be

35、 used by more than one application, the corresponding DAP IRs defined in the T.5 IO-Series Recommendations will be independent of these applications. This ensures that all implementations based on the same DAP will at least satisfy the requirements expressed by the T.510-Series Recommendations whate

36、ver the applications are. The application dependent requirements are to be defined in the T.560-Series Recommendations describing the terminal characteristics. Implementation independent requirements are specified based on Function Units. A Function Unit is a unit to which a requirement to implement

37、ations is specified. A Function Unit is a constraint on data streams, expressed by DAP constituent constraints, their combination or condition on attribute values, etc. Requirements classification is specified in clause 6. IRs qualify every Function Unit as “required” or “optional” to be supported,

38、and also provide fall-back methods when necessary. 6 Requirements classification 6.1 Classification As stated before, a precise specification of implementation should guarantee the ability of an implementation to generate data streams that conform to a DAP and their ability to correctly interpret th

39、e information contained in received data streams so that it can be used by the application or presented to a user. Consequently, the following requirements will be addressed: - requirements on the generation of documents by the implementation; - requirements on the reception of documents by the impl

40、ementation. 6.2 Requirements on generation An implementation may claim to support the generation of a particular FU if it can issue a corresponding constrained ODIF data stream. 6.3 Requirements on reception Three different classes of requirements are specified when receiving an ODIF data stream dep

41、ending on the nature of the manipulation performed by the receiver on the received document: - Retention requirements An implementation may claim to support the retention of a particular FU if the semantics of that Fu can be retained by the implementation and can be further accessed and processed lo

42、cally. That information either can be modified by the end-user (for instance, the line spacing in a character content portion), or remains available after more general editing of the received document (for instance, automatic numbering of the footnotes). - Layout requirements An implementation may c

43、laim to support the layout of a particular FU if it can layout the document in accordance with the layout information when specified within the received document for that FU. Note 1 - If the received document does not contain any layout related information, the implementation may be able to present

44、the document to the user by performing a local layout process. The actual layout of the document is then a local matter and is not specified by this Recommendation. Recommendation T.510 (03/93) 3 ITU-T RECMN*T.510 93 4862573 0594082 39b - Imaging requiremenfs An implementation may claim to support t

45、he imaging of a particular Fu if it can present the document in a human readable form in accordance with the imaging information specified within the received document for that FU. Note 2 - If the received document does not contain any imaging related information, the implementation may be able to p

46、resent the document to the user by performing a local imaging process. The actual image of the document is then a local matter and is not specified by this Recommendation. 6.4 DAP Minimum Implementation Requirements (DMIR) In order to aid interworking between implementations based on the same DAP bu

47、t providing different applications, every DAP has a DAP Minimum Implementation Requirement MIR). Any implementation supporting a DAF must conform to the corresponding DMIR. The DMIRs are defined implicitly for every DAP in the T.510-Series Recommendations (see Figure 4). 7 Implementation model and a

48、ctual implementation 7.1 Implementation model According to the previous clause, an implementation may be viewed as a box containing two modules: generation and reception. The second is itself composed of three sub-modules: retention, layout and imaging. A partial implementation may be composed of on

49、e or more of these modules or sub-modules. A complete implementation, that is an implementation composed of all the modules and sub-modules, should, at least, satisfy the DMIR of a given DAP, and can make use of an appropriate set of partial implementations. 7.2 Points of control and observation (PCO) In order to specify only requirements that can be observed, and consequently for testing purposes as well, it is necessary to define the possible points of control and observation (PCO). As illustrated in Figure 1, the points of control and observation are: - The data stream: input o