1. Overview

In order to set up an e-Business Information Sharing (eBIS) environment there must be some way to capture community agreements on the structure and types of data that will be interchanged. There must be some agreement made on use of an interchange syntax that is understood across a variety of platforms and applications. The World Wide Web Consortium (W3C) has defined such a syntax: the Extensible Markup Language (XML). XML and its structure definition approach, using either XML Document Type Definitions (DTDs) or XML Schemas fits these requirements.

XML has become widely embraced by the web and data interchange communities. XML has become the defacto data interchange syntax to support e-business information sharing.

While there is general agreement on the use of XML to support an eBIS environment, there is no wide spread agreement on the structural parts of the Architecture that would enable such an environment. Many vendors, industry groups, and consortiums are proposing diverse visions for the architectural structures that will enable a company to enter fully into the e-business arena.

The Boeing eBIS Architecture Baseline is a vehicle to reach a common vision with Boeing's partners, customers, and suppliers on these structural parts. This baseline will also be used to reach a Boeing consensus in defining and deploying an eBIS Infrastructure.

Exploration and examination of differences in diverse visions will help The Boeing Company define architectural structures that will work best in our current computing environment to meet our business needs. Having an eBIS Architecture Baseline will help us better assess alternative e-business solutions in this area, now and in the future.

A team of Boeing architects has identified an initial eBIS Architecture Baseline that supports this type of exploration and examination. Described below are the structural parts of the eBIS Architecture Baseline:

· Framework

· Elements

· Core Data Services

· Conceptual Architecture and Use Cases

· Organization and Management Support Services

2. eBIS Framework

Figure 1 eBIS Framework

2.1. eBIS Framework Services

The eBIS Framework identifies 4 main services: Acquire Services, Administer Services, Distribute Services, and Life Cycle Management Services. These services are shown in more detail in figure 2.

Figure 2 eBIS Core Services

2.1.1. Acquire Services

These services support creation or procurement of electronic information. The information is packaged as structured information objects (SIOs), which can be content objects or metadata objects in the eBIS environment.

Note: For more information on SIOs see section 3.

2.1.1.1. Model Services

Model Services provide:

· Model and schema definition service

· Taxonomy development service

· Mediation service for structures, tag semantics, tag use

· Mapping service between taxonomies, structures, and tags

2.1.1.2. Classify/Categorize Services

Classification and Categorizing Services provide:

· Classification service for organizing SIOs per defined metatags or approved taxonomy categories (classification scheme)

· “Lookup” service for finding appropriate metadata structures (Schemas and DTDs) for use in categorizing SIOs

· Indexing service for SIOs (full text automated indexing, cross-referencing, etc.)

· “Lookup” service for searching through abstracts (summaries) of the SIOs

· Ranking service to determine the relevance of "found" SIOs; and as an aid to determine how to proceed

2.1.1.3. Build and Procure Services

The Build/Procure services support the use of consistent structure and content for SIOs when they are created or procured. This consistency is needed for sharing SIOs among multiple applications in the eBIS environment. These services operate over and above the normal editing and formatting services found in any word processing package.

Build and Procure services provide:

· Search and selection of resources (content or metadata objects) -- general or use specific

· Search and selection of appropriate version of a content object (with all the associated metadata) or metadata object.

· Assignment identifiers to content objects or metadata objects

Ø Appropriate or unique names,

Ø Unique qualifiers (namespace, date, etc.)

Ø Metadata within the appropriate ontology and schema.

Aid the creator in creating, updating, and validating the content object or metadata object by enabling:

· Addition of structured information to the content object or metadata object under construction.

· Attachment or merger of structured information, content objects, or metadata objects to a content object or metadata object being updated or created.

· Generation in part or in whole, of content object or metadata objects through use of a form.

· Validation of the content of the content object to language rules (spelling, grammar, vocabulary (i.e. Simplified English)).

· Validation of the links to resources attached during the attach/merge processes.

· Establish relationships/associations between content objects and metadata objects.

· Validation of the content of the metadata object to established metadata rules.

2.1.2. Administer Services

