[Accessibility conventions are described at the bottom of the page]

12. Introduction to document engineering
[> 13.][< 11.1.2][^^^]
12.0 Introduction to document engineering
[> 12.1][> 13.][< 12.][^^][^^^]
Document Engineering (the book)
[[1] - ISBN 0-262-07261-0 - Robert J. Glushko, Tim McGrath
 [1] - formal and rigorous document modeling techniques
 [1] - models, patterns and re-use
 [1] - interoperability or lack thereof
]
The role of documents in business transactions
[[1] - distinguishing models and documents
 [1] - designing business patterns
 [1] - implementing models and documents in applications
]
Techniques for deriving the model and structure of documents
[[1] - analyzing documents
 [1] - assembling document models
]
12.1 Functional dependency
[> 12.2][< 12.0][^^][^^^]
12.1.1 Functional dependency
[> 12.1.2][> 12.2][> 13.][< 12.0][^^][^^^]
Functional dependency is an important principle
[[1] - set of data analysis techniques called "normalization"
 [1] - used by database designers to create relational models
 [1] - adapted by McGrath and Glushko to create document models
]
Normalization captures data semantics
[[1] - from an analysis of information requirements
 [1] - minimizes redundancy and duplication
 [1] - re-uses identified common patterns of information
]
12.1.2 Essentiality
[> 12.1.3][> 12.2][> 13.][< 12.1.1][^][^^][^^^]
Essentiality reduces waste and distraction
[[1] - determining about the essential nature of components
 [1] - avoids modeling derivative components
[[2] - identifies where the semantics are similar enough to adapt already-modeled constructs rather than creating a similar-but-not-quite-the-same construct
]]
12.1.3 Structural patterns
[> 12.1.4][> 12.2][> 13.][< 12.1.2][^][^^][^^^]
Promoting interoperability
[[1] - rearranging the order of information items so that two aggregates can be implemented with the same constructs
 [1] - possibility to distill those same constructs into a common child aggregate
]
Identifying patterns by removing qualifications
[[1] - are some qualifications absolutely necessary for interchange?
]
Encouraging standardization
[[1] - can promote faster and more robust application development by sharing code that works on many business objects
]
12.1.4 Checks and balances
[> 12.2][> 13.][< 12.1.3][^][^^][^^^]
Ensuring no similarly qualified components within the same structure
[[1] - reduces duplication
]
Are items sharing conceptual context, thus inferring more structural context
[[1] - e.g. country code and country name in address
[[2] - suggests a country context with code and name members
]]
12.2 Creating new elements
[> 13.][< 12.1.4][^^][^^^]
12.2.1 Creating new elements
[> 12.2.2][> 13.][< 12.1.4][^^][^^^]
Considering re-use vs. renaming vs. specialization
[[1] - rather than creating new elements with parallel definitions, basing a new element on an existing element will promote better code re-use
 [1] - promotes normalization of information
]
For example, consider the base definition of a party:
[[1] - information regarding an organization or individual
 [1] - Party. Details defined as an ABIE
]
When referring to the "owner party", there is no additional information
[[1] - Transport Means. Owner_ Party. Party defined as an ASBIE
 [1] - simply points to Party. Details
 [1] - qualified by its context of use and the party the structure represents
]
When referring to the "customer party", there is additional information
[[1] - Customer Party. Details needs to be its own ABIE
 [1] - within the ABIE is an ASBIE directly to Party
 [1] - other BBIE and ASBIE information
[[2] - e.g. delivery contact, accounting contact, buyer contact, identifiers, etc.
]]
When referring to the "buyer customer party", there is no additional information
[[1] - Despatch Advice. Buyer_ Customer Party. Customer Party defined as an ASBIE
 [1] - qualified by its context of use and the customer party the structure represents
]
The ASBIE is named the ABIE if the ABIE is conceptually and unambiguously referring to the object class
[[1] - e.g. Statement Line. Details has the ASBIE Statement Line. Exchange Rate pointing to Exchange Rate. Details
[[2] - there is only one exchange rate to refer to (statement line currency and related document currency)
]]
The ASBIE is qualified when there are variations of use of the same ABIE
[[1] - e.g. invoice has many exchange rates "Invoice. Pricing_ Exchange Rate. Exchange Rate" and "Invoice. Payment_ Exchange Rate. ExchangeRate" and "Invoice. Tax_ Exchange Rate. Exchange Rate"
]
The ASBIE is qualified when the relationship is not obvious
[[1] - e.g. Transport Means. Owner_ Party. Party qualifies party with Owner_
[[2] - because many parties could be related to the transport means
]]
12.2.2 Dictionary entry naming
[> 13.][< 12.2.1][^][^^][^^^]
Recall the structure of the property term in a dictionary entry name
[[1] - outlined on [UBL definitions - Section 3.1.4 UBL definitions]
 [1] - {qualifier_} {possessive-noun} primary-noun
]
When to use qualifiers or possessive nouns in property terms
[[1] - identifiers of different kinds of things have different possessive nouns
 [1] - different identifiers of the same kind of thing have different qualifiers
]
e.g. in "Address. Details"
[[1] - "Address. City Name. Name" and "Address. Street Name. Name" are names of different kinds of things
[[2] - both are names but the names belong to (are possessed by) different concepts of cities and streets
][1] - "Address. Street Name. Name" and "Address. Additional_ Street Name. Name" are names of the same kinds of things
[[2] - both are street names but the qualification of which street name is different
]]
e.g. Forwarding Instructions. Details
[[1] - Forwarding Instructions. UBL Version Identifier. Identifier
[[2] - <UBLVersionID> is not a forwarding instructions identifier
][1] - Forwarding Instructions. Customization Identifier. Identifier
[[2] - <CustomizationID> is not a forwarding instructions identifier
][1] - Forwarding Instructions. Profile Identifier. Identifier
[[2] - <ProfileID> is not a forwarding instructions identifier
][1] - Forwarding Instructions. Identifier
[[2] - <ID> is a forwarding instructions identifier
][1] - Forwarding Instructions. Carrier Assigned_ Identifier. Identifier
[[2] - <CarrierAssignedID> is also a forwarding instructions identifier
]]
Note how an unqualified ASBIE has same property term as representation term, so representation term is suppressed
[[1] - refer to section 4 of the UBL Naming and Design Rules
]


This is an accessible version of Crane's commercial training material. The content has been specifically designed to assist screen reader software in viewing the entire textual content. Figures are replaced with text narratives.

Navigation hints are in square brackets:
[Tx.x] and [Fx.x] are textual representations of the applicability icons;
[digit] indicates list depth for nested lists;
[link [URL]] indicates the URL of a hyperlink if different than link;
[EXAMPLE] indicates an example listing of code;
[FIGURE] indicates the presence of a figure replaced by its description;
[>] jumps forward;
[<] jumps backward;
[^] jumps to start of the section;
[^^] jumps to the start of the chapter;
[^^^] jumps to the table of contents.
Suggestions for improvement are welcome: [info@CraneSoftwrights.com]
Book sales: [http://www.CraneSoftwrights.com/links/trn-acc.htm]
Information: [http://www.CraneSoftwrights.com/links/info-acc.htm]
This content is protected by copyright and, as there are no means to protect this accessible version from plagiarism, please do not make any commercial edition available to others.

+//ISBN 1-894049::CSL::Presentation::UBL//DOCUMENT Practical Universal Business Language Deployment 2009-02-12 13:50UTC//EN
Practical Universal Business Language Deployment
Third Edition - 2009-02-12
ISBN 978-1-894049-23-8
Copyright © Crane Softwrights Ltd.