Comparing Styling in Layout-driven &, Content-driven Documents   Table of contents   Indexes   Most Frequently asked business questions about XML from current or prospective SGML users
 
 

AECMA 1000D and IETP : Diverse approach to define IETP from Data-Modules;
, SGML, HyTime, HTML or XML ? You don't have to choose!
 
Michel   Domeon
  Head of Cals Technical Applications Department
  Dassault-Aviation
Military Customer Support Division Support Product Department 78 Quai Marcel Dassault - cedex 300
St Cloud   France  Cedex 92552
Phone: +33 1.47.11.31.39
Fax: +33 1.47.11.31.39
Email: michel.domeon@dassault-aviation.fr Web: www.dassault-aviation.fr
 
Biographical notice:
 
Michel Doméon
 
Michel Doméon is currently working for DASSAULT-AVIATION and has been involved in both the military and civil technical documentation process, especially for information systems.
 
From DCF (IBM) to XML through SGML and HTML, he has been in charge of studying and promoting these technologies within the company.
 
From 1994 he has been involved in AECMA 1000D Specification : First as co-chairman then as chairman of theEPWG  (Electronic Publication Working Group) in charge of all technical aspects of the specification (DTD, Graphics, exchange...)
 Glasgow 
Malloy, Thomas
MoDUK
 United Kingdom 
 
Thomas   Malloy
  Head of Policy
  MoDUK
Kentigern House
Glasgow   Scotland  United Kingdom  G2 8EX
Phone: +44 141 224 2587
Fax: +44 141 224 2142
Email: tmalloy@gtnet.gov.uk
 
Biographical notice:
 
Thomas Malloy
 
Thomas Malloy currently works for the Air Technical Publications branch within Deputy Directorate for Acquisition logistics (RAF) as Head of Policy. He is involved with the policy generation for both paper and electronic documentation for the Royal Air Force (RAF) and the Ministry of Defence (MoD) as a whole. This has meant involvement in the development of Defence Standard 00-60, the UK standard for Integrated Logistic Support, with emphasis on the part covering electronic documentation. External to the MoD, he has been involved in the Nato environment covering Electronic Documentation and is the Co-chair and dogsbody of the AECMA 1000D EPWG .
 
ABSTRACT:
 AECMA 1000D  
Data-Modules
 HTML, Hypertext Markup Language 
 HyTime 
 IETP 
 SGML 
 XML  
 
The first part of this paper describes the AECMA 1000D modular approach and the concept of data-modules and CSDB  (Common Source DataBase) . With the following part describing several approaches for generating IETP  (Interactive Electronic Technical Publication) derived from source data.
 
Depending on the delivery needs, SGML  (Standard Generalized Markup Language) , HyTime  (Hypermedia Time-based Structuring Language) , or Web/ HTML  (Hypertext Markup Language) , publication constructs will be discussed and a final focus on XML  (Extensible Markup Language) delivery advantages will be addressed.
 
For the purposes of this presentation the authors Thomas Malloy and Michel Domeon will adopt the personas of Mr M and Mr D, members of the MIB  (Men in Black) Protecting the EARTH from the scum of the universe, people who want to write and produce paper only.
 
 

AECMA Presentation
 
 

What is AECMA?
 AECMA 
 
AECMA  (European Association of Aerospace Constructors) is an association of European Aerospace Industries, which was founded in 1950 as a forum for Industry leaders. The association covers nine European nations and is recognised as being fully representative of the European aerospace industry.Its primary aim is to "Promote and represent European aerospace interests within the EEC and World-wide".
 
EDWG
EPWG
TPSMG
 

The AECMA working group structure

 
AECMA Organisation

 
 
The above structure reflects the specification coverage of AECMA, the reader should concentrate on the AECMA 1000D Specification at the Technical Publication Specification Maintenance Group(TPSMG) level. The TPSMG is made up of Industry and MoD members at a management/specialist level. One of its tasks is to monitors and controls sub-working groups of which at the time of writing there is one, the Electronic Publications Working Group (EPWG). The EPWG is the working group whose main task is to generate all electronic aspects of the specification including SGML and graphics.
 
 

