| Term | Definition | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Abstract Types | Allow use of complex types in such a way that a single element name can be used to represent various types in an XML document instance. | ||||||||||||
| ACID | A set of software tests (atomicity, consistency, isolation and durability) that are used to ensure hardware and software stability. For example, in transaction processing, a transaction has atomicity if the operations that make up the transaction either all execute to completion, or can be made to appear never to have occurred at all. A transaction has consistency when it successfully transforms the system and the database from one valid state to another. A transaction has isolation if it is processed concurrently with other transactions and still behaves as if it were the only transaction executing in the system. (It does not interfere with other transactions and others do not interfere with it.) A transaction has durability if all the changes that it makes to the database become permanent when the transaction is committed. | ||||||||||||
| Action Message | A properly packaged business action message. See also RosettaNet Business Message. | ||||||||||||
| Actions Specifications | Describe the format of information that is exchanged between partners in the supply chain. | ||||||||||||
| Activity | The work performed in a Business Process. | ||||||||||||
| Administrative PIP | New process to inform members of updates on projects such as the Dictionaries. Admin PIPs are from RosettaNet to Partners; they are not distributed from Partner to Partner. | ||||||||||||
| Annotation | Information for human and/or mechanical consumers. The interpretation of such information is not defined in the XML Schema specifications. The annotation element can contain one or more or elements. | ||||||||||||
| Architecture | The way components of a complex system fit together. | ||||||||||||
| AS2 | Applicability Statement 2 | ||||||||||||
| As-is Business Process Model | A graphical model of an organizational business process showing the activities, external processes and decisions along with the information exchanged between them. An employee fulfilling a role performs each activity. External processes are performed by external entities. | ||||||||||||
| Attribute (UML) | A simple, discreet piece of information that is part of a class. | ||||||||||||
| Attribute (XML) | A name="value" field within an XML element, providing information associated with that XML element. | ||||||||||||
| Attribute Group | A set of attribute declarations, enabling re-use of the same set in several complex type definitions. | ||||||||||||
| Attribute Group Definition | An attribute group definition is an association between a name and a set of attribute declarations, enabling re-use of the same set in several complex type definitions. | ||||||||||||
| BOM | Bill of Material. A BOM is a parts list with specifications. It is a reference that displays part name, code, specification and cost. This information is used for system designs, purchasing and inventory control. A typical BOM contains the following: Part Code Quantity Description Dimensions Type Cost Total Cost | ||||||||||||
| BOV | Business Operational View (concept from ISO 14662 Open-EDI Reference Model). The first section of every PIP specification, the BOV describes the business-related aspects of the PIP. This is information captured from business analysts during development of the PIP. The BOV is the PIP Blueprint as approved by the RosettaNet members. | ||||||||||||
| BPSS | Business Process Specification Schema | ||||||||||||
| BTO | Build to Order. | ||||||||||||
| Built-in Data types | Data types that are defined either in the XML Schema specification (as primitive types) or in this specification, and can be either primitive or derived. | ||||||||||||
| Business Action | A message with content of a business nature such as a Purchase Order Request or a Request For Quote. The exchange of business actions and business signals comprise the message choreography necessary to complete a business activity specified by a given PIP. | ||||||||||||
| Business Activity | A PIP encapsulates one or more discrete business activities as specified by the business analysts during development of the PIP blueprint. For example, PIP 3A4 (Manage Purchase Order) specifies three (3) separate business activities: Create Purchase Order, Change Purchase Order, and Cancel Purchase Order. The exchange of business actions and business signals comprise the message choreography necessary to complete a business activity specified by a given PIP. | ||||||||||||
| Business Data Entity (BDE) | Used to define a Business Document; represent structured business information and are made up of other BDEs and Fundamental BDEs, i.e., a Physical Address made up of address lines and a postal code. | ||||||||||||
| Business Data Property | The type of business data entity association. | ||||||||||||
| Business Dictionary | The document that contains definitions for the Business Properties. | ||||||||||||
| Business Document | Container for structured business information that is made up of Business Data Entities, Fundamental Business Data Entities and Business Properties. A Business Document defines the information transferred from Activity to Activity. Business Documents are developed by partners using RosettaNet Message Guidelines. | ||||||||||||
| Business Message | See RosettaNet Business Message. | ||||||||||||
| Business Process | A set of Activities that represent all the alternative methods of performing the work needed to achieve a business objective. | ||||||||||||
| Business Process Specification Schema (BPSS) | The ebXML BPSS specification is used to describe PIP Choreography. PIPs will be generated using the "Binary Collaboration" element in BPSS v1.01 with modifications. | ||||||||||||
| Business Property | Association between BDEs; generally do not have Role Names. | ||||||||||||
| Business Signal | A message exchanged between two RosettaNet network applications to communicate certain events within the execution of a PIP instance. Examples of signals include receipt and successful validation of a message (Receipt Acknowledgement) and receipt of a message out of sequence (General Exception). A signal is used to communicate an exception condition within the normal message choreography of a PIP. See also Process Control PIP. | ||||||||||||
| Cardinality | Cardinality specifies how many instances of one class may be associated with a single instance of another class. Cardinality can be indicated for both classes and relationships. Application of a cardinality adornment to a class indicates the number of instances allowed for that class. Application of a cardinality adornment to a relationship indicates the number of links allowed between one instance of a class and the instances of another class. Valid Values The following cardinality values apply to both classes and relationships. Values are presented in lower-bound..upper bound format. Literals stand for any number and must be typed in using the appropriate specification.
| ||||||||||||
| Class Diagram | A grouping of related information. | ||||||||||||
| Cluster | A Cluster is a group of high-level business processes. The Clusters that are addressed by the RosettaNet Initiative represent the core business processes or the backbone of a supply chain. The Clusters listed below were identified through interviews with RosettaNet Board Member companies, and through the RosettaNet Business Research Teams knowledge of common and emerging business practices. This provides only a guideline for RosettaNet's focus and may be changed by the Cluster Workshop Teams. Cluster 1: Partner and Product/Service Review Cluster 2: Product Introduction Cluster 3: Order Management Cluster 4: Inventory Management Cluster 5: Marketing Information Management Cluster 6: Service and Support Cluster 7: Manufacturing | ||||||||||||
| Complex Type | An XML element type that allows nested elements in their content and may carry attributes. | ||||||||||||
| Complex Type Definition | A complex type definition is a set of attribute declarations and a content type, applicable to the attributes and children of an element information item respectively. The content type may require the children to contain neither element nor character information items (that is, to be empty), to be a string that belongs to a particular simple type or to contain a sequence of element information items that conforms to a particular model group, with or without character information items as well. | ||||||||||||
| Complex type extension | Extension adds attributes, and adds elements to the end of the content model of the base type. | ||||||||||||
| Complex type restriction | Restriction limits a base type to a more restrictive set of valid values. | ||||||||||||
| Compliance | An implementation that meets all requirements of the RNIF specification. All transactions, actions, or data elements must be valid as defined in the term, "Validation"Â | ||||||||||||
| Compliance Testing | Comparing an implementation operation against specified requirements to determine compliance or noncompliance. | ||||||||||||
| Component | Component means a basic building block of the Schema like named type, named element, named group, etc. | ||||||||||||
| Conformance | The ability to demonstrate in an unambiguous way that a given implementation is correct with respect to the formal model. | ||||||||||||
| Constraint | The conditional constraints that specify the mandatory composition of the business document in certain contexts. | ||||||||||||
| Control Information | Information that is appended to content from an upper network layer. | ||||||||||||
| Data Element | A basic unit of identifiable and definable data; a basic unit of data for the purpose of recording and interchange. Within the EDI format, related data elements are grouped into segments. | ||||||||||||
| Data Type (UML) | The format of information allowed for an attribute. | ||||||||||||
| Data Type (XML) | A data type is a 3-tuple, consisting of a) a set of distinct values, called its value space, b) a set of lexical representations, called its lexical space, and c) a set of facets that characterize properties of the value space, individual values or lexical items. | ||||||||||||
| Decision | The question that is asked to determine the exact set of activities during the execution of a Process. For example, a question might be What type of order? Or How will the order be shipped? A Decision is represented by a Decision Object (shaped in the form of a diamond) in an Activity Decision Flow Diagram. | ||||||||||||
| Derived Data Types | Derived data types are those that are defined in terms of other data types. A data type is said to be derived by restriction from another data type when values for zero or more constraining facets are specified that serve to constrain its value space and/or its lexical space to a subset of those of its base type. Every data type that is derived by restriction is defined in terms of an existing data type, referred to as its base type. Base types can be either primitive or derived. | ||||||||||||
| Design Pattern | A design pattern describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. | ||||||||||||
| Domain | A business area with specialized vocabulary and business practices. There may be many domains, or areas of expertise, represented in a single PIP and a single domain may span multiple PIPs. | ||||||||||||
| Domain Analysis | Domain analysis is "the process of identifying, collecting, organizing, and representing the relevant information in a domain, based upon the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within a domain" | ||||||||||||
| Domain Model | Domain model describes objects, the data and mutual relationships among them that are required to represent a set of requirements of one or more PIPs. Represented in UML and XML in different stages of PIP production. | ||||||||||||
| Domain Modeling | The process of creating a domain model. See http://www.sei.cmu.edu/domain-engineering/domain_model.html | ||||||||||||
| DTD | Document Type Definition. PIPs are implemented using XML that is validated against the appropriate Document Type Definitions. | ||||||||||||
| D-U-N-S® Number | Data Universal Numbering System. A sequentially generated nine-digit number that is assigned and maintained only by Dun and Bradstreet, which identifies unique business locations, and is global in scope. | ||||||||||||
| eBusiness | An enterprise that conducts many of its business functions through electronic means. The term also refers to businesses that operate on the Internet and offer goods, services, and information for sale via the Web. | ||||||||||||
| EC Technical Dictionary | Electronic Components Technical Dictionary. Currently in development; will include technical specification properties of EC products and accessories. | ||||||||||||
| EDI | Electronic Data Interchange. Automatic transfer of documents between computers in a "machine language", typically between different organizations. Documents may include invoices and orders. | ||||||||||||
| Element | A fundamental unit of XML information, which has an element name, optional attributes, optional data value, and an associated type definition. Elements may be nested, one inside another. | ||||||||||||
| Element Declaration | An element declaration is an association of a name with a type definition, either simple or complex, an (optional) default value and a (possibly empty) set of identity-constraint definitions. | ||||||||||||
| Enumerated Type | A special case of data type that is constrained to specific values. | ||||||||||||
| EPC | Electronic Product Code | ||||||||||||
| Extension | Added functionality or features that do not violate the integrity of the original framework. | ||||||||||||
| External Standards | An industry standard leveraged by RosettaNet, such as International Standards Organization (ISO), which maintains its own code lists, methods and practices that provide a common ground of knowledge. | ||||||||||||
| Facet | A facet is a single defining aspect of a value space. Generally speaking, each facet characterizes a value space along independent axes or dimensions. | ||||||||||||
| Fixed attribute values | An attribute value that always has the same value. | ||||||||||||
| Framework | A set of related architectural components. | ||||||||||||
| FTP | File Transfer Protocol | ||||||||||||
| Fundamental Business Data Entity (FBDE) | A BDE that cannot be separated into components, such as a Postal Code or free-form text. | ||||||||||||
| GLN | Global Location Number | ||||||||||||
| Globally defined attributes | Attribute definitions that are defined at the highest level in the XML Schema document, so that the definitions can be reused. | ||||||||||||
| Globally defined elements | Element definitions that are defined at the highest level in the XML Schema document, so that the definitions can be reused. | ||||||||||||
| Groups | XML Schema allows fragments of content models to be named and referenced from multiple complex types. | ||||||||||||
| GTIN | Global Trade Item Number. The part-numbering schema that identifies any item upon which there is a need to retrieve pre-defined information and may be priced, ordered or invoiced at any point in the supply chain. | ||||||||||||
| Guideline | A set or collection of specifications, sometimes including specific implementation advice. (See EDI Guideline.) | ||||||||||||
| Header | Control information appended to content from an upper network layer. | ||||||||||||
| HTML | Hypertext Markup Language | ||||||||||||
| HTTP | Hypertext Transfer Protocol | ||||||||||||
| Implementation Framework | Guidelines for creating instances of related architectural components. (See RNIF.) | ||||||||||||
| Interchange Format | A specific data layout that defines a structured business document. The interchange format specifies the sequence, representation and grouping of granular data elements, and may describe each element in terms of data type, options, cardinality, size and valid values. | ||||||||||||
| Interchange Model | The PIP Service Content structure described using either UML or XML Schema Same as PIP Interchange Model. | ||||||||||||
| Internet | A matrix of networks that connects computers around the world. | ||||||||||||
| IT Technical Dictionary | Information Technology Technical Dictionary; includes technical specification properties of IT products and accessories. | ||||||||||||
| Loop | A collection of segments that repeat together. | ||||||||||||
| Lower Layer | A lower layer down in the OSI network communications reference model. | ||||||||||||
| Main type | A reusable type that is used to define the root element of the XML instance document (PIP Action Message). In case when Schema contains only one reusable type definition than that type is by default the Schema main type. | ||||||||||||
| MAY | This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation, which does not include a particular option, MUST be prepared to interoperate with another implementation, which does include the option, though perhaps with reduced functionality. In the same vein an implementation, which does include a particular option, MUST be prepared to interoperate with another implementation, which does not include the option (except, of course, for the feature the option provides). | ||||||||||||
| MCC | Message Control and Choreography | ||||||||||||
| Message Guidelines | Human readable structure definitions of the business messages for discussion and design. Message Guidelines include fields and codes for PIPing companies to build Business Documents, which outline cardinality of Business Properties and Business Data Entities (BDEs), and provide Code Lists and definitions of Business Properties, BDEs, Fundamental BDEs, and Quantitative Fundamental BDEs. | ||||||||||||
| Message Schemas | Machine readable structure definitions of the business messages for validation, mapping and PIP operations. In addition to the .DTD syntax, more will be available that include XML Schema and Microsoft Word. | ||||||||||||
| Mixed Content | A combination of child elements and character data nested within an element. | ||||||||||||
| MMS | Multi Message Servicing | ||||||||||||
| MNC | Multi National Company | ||||||||||||
| Modular PIP | Describes the PIP Service Content using W3C XML Schema, and PIP Choreography described using ebXML BPSS. | ||||||||||||
| Monolithic PIP | Describes the PIP Service Content using message guidelines and DTD. | ||||||||||||
| MUST | This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification. | ||||||||||||
| MUST NOT | This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification. | ||||||||||||
| Name | The full name of an information element. | ||||||||||||
| Name | Represents names in XML. A Name is a token that begins with a letter, underscore, or colon and continues with name characters (letters, digits, and other characters). This data type is derived from token. | ||||||||||||
| Named Types | Named types may be defined once and used many times. | ||||||||||||
| Namespaces | An XML namespace is a collection of names identified by a URI reference, which are used in XML documents as element types and attribute names. | ||||||||||||
| NCName | Represents non-colonized names. This data type is the same as Name, except it cannot begin with a colon. This data type is derived from Name. | ||||||||||||
| Network Layer | OSI communications reference model comprises layers, each specifying particular network functions. Many protocols can implement the functions defined for a layer. | ||||||||||||
| Networked Applications | RosettaNet-compliant software functions. | ||||||||||||
| NIST | National Institute of Standards and Technology | ||||||||||||
| Non-Normative | An adjective to denote part/aspects of the specification that provide descriptive and human-readable representation of the Modular PIP specifications. Should a discrepancy occur between normative and non-normative documentations, please refer to the normative documentation. | ||||||||||||
| Non-Repudiation of Origin and Content | Prevents the originator from denying the origin and content of a message. Origin: protects against any attempt by a message originator to deny sending a message; irrevocable proof that the originator sent the message. Content: protects against any attempt by a message originator to deny the actual content of the sent message; irrevocable proof of what exact content was sent and that it did not get modified in any way from the original. | ||||||||||||
| Non-Repudiation of Receipt | Prevents the responder from denying the fact that they received what has been sent by the originator. Protects against any attempt by a message recipient to deny receiving a message. | ||||||||||||
| normalizedString | Represents white space normalized strings. This data type is derived from string. | ||||||||||||
| Normative | An adjective to denote parts/aspects of the specification that defines implementation compliance. For example, only XML Schema and XML are normative forms of representation of Modular PIP specifications. | ||||||||||||
| OBI Object | The standard data structure used to exchange order-related data between OBI-compliant trading partners. The OBI object contains an encapsulated version of OBI data and it may include a digital signature. The OBI data field within an OBI object contains an order or order request that has been formatted based on the EDI-based OBI order format specification. | ||||||||||||
| OBI® | Open Buying on the Internet. | ||||||||||||
| Occur | A single segment that can repeat a given number of times is said to occur. For example, DTM Occurs = 100 means that the Date/Time Reference segment can repeat 100 times in sequence. | ||||||||||||
| Organization | A group organized for some specific purpose or function. An organization can be an enterprise, a company, or a factory, to name just a few examples. | ||||||||||||
| Partner Interface Process (PIP) | The RosettaNet model that depicts the activities, decisions and Partner Role interactions that fulfill an eBusiness transaction between two partners in a supply chain. Each Partner must fulfill all obligations specified in a PIP. If any one party fails to perform a service as specified in the approved RosettaNet PIP documentation then the business transaction is null and void. A sub-process, a subset of a sub-process, or combination of sub-processes identified by Cluster or Segment Workshop participants as containing key interactions between Partner Types. A PIP contains interactions that, if standardized, would improve supply chain efficiencies. There can be sub-processes that will are not identified to become PIPs because they do not meet the PIP criteria listed below. A PIP must: have a measurable business outcome or output; not contain proprietary business processes; contain more than one role interaction; and Be a discrete unit of work that can be attached like building blocks to other PIPs to achieve a larger business outcome. | ||||||||||||
| Partner Role Interaction | The one-way exchange of business properties between partner roles. Partner Role Interactions are executed by networked service and agent applications that interact by transmitting and receiving messages. These services interact via service transactions and the agents with services. Both interact by transmitting and receiving messages. | ||||||||||||
| Partner Roles | The activities performed at the organizational, departmental or individual employee level. The activities may include Catalog Publisher, Catalog Distributor, Order Manager, Requisition Manager and the structured properties they exchange when they interact. | ||||||||||||
| Partner Type | Partner Type describes the high-level business functions that a trading partner performs in the supply chain. | ||||||||||||
| Performative | A verb that specifies some action to be performed; a basic Knowledge Query and Manipulation Language (KQML) command; a construct of speech act theory. A speech act can be put in a stylized form that begins hereby request or hereby declare. In this form the verb is called the performative, since saying it makes it so. Verbs that cannot be put into this form are not speech acts, for example hereby solve this equation does not actually solve the equation. | ||||||||||||
| PIP Blueprint | Created as a result of developing a (to-be) business model that specifies how Partner Roles (Buyer, Seller, Assembler, Catalog Publisher, etc.) interactively perform interface activities that collaboratively achieve a business objective. The PIP Blueprint document includes narrative and diagrams. | ||||||||||||
| PIP Choreography | The exchange sequence of PIP messages specified using BPSS. | ||||||||||||
| PIP Design and Development Process | A structured process that describes the work and steps required to create a PIP specification based upon requirements as detailed in the Specification Requirement Document (SRD). | ||||||||||||
| PIP Implementation Guideline | Collates the results of the RosettaNet development methodology into a document for eBusiness architects, implementers and solution providers to create RosettaNet-compliant implementations of interoperable software solutions. | ||||||||||||
| PIP Interchange Model | The structure of the exchanged information between trading partners in a specific context. | ||||||||||||
| PIP Protocols | Technical interface diagrams that visually describe and define the PIP Blueprint. | ||||||||||||
| PIP Specification | Partner Interface Process detailed formulation, in document form, which provides a definitive description of a system for the purpose of developing or validating the system. | ||||||||||||
| PIP UML Interchange Model | Interchange Model represented in UML | ||||||||||||
| Process Specifications | Describe the conditional choreography of exchange sequences necessary to execute PIPs. | ||||||||||||
| Protocol | Formal set of rules and conventions that govern how computers exchange information over a network medium. | ||||||||||||
| Quantitative Fundamental Business Data Entities | QFBDEs should have: a) unit of measure (such as "inches"); b) dimension (such as length); c) system of units (such as USA or the International System of Units [SI]). A QFBDE is a physical quantity that comprises both an amount and a physical unit of measure from a system of units. For example, the QFBDE "Length" can be specified in "meter" using the SI Units of Measure. | ||||||||||||
| RAE | RosettaNet Automated Enablement | ||||||||||||
| RDA | RosettaNet Dictionary Architecture | ||||||||||||
| RFID | Radio Frequency Identification | ||||||||||||
| RNBD | RosettaNet Business Dictionary | ||||||||||||
| RNIF | RosettaNet Implementation Framework. The RNIF provides implementation guidelines for those who wish to create interoperable software application components that execute PIPs. | ||||||||||||
| RNTD | RosettaNet Technical Dictionary | ||||||||||||
| Role Name | A categorical title of a Partner in a PIP; may also be referred to as a Partner Role. | ||||||||||||
| Role Type | The type of role that performs activities in an e-Business process, Employee, Organizational or Functional. | ||||||||||||
| RosettaNet Object | RosettaNet version of the OBI Object, which accommodates upper-level protocols, as opposed to only EDI-formatted messages. | ||||||||||||
| RSM | RosettaNet Standards Methodology | ||||||||||||
| Scenario | A business scenario describes a specific instance of a specific process within the business process. Scenarios are specific instances of use cases. | ||||||||||||
| Schema | Refers to XML Schema document compliant with W3C XML Schema Recommendations. | ||||||||||||
| Schema Component | Refers to the building blocks of the Schema like elements, types, content models, model groups, annotation etc. | ||||||||||||
| Segment | A group of logically related data elements in a defined sequence. Within the EDI format, segments are grouped into a transaction set. Each RosettaNet Cluster is comprised of several Segments that are cross-enterprise processes involving more than one Partner Type in the supply chain (rather than internal company processes). | ||||||||||||
| SHOULD | This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. | ||||||||||||
| SHOULD NOT | This phrase, or the phrase "NOT RECOMMENDED", means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. | ||||||||||||
| SI | International System of Units | ||||||||||||
| Simple Structure (Type) | A special case of data type that is constrained to a specific representation of the value. | ||||||||||||
| Simple Type | Simple types cannot have element content and cannot carry attributes. | ||||||||||||
| Simple Type Definition | A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the normalized value of an attribute information item or of an element information item with no element children. Informally, it applies to the values of attributes and the text-only content of elements. | ||||||||||||
| SKU | Stock Keeping Unit | ||||||||||||
| SME | Small and Medium Enterprise | ||||||||||||
| SMTP | Simple Mail Transfer Protocol | ||||||||||||
| Source Business Data Entity | The source of the business data entity compositional association. | ||||||||||||
| Specification | A detailed formulation, in document form, which provides a definitive description of a system for the purpose of developing or validating the system. | ||||||||||||
| Specification Requirements Document (SRD) | A deliverable from a Milestone Program that contains the requirements for a PIP(s). | ||||||||||||
| Standard | A set of clearly defined and agreed-upon conventions for specific programming interfaces. | ||||||||||||
| Standard Document Header | Adopted from UNCEFACT. | ||||||||||||
| Structure | Something composed of organized or interrelated elements; the manner in which the elements of something are organized or interrelated. | ||||||||||||
| Substantive Response | Includes data from the initiating message as well as data included by the responding partner (e.g., disposition of a product such as quantity and ship date that a supplier can fulfill on a Purchase Order). | ||||||||||||
| Substitution groups | An element can be declared to be a substitute for another element, the "head" element, allowing the new element to appear anywhere the head element may appear. | ||||||||||||
| Syntax | The patterns of formation of sentences and phrases from words and the rules for the formation of grammatical sentences in a language. | ||||||||||||
| System Structure | The Standard Document Header and any other components of a PIP message that are used for integration with RNIF and/or other middleware. | ||||||||||||
| targetnamespace | The namespace of an instance document. | ||||||||||||
| TCP/IP | Transfer Control Protocol/Internet Protocol | ||||||||||||
| Technical Advisory | A Technical Advisory (TA) provides clarification for differing interpretations of a feature not explicitly addressed in the current specification and/or introduces a new feature. Rules: 1) The clarification or feature introduction is an amendment to the specification. 2) The clarification is required to resolve an implementation issue. 3) The new feature is required. 4) The clarification or feature requires implementation according to the specification (e.g. coding change). | ||||||||||||
| Technical Advisory | A Technical Advisory (TA) provides clarification for differing interpretations of a feature not explicitly addressed in the current specification and/or introduces a new feature. Rules: 1) The clarification or feature introduction is an amendment to the specification. 2) The clarification is required to resolve an implementation issue. 3) The new feature is required. 4) The clarification or feature requires implementation according to the specification (e.g. coding change). | ||||||||||||
| Technical Recommendation | A Technical Recommendation describes features or enhancements not yet available in a published version of the subject specification. Rules: 1) The implementation of a Technical Recommendation is optional. 2) The feature or enhancement described by a Technical Recommendation may be, but is not guaranteed to be, included in a future release of the subject specification. 3) If the feature or enhancement is utilized, the implementation must be according to the specification (e.g. coding change). | ||||||||||||
| Technical Recommendation | A Technical Recommendation describes features or enhancements not yet available in a published version of the subject specification. Rules: 1) The implementation of a Technical Recommendation is optional. 2) The feature or enhancement described by a Technical Recommendation may be, but is not guaranteed to be, included in a future release of the subject specification. 3) If the feature or enhancement is utilized, the implementation must be according to the specification (e.g. coding change). | ||||||||||||
| To-be Business Process Model | A graphical model of an organizations business process, functioning as a partner type in a supply chain, showing the activities, external partner processes and decisions along with the properties exchanged between them. An employee fulfilling a role performs each activity. External processes are performed by supply chain Partner Types. Property exchange between supply chain Partners is depicted as a Role Interaction. | ||||||||||||
| token | Represents tokenized strings. This data type is derived from normalizedString. | ||||||||||||
| TPIR | Trading Partner Implementation Requirements | ||||||||||||
| TPIR-PIP | Trading Partner Implementation Requirements – Partner Interface Process | ||||||||||||
| TPIR-PF | Trading Partner Implementation Requirements – Presentation Format | ||||||||||||
| Trailer | Control information that is appended to content from an upper network layer. | ||||||||||||
| Transaction | A collection of actions that have ACID properties. | ||||||||||||
| Transaction Set | A collection of formatted data that contain the information required by a receiver to perform a standard business transaction. In an EDI standard, a transaction set is defined as having three sections (header, detail and summary) and includes a predefined group of segments in each section. | ||||||||||||
| Transaction Specifications | Describe the sequence of information exchanged and the boundaries of these exchange sequences that comprise a single unit of work. | ||||||||||||
| Type Derivation | XML Schema allows a type to be derived from another type (its base type), either by extension or restriction. | ||||||||||||
| Type Redefinition | XML Schema allows a Schema author to redefine the types or groups of another Schema document. | ||||||||||||
| Type Substitution | Allows a base type to be substituted by any derived type. | ||||||||||||
| UN/SPSC | United Nations/Standard Product and Services Code | ||||||||||||
| Unified Modeling Language (UML) | A graphical language for visualization, construction and documentation of artifacts. The preferred modeling language for use in RosettaNet methodologies. | ||||||||||||
| Union types | The union operation is supported by XML Schema for element types. For example, a codelist may be defined as the union of two other codelists. | ||||||||||||
| Universal Structure | Most commonly used business information structures across all PIPs. | ||||||||||||
| Unpacking | Extracting the individual RosettaNet Business Message components from the MIME and/or S/MIME entities and simultaneously performing validation steps where applicable. | ||||||||||||
| Upper Layer | A layer higher up in the OSI network communications reference model. | ||||||||||||
| Valid XML document | An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it. (From World Wide Web Consortium, Extensible Markup Language (XML) 1.0: W3C Recommendation 10-February-1998.) | ||||||||||||
| Validation | A data element, action, transaction, or process is valid if and only if it meets all requirements of the RNIF specification. Validation is the act of comparing such an entity against the specified requirements to determine validity or invalidity. Note that each action within a transaction must meet the content and sequence requirements for that transaction. Similarly, each transaction within a process must meet the content and sequence requirements of that process. Such validation is an essential part of testing an implementation. It is also anticipated that the validation team will develop specific requirements for such validation during production use of an implementation. | ||||||||||||
| Value Space | A value space is the set of values for a given data type. Each value in the value space of a data type is denoted by one or more literals in its lexical space. | ||||||||||||
| Vocabulary | The collection of words known to a particular person or group and used for a particular purpose. | ||||||||||||
| WS-I | |||||||||||||
| WSDL | |||||||||||||
| WWW | World Wide Web. An information server on the Internet composed of interconnected sites and files, accessible with a browser. | ||||||||||||
| XML | Extensible Markup Language. HTML is concerned with display of content; XML is a language that is concerned with creating, sharing and processing information. | ||||||||||||
| XML document | A data object made up of virtual storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form the character data in the document, and some of which form markup. Markup encodes a description of the documents storage layout and logical structure. | ||||||||||||
| XML Schema | An XML document that defines the allowable content of a class of XML documents. A class of documents refers to all possible permutations of structure in documents that will still confirm to the rules of the Schema. | ||||||||||||
| XSD | Refers to XML Schema Definition language | ||||||||||||
| xsi | Refers to XML Schema instance namespace. This is a separate namespace for four schema-related attributes that may appear in instances. These attributes, whose names are commonly prefixed with xsi, are: type, nil, schemaLocation, and noNamespaceSchemaLocation. |