Administer Services support identification, storage, and retrieval of SIOs, and provide summaries of SIOs for the user. Cataloging tools provide multiple views of SIOs to facilitate their creation, identification, storage, retrieval, and distribution.

2.1.2.1. Release/Register Services

Release/Register Services provide a standardize method to ensures that the validation and release rules are met before the content object or metadata object is registered for use or access.

Release/Register services provide:

· Validation that the structure of the object conforms to syntactic rules embodied in the DTD or schema

· Validation that the encoding format conforms to the formal syntactic rules

· Validation that the SIO's content is in conformance to value, range, or other data creation rules for objects of that type.

· Validation that the business rules, policies, and guidelines (e.g., appropriate Quality Control operations, reviews and approvals) have been followed before the content or metadata objects are made available for use.

· Status indicators for SIOs indicating their current state (in-work, in-test, deprecated, in-use, etc.).

2.1.2.2. Profile Services

Profile Services capture business rules or contractual agreements (profile metadata) about interchange of data or access to data.

Profile Services provide:

· Metadata definitions for such items as user role, application type, default modes of presentation, default uses, etc.

· Metadata definitions for timing conditions and quantity distributions, which must occur at a certain date or time intervals

· Support for the distribution or access to content SIOs by groups of users or applications.

2.1.2.3. Name and Linking Services

Naming and Linking Services ensure that unique identifiers (name, version, and namespace) are assigned to content object and metadata objects and appropriate registries are updated.

Naming and Linking Services provide:

· URI Assignment mechanism

· SIO location aids

· Maintenance service for URI links to schema objects, metadata objects (descriptions, abstracts, and definitions), rules within registries, dictionaries, lookup tables, catalogs and directories

· URIs for objects

· Unique names

· Administration service for linking relationships/associations

2.1.2.4. Secure and Authenticate Services

Secure and Authenticate Services generate and validate security, authenticate, and integrity metadata based on established rules specific to an SIO or an SIO type.

Secure and Authenticate Services provide:

· Authentication and verification service for the identity of a user or a software process attempting to access a resource

· Access authorization service for entities such as users, user roles, programs, or processes access to system resources.

· Security disclosure service to ensure that data is not disclosed either intentionally or accidentally to unauthorized individuals, entities, or processes

· Change authorization service to ensure that no unauthorized changes are made to data or the system

· Monitor and alert service for system administrators regarding conditions that may violate established security measures.

· Security update service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information reflecting the current security and authenticate values for the SIO or SIO type.

Integrity Services provide:

· SIO metadata configuration management service to ensure creation and modifications to SIOs are based on rules appropriate to the process being performed against it or based on configuration control rules. Ensures that:

Ø Versioning and control information on the SIO is updated per established rules.

Ø Transaction metadata information is updated to show which services have used the content object in its process. Business rules establish which content objects require this kind of transaction tracking.

Ø Only authorized access content objects or metadata objects is made by users, applications, or agents.

· Version control service to ensure all the appropriate catalogs, directories, registries, logs, etc. are updated with the appropriate information reflecting this creation or modification of an SIO.

2.1.3. Distribute Services

Distribute Services ensure that the content object is delivered in the right format, in the right quantities, to the right people, at the right location, at the right time.

2.1.3.1. Push Service

Push Service enables delivery of SIO to recipients.

2.1.3.2. Web Assembly and Convert Services

Web Assembly Service supports the location, retrieval, transformation, and assembly of SIOs into a web-able delivery package.

Web Convert Service supports the transformation and rendering of SIOs for consumption by the recipient through the web.

2.1.3.3. Notify and Subscribe Services

Notify Service provides push notification that an SIO has been changed or re-located.

Subscribe Service provides the ability to locate one or more SIOs meeting the criteria specified. Requests to locate SIOs can be made on a subscription basis

2.1.3.4. Search and Filter Services

Search Service provides the ability to lookup information based on default parameters. This service also provides notification when the content object has been found or is available for some use.

Filtering Service provides the ability for users to customize the parameters that will be used to determine the space (number of candidates, sublevels followed, areas of interest) that will be searched based on criteria that is set by the searcher.

2.1.4. Life Cycle Management Services

Life Cycle Plan Services make available SIOs for use and reuse for the specified period the object is deemed to have business value or a legal requirement for its existence.