AECMA S1000D
 
 

What is AECMA S1000D?
CSDB
 
AECMA S1000D is a specification for "Technical Publications utilising a Common Source Data Base". Documentation produced to AECMA S1000D will be in the form of units of information called Data Modules. All the Data Modules required to produce a technical publication are held in a CSDB . To facilitate ease of data management and transfer between IT systems the information is prepared using SGML . Each of the above will be covered more fully later in this paper.
 
 

Why AECMA S1000D?
 
The specification that exist today and are used on legacy systems are rooted in tradition with wide interpretation being applied by the controlling bodies, they exist to cover page and book based information. AECMA S1000D provides a migration from pages and books to digital delivery and use. it accomplishes this by providing a Numbering Scheme which is universal and can be used on any project, allowing integration with other logistics specifications, i.e. S2000M, Logistics Support Analysis etc.
 
What AECMA S1000D is not is another paper publications specification, database model or a definition for a computer software application.
 
It however has some major benefits it is Non Proprietary, allows neutral delivery of Data and management of data also it uses the CALS philosophy of "create once use many" .
 
 

AECMA S1000D status
 
Work started on AECMA S1000D in 1983, with the present status being that the specification is at Change 7
 
Details of the DTDs can be found on the AECMA WEB site : www.aecma.org.
 