2.1.4.1. Storage Services

Storage Services provide optimal physical placement of content objects on one or more servers that facilitate access and retrieval across a distributed environment.

Storage Services provide:

· Determination of the appropriate/optimal storage location(s) for the SIO and the appropriate/optimal storage formats for the SIO.

· Life cycle storage service to ensure that all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information in regard to the storage of SIOs.

2.1.4.2. Disposition Services

Disposition Services remove SIOs from the web using established rules for this type of SIO.

Disposition Services provide:

· Backup service to copy the SIOs contained in active data stores into a backup data store.

· Retirement service to assign sunset dates on SIOs.

· Refresh service to maintain the SIOs in a format that is useable and accessible in the current computing environment.

· Disposition management service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information in regard to the disposition of the SIOs.

· Retrieval and restoration service to move backup copies of SIOs from the appropriate short-term archive into a web accessible data store.

Disposal Services provide:

· Removal of SIOs from the web accessible data store.

· Disposal management service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information in regard to the archival/disposal of SIOs.

· Archive management service to package SIOs with all the registry metadata and other appropriate metadata supportive of long term archival.

Restoration Services provide:

· Retrieval and restoration of archived copies of SIOs from the appropriate long term archive into a web accessible data store.

· Restoration management service to ensure all the appropriate catalogs, directories, registries, logs, etc. contain the appropriate information in regard to the restoration of SIOs.

2.2. eBIS Framework Standards

The eBIS framework services are supported by a set of technical standards. A preliminary set of XML-based standards has been identified that need to be put in place as Boeing Architectural Standards Bulletins (ASBs).

Figure 3 eBIS Framework Standards

2.3. eBIS Framework Tools and Applications

The eBIS framework services are supported by a set of tools and applications for data interchange. A matrix of these tools and applications has yet to be developed. The development of this matrix should be done in conjunction with already established companywide technical, process, and product standards. It should use processes and infrastructure established by the Architecture Sub-council of the Information Systems Process Council.

Figure 4 eBIS Framework Tools and Applications

The eBIS tools and applications should:

· Enable deployment of eBIS services and architectural elements.

· Make use of the targeted technical standards.

· Be lightweight and have the capability of being rapidly reconfigured to support changing business rules and technical models.

Figure 5 Tools supporting Data Creations and Distribution

Figure 6 Tool Types supporting Portal distribution of data

The appropriate groups within Boeing should be tasked to:

· Prepare a matrix software tools and prepare a Standard Software Services Offering Website to describe:

Ø Specifics about the common tools

Ø Use of common tools

Ø Location of common tools.

· Prepare a Standard Software Services Offering Website to describe:

Ø Specifics about the common tools

Ø Use of common tools

Ø Location of common tools.

· Define and enable:

Ø Services to exchange mechanism to share information between application

Ø Transport mechanism

Ø XML interfaces (for each platform)

Ø Tools supporting eBIS processes (may make available on an enterprise-wide basis as required).

2.4. eBIS People Skills

The appropriate groups within Boeing should be tasked of developing a matrix of the eBIS people skills that would enable deployment of eBIS services and architectural elements.

Figure 7 eBIS Framework People Skills

The skills required are centered on understanding how to implement and use:

· Targeted technical standards.

· Targeted tools and applications

· Targeted services

2.5. eBIS Views

2.5.1. Process View

The following eBIS Framework Process View shows how the eBIS services can support applications in a business process.

Figure 8 Framework-Process View

In this view, business processes make use of common Administration, Distribution, and Life Cycle Management Services offered by an eBIS Infrastructure. In effect, the business processes make use of an eBIS Information Bus to move data from point to point. In our view, the eBIS Architectural Services are distributed and can be utilized on an as needed basis to support the business process. Processes can utilize the eBIS "Bus" to flow the data into and out of Shared Storage and Access Mechanisms and flow the data into whatever sequence of applications support the processes.

Currently, there is limited coordination across traditional stovepipe groups wanting to implement these core services at an enterprise-wide level. The eBIS Business Unit coordination organization will provide this coordination support to traditional stovepipe groups who are desirous of building this eBIS "Bus".

2.5.2. Data-Centric View

The following eBIS Framework view is data-centric.

Figure 9 Framework – Data View

2.5.2.1. Acquire and Administer Services

Systems make use of a set of Core Data Services to support the acquisition and administration of data. SIOs with their associated metadata content are designed, built, and administered through a combination of human or machine activities:

· Locate resources

· Design/model structures

· Make community agreements on model and structures supporting sharing and interchange

· Tweak existing models and structures

· Wire up and connect structures

· Build Content Objects, Metadata Objects, and associated metadata content from structures and available information

Content Objects, Metadata Objects, and associated metadata content to support these activities comes from internal and external sources.

The human Acquisition and Administration service activities are coordinated through and supported by a central service organization However; since the eBIS Architectural Services are distributed and can be subscribed to separately, groups do not have to make use of all of these services.

2.5.2.2. Distribution and Life Cycle Management Services

Current organizations and systems provide a set of services in support of their business processes. These traditional stovepipes make use of a set of Core Data Services to distribute and collect data. These Core Data Services provided are:

· Common Data Collection Services

· Common Data Access Services

· Common User Interaction Services

· Common Data Interchange Services

2.5.3. Use Cases

Boeing is developing Use Cases to illustrate where and how XML might be used within the company. Additional Use Cases will be developed over time.

There are different categories of Use Cases:

Business Sharing and Interchange Scenarios

One to One - When one application or person is sharing or interchanging information with only one other application or person.

One to Many - When one application or person is sharing or interchanging information with two or more applications and/or people.

Many to One - When many are sharing or interchanging information with one application or person.

Many to Many - When many applications or people are sharing information or interchanging information with many other applications or people.

Infrastructure Scenarios

Registry and Authorization - Creating access profiles.

Data Conversion - Translate / Convert out of and into databases

Structure Conversion - Translation Mapping across applications

3. eBIS Architecture Elements

The eBIS architecture elements are:

· Structured Information Objects

o Content Objects

o Metadata Objects

· XML Packaging Mechanism

· Storage and Access Mechanisms

· Requestor Mechanisms

· Registries

Each will be explained in detail below.

Figure 10 eBIS Elements Key Concepts

3.1. Structure Information Objects

Structured Information Objects (SIOs) are composed of some type of content and the associated metadata content. SIOs support the interchange or reuse of Content Objects and Metadata Objects.

3.1.1. Associated Metadata Content

Figure 11 Associated Metadata Content

Many different types of associated metadata content and structures may exist for a Content Object or Metadata Object at any given time in non-shareable databases, applications, and registries. When the metadata content associated with a content object or metadata object is made available for sharing or interchange, it must be in the XML syntax.

The associated metadata content is composed of one or more metadata structures. There is a XML Schema or XML DTD for each type of metadata content structure. The associated metadata content enables the Content Objects (non-XML structured or unstructured) and Metadata Objects (non-XML) to be self-describing. This self-describing quality is what enables use, reuse, and repurposing of the Content Object or Metadata Object in an XML-based eBIS environment.

The metadata associated to a Content Object or Metadata Object can used to populate the registry entries.

The benefit of separating the associated metadata content from the content object or metadata object is that the structures for these objects do not become overburdened with unnecessary structures. This may not be a problem when the information is tightly bound to the receiving system. Once the data needs to suit multiple users and multiple purposes the advantages of carrying the application or process specific metadata separate from the content become obvious. This is the design approach recommended in the eBIS Baseline.

3.1.2. Content - Content Objects and Metadata Objects

The content can be either a Content Object or a Metadata Object.

3.1.2.1. Content Objects

Figure 12 Content Object

A Content Object can be a document, a message, a document fragment, or some unit of information that needs to be shared. Content Objects contain information structured in XML. The Content Objects can be composed of other types of non-XML structured data such as SGML, HTML, X12 EDI, STEP Part 21, etc. Content Objects can be composed of unstructured data.

Figure 13 Content Object composition

Content Objects can be modules or fragments of information, SIOs, which make up a whole unit. Content Objects can be made up of collections of these modules and fragments. The associated metadata content would then contain information to indicate that the content object is made up of a module or fragment or collections of these modules and fragments.