Change 7 has introduced constructs for:
  • Schedules information
  • Aircrew information
  • Maintenance/Fault diagnosis information
  • Illustrated Part Data information
  • Enhanced structure for Interactive Electronic Technical Publications
    •  
     

    AECMA S1000D structure
     
    The specification is split into four main chapters covering the requirements to allow users to create a technical documentation. Several key concepts are put forward in the specification. These are detailed below:
     
     

    Common Source Data Base(CSDB)
     
    The AECMA S1000D Definition for a CSDB is "a 'store' of Data Modules required to produce technical publications". A CSDB is a collection of units of information describing a particular task, system, subsystem or component of an Air vehicle or equipment. Each of these units of information is called a Data Module. The specification defines a hierarchical structure for the organisation of Data Modules which make up a CSDB. However it does not define how a CSDB should be structured or organised.
     
     

    Data Module
     
    The AECMA 1000D Definition for a Data Module is "a self contained unit of data containing text and/or illustration on the operation and maintenance of an Air Vehicle, airborne engine, airborne equipment and support equipment. The unit of data is produced in such a form that it can be inputted to, and retrieved from, a data base using the Data Module Code (DMC).
     
    Each Data Module is assigned a unique identifier (DMC), which indicates its position in the hierarchical structure of the CSDB and also describes the information contained in the Data Module. The Data Module has some unique characteristics, it is;
  • A self contained unit of data
  • Neutral (independent of media)
  • Capable of linking "level, skill etc." to information for the User
  • Capable of Digital Information Interchange
  • Flexible, allowing Data retrieval (will produce differing sets of data)
    •  
     

    Data Module Types
     
    There are several types of Data Module allowable within AECMA covering many types of information, below are some examples:
  • General data
  • Crew Drills
  • Technical data
  • Description of how it is made and its function
  • AGE, tools and software
  • Software documentation
  • Operation
  • Servicing
  • Examinations, test and checks
  • Failure reports and isolation procedures
  • Storage procedures and data
  • Illustrated Parts Data
    •  
     

    Data Module Structure
     
    A Data Module consists of an Identification and Status section and a Contents section. These sections are further broken down into elements, with examples shown below;
     
    Identification and Status elements
  • Data Module Code
  • Title
  • Issue Number
  • Security Classification
  • Originator
  • Applicability
    •  
    Content elements
  • Effectivity
  • Security Classification
  • Change marks and highlights
  • References
  • Description
  • Procedures
  • Spares
  • etc
    •  
    The DM structure is applicable to Air vehicles, engines and equipment but it is easily applied to other vehicles and associated equipment, with this being accomplished within many countries.
     
    DMC
     

    Data Module Code (DMC)

     
    A standardised structured address called the DMC is used to manage the input, access and retrieval of Data Modules. There are two distinct types of DMC covering Air vehicles, engine or airborne equipment and support and training equipment.
     
    The DMC is a 17 character code, divided into eight groups as shown in example below :

     
    data module code structure

     
    Group a
     
    The first two characters are the Model Identification (MI) Code, which identifies the specific model of an air vehicle or engine to which the data module applies. MI codes are allocated by AECMA and issued as a block, as required for the number of models which the project expects to produce.
    Group b
     
    The System Difference Code (SDC), a single alpha character applicable to the first four characters of the SNS. Used when different systems with the same system/ subsystem identification, but carrying out the same function, are used. e.g. Radar installations designed and manufactured by different suppliers
    Group c
     
    The Standard Numbering System (SNS), consists of 3 pairs of digits.
     
    The SNS is designed to provide standardisation in the arrangement or addressing of material. Two terminology's are applicable; Chapter/Section/Subject or System/Subsystem/Sub-subsystem. Two SNS are also detailed in the specification covering; Air vehicle, engine and airborne equipment and missiles.
     
    These detail a hierarchical breakdown of the major systems and components of the air vehicle, engine and associated equipment. The SNS is identical to that used in ATA 100, with the addition of additional codes for weapon systems.
    Group d
     
    The Disassembly Code identifies the assembly, sub-assembly or component to which the Data Module applies. The numbering scheme is based upon the Disassembly principle which states that there is consecutive numbering of sub-assemblies and components as they are removed from the highest level assembly (code 00). For example the first sub-assembly removed is coded 01, the second 02, etc.. This code also has a variant which designates alternative items of equipment differing in design, but not enough to change the System Difference Code.
    Group e
     
    The Information Code is a three numeric character code used to identify the type of information covered by a Data Module;
     
    The Primary Information Codes are :
    • 000 Function, data for plans and description
    • 100 Operation
    • 200 Servicing
    • 300 Examinations, tests and checks
    • 400 Failure report and isolation procedures
    • 500 Disconnect, remove and disassemble procedures
    • 600 Repairs and local-make procedures and data
    • 700 Assemble, install and connect procedures
    • 800 Storage procedures and data
    • 900 Miscellaneous
     
    This code also has a variant which indicates procedural variants that may need to be covered;
     
    Example: Information code 641A may denote anodising a component using a chemical bath and 641B is anodising using swab solution
    Group f
     
    The Item Location Code is a single alpha character that indicates where the maintenance task will be carried out or where the information is applicable to. The codes are :
    • A Information related to items installed on the air vehicle
    • B Information related to items installed on an engine or major assembly removed from the air vehicle
    • C Information related to items on the bench
    • D Information related to all three locations A, B and C. No other combinations allowed!!!
    • T Information related to training only data modules.
     
     

    Support and training equipment DMC
     
    The data module code for support equipment is detailed below and is further detailed in S1000D

     
    data module code structure for AGE

     
     
    Simplified English
     

    AECMA S1000D Writing Rules

     
    AECMA S1000D also has writing rules, covering language, dictionaries etc. The use of another AECMA specification is also quoted. AECMA Simplified English, S1000D states that procedural instructions shall be written in AECMA Simplified English, with descriptive text having the "writing rules" in Part 1 of AECMA Simplified English applied. If this excites you should read the specification.
     
     

    AECMA S1000D Illustrations
     ATA, Air Transport Association 
    CGM open initiative
     
    The specification details a chapter on the modes of presentation, types of illustrations, and there control using an Illustration control number. However the production of illustrations for an electronic environment is not covered, with AECMA keeping an eye on the ATA and CGM open initiative work being done in this area. The illustration formats allowed within the specification are the CALS graphic standards
    • MIL PRF 28002 Raster graphics (cals type 1)
    • MIL PRF 28003 CGM graphics Cals profile
    • JPEG
     
     

    AECMA S1000D DTD
     
    The DTD has been developed with the following objectives:
  • Modular form. The DTD's have a modular form. The modular concept will assist in the generation, and simplification, of electronic commenting procedures by its ability to readily identify relevant information at the lowest level possible.
  • Compliance with standards. The prime structure of the DTD's reflect the AECMA 1000D specification. The DTDs comply with ISO 8879.
  • Upward compatibility. To ensure upward compatibility between the initial DTD's and subsequent issues.
    •  
     

    Theory of Operation
     
    The DTD consists of three parts, each part may contain one or more entity
     
    The 3 parts are:
  • the 'main' controlling entity
  • the 'location definition' entity
  • the 'body' of the DTD
    •  
    Paths through the DTD are controlled by incorporating the different entities required.
     
    There is one "main" entity for each type of Data Module structure. The DOCTYPE statement at the start of each Data Module specifies which "main" controlling entity should be used for that structure.
     
    Each "main" entity:
  • Defines the location of the "components definition" entity.
  • references the "components definition" entity which defines the physical locations of all the other AECMA 1000D DM DTD entities.
  • references the type of address & status information entity. (AGE or AVEE)
  • references the "body" of the DTD. (BASE)
  • references the type of applicability information. (AGE or AVEE)
  • references the type of content model. (AIRCREW, DESCRIPT, etc)
  • references the common content model. (CONTENT)
    •  
    AECMA 1000D also details the the formal public identifiers, parameter entities, elements and attribute lists allowable within the specification.
     
     

    AECMA 1000D - interchange of data modules
     
    To achieve an orderly and systematic digital interchange of DMs, it is necessary to work within a set of formal data interchange standards and procedures.
     
    The digital exchange of Data Modules is based on MIL STD 1840  (Automated Interchange of Technical Information.)
    1840
     
    There are two aspects to the satisfactory delivery of DM:
    • the delivery of DMs in accordance with the transfer protocols defined in the standard
    • the integrity of the DMs themselves with respect to AECMA S1000D.
     
    Mil Std 1840 defines how data will be packaged for transfer between parties and the standards to which that data shall be prepared.
     
     

    AECMA S1000D and Technical Publications
     
    Previously we have concentrated on the "core" parts of the specification which allow us to create publication building blocks called Data Modules. The next part of this paper will focus on the aspect of building publications from these blocks. For paper output the information to be presented is grouped into categories called information sets which correspond to the common publications used for the support of an air vehicle
     
    The specification describes the purpose, scope and content of each publication and the content and coding of all the required Data Modules necessary to complete an information set, examples are given below
  • ACL - Air Vehicle Cargo Loading
  • ACS - Air Vehicle Cross Servicing
  • AFI - Air Vehicle Fault Isolation
  • AGE - Air Vehicle Ground Equipment
  • AM - Air Vehicle Maintenance
    •  
    Also described is the format of presentation for the paper publications. However our main thrust is the generation of IETP .
     
     

    AECMA S1000D and IETPs
     
    A publication contains DM and associated illustrations extracted from the CSDB , with the addition of generated data derived from the DM (eg table of content, list of illustrations), and specific information created for the publication (eg access illustrations).
     
     

    Publication modules
     
    A publication module is required to define the publication content and its final structure. Each publication module defines the list of DM to be collected, the list of data to be generated, and the specific navigation or access illustrations needed in the publication. The publication modules are defined in SGML or HyTime formats and are described in the relevant IETP chapters.
     
     

    Publication construction
     
    The building of the publication shall be independent to the end-user presentation software. This requires that the publication is built in two steps.
     
     

    Intermediate form
     
    The publication in intermediate form is implemented in a SGML/HyTime format known as a publication DTD, with illustrations in CGM, CCITT Gr4 or JPEG files.

     
    Intermediate form, step one

     
     
     

    End user deliverable
     
    Building the end-user deliverable publication depends on the end-user software and hardware.

     
    End user deliverable, step two

     
     
     

    Type of Publication
     
    The IETPs presently covered within the specification are :
  • IETP-L Linearly structured
  • IETP-D Database oriented
  • IETP-I Integrated (not yet specified)
  • IETP-H HTML web oriented
    •  GUI, Graphical User Interface 
     
    All the above IETP construct have one aspect in common this is the rules for the Graphical User Interface(GUI) , where AECMA specifies rules such as:
    • number of windows/panes,
    • scroll bars, types and dimensions
    • button styles/set
    • User interface (ie search.)
     
    This aspect is meant to lay down rules for "front ends" that will allow the same look and feel across IETP types thus creating standardisation and reducing learning time.
     
     

    IETP-L : linearly structured
     
    IETPL
     

    Definition

     
    This chapter concerns the interactive electronic display of technical information specially authored into and maintained in a linear SGML document. The source data, which comprises DMs extracted from the CSDB (core data) and specific data for the particular publication, is then assembled into a linear SGML document and is subsequently packaged (ie view-packaged) in a proprietary application for interactive presentation. An overview of the process is depicted in the following figure.

     
    IETP process

     
     
    An IETP-L must contain all relevant information necessary to allow the building of an end-user deliverable publication.
     
    The IETP-L is based on SGML standard for the text definitions.
     
    This IETP-L is defined through:
  • A package of SGML DTDs:
  • A catalog to associate each SGML or graphic component to a specific file
  • The SGML, CGM and raster specifications
    •  SUBDOC 
     
    For IETP-L the core of the IETP will refer to the SGML instances of data-modules. To manage the diverse types of DM that may be included, the use of entity management and SUBDOC structure will allow the parser to accept inside the IETP-L, the structure of all DM (eg PROCED, DESCRIPT, AIRCREW, IPD) These DM calls are implemented through the use of elements with an attribute of ENTITY type (general entity name attribute). All these entities are SGML documents with their own DTD. The entity type must be SUBDOC.
     
    The use of SUBDOC is shown in the specification, but implementation can be completed in a proprietory manner.
     
     

    Structure
     
    The IETP-L structure is divided into two parts:
    • An IETP STATUS part (derived from the data module status part)
    • An IETP content part made from:
      • A specific IETP introduction
      • The inclusion for one or more table of content (by SNS, by info code, etc)
      • The core of the IETP which contains the call to the necessary data modules
      • The inclusion of generated lists:
        • LOI List of illustrations
        • LOSU List of supplies
        • LOSE List of support equipment
        • LOSP List of spares
        • HLT Highlights
        • LOEDM List of effective data modules
        • IDX Index
     
     

    Linking mechanism
     
    This IETP-L DTD is based on the SGML ENTITY management only and does not include HyTime links as in IETP-D publications.
     
    The core of the IETP-L uses the SUBDOC management to access the SGML instances of the referenced data-modules.
     
     

    Advantages and Disadvantages

    IETP-L Advantages and Disadvantages
    Advantages Disadvantages
    Easy to produce Use of SUBDOC not generally supported
    No enhanced mechanism to understand No enhanced links mechanism to use, Specifically for inter IETP links (need to add proprietary or HyTime links)
    Full respect of basic standards (neutral form garanteed) Don't keep the modular aspect, by gathering all DM in one instance
    Not prepare for the future with web and XML delivery (don't keep the modular approach)
     
     

    IETP-D : Database oriented
     
     

    Definition
    IETPD
     
    This chapter concerns the interactive electronic display of technical information specially authored into and maintained in a non-redundant relational or object-oriented hierarchical database. This source data is subsequently packaged (ie view-packaged) as a run-time database for interactive presentation.
     
     

    Structure
     
    The IETP-D structure is based upon four levels:
    1. At the first level, there is the DM conforming to the AECMA 1000D DM DTD, with title, status and content sections.
    2. At the second level, a new instance called Data Module Header (DMH) is defined (one for each DM). This DMH is the only point of access to a DM. This DMH contains:
      • A generated TOC of each DM (eg status, contents and steps)
      • A glossary (for all tagged terms used inside the DM)
      • All HyTime links to access information within the DM
      • The inclusion of generated lists:
      All these DMH may be easily generated from the tagged elements of each DM.
    3. At the third level there is a list of Effective Data Module Header (LOEDMH) instance which contains all the DMH locations (list of nameloc/nmlist).
    4. At the fourth level the IETP-D instance is defined and contains only:
      • An IETP status
      • The entry points inside the publication, which in these examples include (but are not limited to) the generated data (TOC, LOI, LOEDM, etc)
      • All the links to access the generated data
      • The links to the hub (LOEDMH)
    		 
     
    The publication allows the end user to access to different entry points (TOC by zoning, TOC by chapter, glossary, LOI, etc). After selection of an entry point, the system links to a hub (LOEDMH) which contains all the DMH locations, and presents, to the end user, the structure of each DM which is already defined in this header. The user can only access information within the DM at this level (using ilinks), because the DMH contains the location of each portion of the elementary DM.
     
     

    Linking mechanism
     CLINK 
    ILINK
     
    The linking mechanism is detailed in the following figure. The HyTime ilink (independent link) definition has been selected in preference to the clink (contextual link) definition. Both definitions are described in ISO 10744.

     
    Linking mechanism schematic

     
     
     

    Advantages and Disadvantages

    IETP-D Advantages and Disadvantages
    Advantages Disadvantages
    keep the modular aspect, by only linking to DM instances More complicated to understand and produce than IETP-L
    enhanced links mechanism (powerfull ilink architectural form) Few HyTime engine available, and most of tools didn't support ilinks (replaced by clinks)
    Full respect of basic standards (neutral form garanteed) Need the automatic building of Data module headers and HUB instance (LOEDMH) to reflect the cross references linking mechanism
    Prepare an XML delivery by keeping the modular approach HyQ queries must be replaced by SDQL
     
     

    IETP-H : Web HTML
     
     

    Definition
    IETP-H
     
    This chapter details the general features which are required in order to deliver SGML-coded data modules as an IETP through HTML tagging on the WEB from a CSDB.

     
    Internet/Intranet IETP delivery process

     
     
     

    Structure
     
    The hierarchical structure of technical documentation data for delivery on the WEB is based upon three levels:
    1. Upper level - LOAP
    2. Intermediate level - IETP
    3. Base level - Data modules
    		 
     
     

    Upper level - LOAP
     
    Contains the list of all applicable publications and the way to address them either through textual or graphic link.
     
     

    Intermediate level - IETP
     
    An IETP is constructed for a specific subject and defines the links to the relevant base level data modules.
     
    The IETP contains an introduction, status, tables of contents and generated data allowing the end-user to access a relevant data module. Examples of generated data are:
    • LOEDM - List Of Effective Data Modules
    • HTL - Highlights
    • INDEX - Index
    • LOI - List Of Illustrations
    • LOSE - List Of Support Equipment
    • LOSU - List Of Supplies
    • LOSP - List Of Spares
     
     

    Base level - Data modules
     
    These DM conform to the AECMA-1000D DM DTD, with identification, status and content sections
     
     

    hierarchical levels presetation

     
    Hierarchical levels of technical documentation

     
     URL 
     
    The proposed structure is based on the fact that the URL (directories and filenames) can be automatically deduced from:
    • reference to DMC structure for data modules
    • reference to TPC for IETP
     
    In the proposed solution, the data modules are stored independently from the IETP, the organization is as given in following figure which illustrates a directory and filenaming method.

     
    Files and directories structure

     
     
     

    Linking mechanism
     
    The URL structure is as follows:
     
    "protocol://host/path/filename" where:
    • protocol can be http, ftp, news, etc
    • host is the ID or internet address of the system. The IP number may be directly addressed but generally the domain name is issued (on local platforms "protocol://host" element is not required)
    • path and filename allows a file to be addressed using either relative or absolute paths
      • in relative mode "../path/filename"
      • in absolute mode "file://path/filename"
      • path and filename allows a file to be addressed using either relative or absolute paths
     
    The HTML structure also allows a specific file at a specific target to be opened. This requires an anchor using the "A" tag with a specific ID to be defined in the HTML file. To locate the link at this anchor, the character # with the anchor name must be added after the URL filename location.
     
    The following Table defines the various links available in S1000D structures, for referencing URL location.

    Aecma Url structure
    Element Context Title Type of link URL example
    dmcref DM Reference to DM intra/inter IETP link ../DM/YY-A-32/16-01-00A-520A-A.HTM
    partno DM Part number IPD link (Part number repository) ../DM/YY-A-53-25-10-02A-999A-A.PNR
    Table DM CALS table ref table access direct in file
    Xref DM Cross references (supply, support, tables, figures) DM internal link #supportid1
    ICN DM Illustration control number illustration access ../IMAGES/CGM/0004A011.CGM
    CSN DM Catalogue sequence number IPD link (inside nomenclature) ../DM/YY-A-53-25-10-02A-999A-A.HTM#CSN04
    DMC LOEDM DM reference ../DM/YY-A-32-16-01/-00A-520A-A.HTM
    DMC LOI DM reference ../DM/YY-A-32-16-01/-00A-520A-A.HTM
    DMC LOSU DM reference ../DM/YY-A-32-16-01/-00A-520A-A.HTM
    DMC LOSE DM reference ../DM/YY-A-32-16-01/-00A-520A-A.HTM
    DMC TOC DM reference ../DM/YY-A-32-16-01/-00A-520A-A.HTM
    RTX DM-IPD Refer to link DM + CSN ../DM/YY-A-53-25-10-02A-999A-A.HTM#CSN04
    CSN REPNR CSN link from part number repository ../DM/YY-A-53-25-10-02A-999A-A.HTM#CSN04
    CSN IPD CSN item inside IPD (figure/text link) ../DM/YY-A-53-25-10-02A-999A-A.HTM#CSN04
     
     

    Advantages and Disadvantages

    IETP-H Advantages and Disadvantages
    Advantages Disadvantages
    Easy to understand Need a convertion from SGML to HTML
    Easy to convert from SGML to HTML as Aecma 1000D DTD has powerfull DTD's Structure loose
    keep the modular aspect, by only linking to DM instances
    Dm structure well defined for WEB delivery
    Enhanced links mechanism (powerfull url and href combination)
    Respect of standards (neutral form garanteed)
    Prepare an XML delivery by keeping the modular approach and url links
    Cheap and powerfull browsers available
    Easy browsing enhancement (lots of plugins, java(script) development)
     
     

    IETP-X XML oriented
     
     

    XML and AECMA 1000D
     
    the XML interest for AECMA community, the work in progress, the advantages of XML IETP will be define here
     
     

    Advantages and Disadvantages

    IETP-X Advantages and Disadvantages
    Advantages Disadvantages
    Easy to understand Need the 2 last parts of XML standard to be widely adopted (links and style)
    No loose of structure (keep Aecma 1000D powerfull structure)
    Respect the modular aspect, by only linking to DM instances
    enhanced links mechanism with combination of WEB url and HyTime links
    Respect of standards (neutral form garanteed)
    No need of complex convertion from SGML source code
    Cheap and powerfull browsers available
    Easy browsing enhancement (lots of plugins, java(script) development)
     
     

    Conclusion
     
    The AECMA IETP modular approach, with Data Module concept as small unit of information, is well dedicated and well adapted to the web technologies.
     
    The achievement of an AECMA 1000D XML IETP will be addressed inside the AECMA spec to cover the gap left by the existing IETP structure and to gather the advantages of : The HyTime Linking mechanism already defined for IETP-D and The URL linking mechanism for WEB delivery, very adequate with the Spec 1000D modular approach.
     
    With these IETP-X, new AECMA armament generation, the M.I.B mission will at least be achieved : 'allowing us to protect the EARTH from the scum of the universe : people who want to write and produce and deliver paper only'
     
    Acknowledgments
      The authors wish to express their thanks to the MIB and AECMA organisation, their company, the GCA organisation, their fathers, mothers, and all the people who succeed to read this paper until the conclusion.
    Comparing Styling in Layout-driven &, Content-driven Documents   Table of contents   Indexes   Most Frequently asked business questions about XML from current or prospective SGML users