Content Objects can be aggregations -- composed of XML and non-XML Content SIOs and/or Metadata SIOs. Such SIOs could be SVG graphics, XML files, RDF blocks, XSLT scripts, style sheets, CGM graphics, graphs, spreadsheets, etc.

3.1.2.2. Metadata Objects

Figure 14 Metadata Objects

Metadata Objects are specialized forms of content objects. Metadata objects must be some form of structured data either in XML or some non-XML format.

Some examples of Metadata objects are:

· XML DTDs, XML Schemas

· Transformation Scripts (into and out of), Architectural Forms

· Stored procedures to access/query/retrieve XML content against XML registry or registered namespace databases

· Templates, forms, formulas, style sheets

· Pointer to Registries of external namespaces/databases containing XML content

· Search/Semantic Resources - catalogs, dictionaries, indexes, abstracts, vocabularies, glossary, thesauri, ontologies, pointers to other registries --internal and external domain authority/owner, Topic Maps, URLs, etc.

· UML Models, Express Models, SQL Schema Specifications

Figure 15 Structured Information Objects

These metadata objects support the use, creation, transformation of the Content Objects, other Metadata Objects, the associated Metadata content, and XML Packaging Mechanism.

Metadata objects support the modeling or classification of the Content Objects, Metadata Objects, and associated Metadata content.

How much of the metadata is packed into associated metadata content is a design decision that will have to be made. It is dependent on the processing, interchange, repurposing, and/or the storage requirements. It is also dependent on the business requirements. Framework designers for OAG, Arriba, and Commerce One have put the associated content into the DTD structure for the content. The BizTalk Framework design has placed this associated metadata data content into the packaging mechanism.

3.2. XML Package

An XML Package enables the instantiation of a SIO (content object and its associated metadata content) with all the characteristics described in the previous section. The most important of these is enabling all variations of SIOs to look like a single “flavor” of SIO as it flows through the eBIS infrastructure. This consistency would enable a set of core-services to be established to handle the processing of these XML packages.

3.2.1. XML Packaging Mechanism

Currently there is no Packaging Mechanism defined by the W3C. Each IT supplier or Framework Definer (BizTalk, OAG, Commerce One, Rosetta Net, etc.) is employing their own packaging mechanism and strategy to satisfy similar requirements. We will have to deal with these multiple packaging solutions until a common mechanism and strategy is agreed upon.

The following text describes the eBIS requirements in an XML Packaging Mechanism.

Figure 16 Packing Mechanism for Content Objects and Metadata Objects

A Packaging Mechanism must be hardware- or software-independent packaging mechanism therefore the XML syntax must be used. A Packaging Mechanism must be able to support:

· On-Demand Assembly

· Repurposing

· Interchange

· Access and Retrieval

· Creation, Maintenance, Deletion of Content Objects and its associated Metadata

· Creation, Maintenance, Deletion of Metadata Objects and its associated Metadata

· Long-term storage

· Short-term storage

The design of a XML Packaging Mechanism must enable processors to:

· Identify, read, and handle the SIO's content (content object or metadata object) and associated metadata content with or without “bursting “ the XML Package.

· Identify the specific Schemas or DTDs used to create the various metadata units carried as associated metadata content .

· Repopulate registries and databases with the associated metadata.

The XML Packaging Mechanism must be able to contain aggregation of other packages. Large documents could be modularized into smaller units of associated metadata content and content objects. These smaller units, SIOs, could be repurposed into new assemblages of information.

Figure 17 Assembled Data in Packaging Mechanism

An XML Packaging Mechanism must be able to be nested within another XML Packaging Mechanism. The associated metadata would provide a packing list of the items placed in a single package. Therefore, Content Objects that are composed of aggregations (assemblies) of XML and non-XML data content and metadata objects can be encapsulated in an XML Packaging Mechanism.

An XML Packaging Mechanism must be able to contain multiple occurrences of the same data type. The associated metadata would provide a packing list of the items placed in single package. Therefore, aggregations of non-XML data content can be placed into a single Packaging Mechanism. For example, all 4000 CGM graphics for a Maintenance Manual could be encapsulated in one package.

3.2.2. XML Packaging Processor

A processor is any tool or application that is employed to read, use, or create XML packages. A processor must be able to:

· Identify that the content object is part of a set of specific Schemas or DTDs

· Add, modify, or delete the content object based on the specified Schemas or DTDs.

· Identify that the associated metadata content can make use of one or more specific Schemas or DTDs.

· Add, modify, or remove associated metadata content structured to/from a specific Schema or DTD.

· Add, modify, or delete XML Packaging Mechanisms within an XML Packaging Mechanism.

· Add, modify, or delete associated metadata content, packing list, for XML Packaging Mechanisms within the XML Packaging Mechanism.

· Access or process files in a XML Packaging Mechanism as a block or as single files.

· Add, modify, or delete aggregations of the same type in an XML Packaging Mechanism

· Add, modify, or delete associated metadata content, packing list, in an XML Packaging Mechanism.

· Add, modify, or delete associated metadata content belonging to a specific DTD or Schema.

3.3. Requestor Mechanisms

Figure 18 Requestor Mechanisms

The Requestor mechanisms can be applications, software agents, people, role types, or groups. Requestor Mechanisms make requests to Registries and to Storage and Access Mechanisms. Metadata about these Requestor Mechanisms (i.e. authorization level) and its requests (i.e. XML or non-XML) are located in the appropriate registry. A processor is able to handle the request appropriately in combination with the content of the request and associated metadata contained in the Registry.

3.4. Storage and Access Mechanisms

Figure 19 Storage and Access Mechanisms

There are multiple Storage and Access Mechanisms that enable access and use of Content and Metadata Objects in an eBIS environment.

Types of Storage and Access Mechanisms

· Enterprise Specific Repository

· Domain Specific Repositories

· External Group Specific Repository

· Data Marts

· Data Warehouses

· Short- and Long-Term off-line Storage

· Websites.

These storage and access mechanisms are registered. The metadata associated with these Storage and Access Mechanisms (i.e. location and access method) are registered also. The objects contained within these storage mechanisms can also be registered.

3.5. Registries

Registries will point to and will contain information about:

· Registries and their associated metadata

· Requestor mechanisms and their associated metadata

· Access mechanisms and their associated metadata

· Storage mechanisms and their associated metadata

Ø Metadata objects and their associated metadata

Ø Content objects and their associated metadata

· Tools and applications and their associated metadata

Figure 20 Different types of registries

Internal and external registries can be located and accessed by using the associated metadata stored in the Clearing House registries.

Figure 21 Draft Framework Data Model of Clearing House Registries

Figure 22 eBIS Centralized Clearing House Registry

The following are registries that need to be managed and maintained on an enterprise-wide level. These registries provide the centralized point from which tools, applications, requestor mechanisms can locate other registries, repositories, and other tools and applications. This list is not exhaustive.

3.5.1.1. Global Namespace Registry

A Global Namespace Registry contains:

· An index of uniquely named namespaces whether they are internal and external

· The namespace owner

· Any other associated metadata content that would further identify the Namespace origin and authority.

· Pointer to the Namespace Registry

· Pointer to the Namespace Repository

3.5.1.2. <Name> Namespace Registry

A <Name> Namespace Registry registers the models and their elements for a unique namespace.

A <Name> Namespace Registry contains:

· An index of all DTDs and Schemas contained in the <Name> Namespace Repository.

Ø Defines the official names for each DTD and schema within the repository.

Ø Their status or state for use (in work, in test, In production)

Ø Life cycle management information (creation date, owner, sunset date, etc.).

Ø URI to it or the repository where it lives

· An index of all metadata objects necessary for the use and understanding of the DTDs and schemas (e.g. stylesheets, transformation scripts, etc. and examples on how to use schemas).

Ø Defines the official names for each metadata object within the repository utilized by this registry.

Ø Their status or state for use (in work, in test, In production)

Ø Life cycle management information (creation date, owner, sunset date, etc.).

Ø URI to it or the repository where it lives

· Models of the <Name> Namespace (UML, ER, Express)

· Reference materials for semantic understanding of the Namespace

Ø Glossaries, Data Dictionaries, and other information to provide semantic understanding of tags. Each tag name or element must be unique within a namespace.

Ø Rules and examples on use the use of the DTDs and schemas

Ø Boeing variations and restrictions on use of external (industry or public) metadata objects.

Ø Internal rules for use of internal schemas.

· <Name> Namespace Management

Ø Rules on how tags, DTDs, schemas, or other metadata objects are maintained and added to the namespace

Ø Rules on how namespace DTD, schema, or tag conflict resolution will be handled

Ø Rules on delegation of responsibility to assign something to the namespace

3.5.1.3. DTD and Schema Registry

The DTD and Schema Registry registers all the XML DTDs and XML Schemas:

· Authorized for use within the Boeing Company. Note: Not all DTDs/Schemas in a Namespace may be active or authorized for general use at any given time.

· Associated metadata content that may help in search and retrieval.

· Their status or state for use (in work, in test, In production)

· Life cycle management information (creation date, owner, sunset date, etc.).

· Namespace it belongs to

· URI where it lives

3.5.1.4. Where Used Registry

The Where Used Registry contains a registry which indicates where a DTD, schema, or namespace is being used in repositories. It can contain mappings of which documents point to or make reference to particular DTDs, schemas, or namespaces. Examples of other where used mappings are:

· Namespace by DTD,

· Information object by information object

· Metatag by DTD

· DTD by document

3.5.1.5. Equivalence Registry

The Equivalence Registry contains equivalent structures and names. It contains:

· Equivalence mappings from one model to XML e.g. EXPRESS to XML.

· Equivalence mappings within a namespace

· Equivalence mappings across namespaces

3.5.1.6. Transformation and Mapping Rules Registry

The Transformation and Mapping Rules Registry contains strongly typed transformation scripts and mapping rules. Scripts could have data dictionary type explanations to support correct understanding and use. For example the registry could contain:

· Transformation scripts from one tagged structure to another,

· Rules to transform date to date,

· Scripts or rules to transform employee record in native format to XML,

· Scripts or rules to transform PO for Westinghouse to PO for GE.

3.5.1.7. Topic Map Registry

The Topic Map Registry contains style sheets for knowledge, which are views or navigation paths through data particular to a group, use, or topic. One or more topic maps may be created to remap or restyle the information or knowledge presented in a repository or across a set of documents. The registry contains all the topic maps:

· Authorized for use within the Boeing company

· Associated metadata content that may help in search and retrieval.

· Their status or state for use (in work, in test, in production)

· Life cycle management information (creation date, owner, sunset date, etc.).

· Owner

· URI where it lives

3.5.2. Other Internal or External Registries

The following are registries that need to be managed and maintained on a group, domain, or project level. This list is not exhaustive.

3.5.2.1. Instance Repository Registry

The Instance Repository Registry contains an:

· Index of documents in repository. There is no restriction on the number of schemas and/or referenced namespaces the repository or its documents can reference.

· Associated metadata content for the Instance Repository which provides the:

Ø Location

Ø Access methods

Ø Authorization levels required to access

Ø Official name

Ø Owner for the Instance Repository

3.5.2.2. Access and Roles Registry

The Access and Roles Registry contains:

· Index of Requestor Mechanisms

Ø roles

Ø role types,

Ø software agents,

Ø people,

Ø groups

· Authorization levels for each Requester Mechanism assigned per types or classes of metadata objects, content objects, associated metadata, registries, tools, application, or repositories.

3.5.2.3. Profile Registry

The Profile Registry contains a registry of information that forms a profile of customer, supplier, people, applications, agents, requirements that support the interchange of information (e.g. information on address, contacts, delivery requirements, handshaking).

3.5.2.4. Tools and Applications Registry

The Tools and Applications Registry contains a registry of tools and applications and their associated metadata.

3.5.2.5. Requestor Mechanism Registry

The Requestor Mechanism Registry contains a registry of requestor mechanisms and their associated metadata. Contains the structures for these requestors and authorization levels.

3.5.2.6. Storage Mechanism Registry

The Storage Mechanism Registry contains a registry of storage and access mechanisms and their associated metadata.