NISTIR 7175

XML Schema Design Quality Test

Requirement Document

Boonserm Kulvatunyou

K.C. Morris

 
NISTIR 7175

XML Schema Design Quality Test

Requirement Document

Boonserm Kulvatunyou

K.C. Morris

Manufacturing Systems Integration Division

Manufacturing Engineering Laboratory

October 2004

U.S. DEPARTMENT OF COMMERCE

Donald L. Evans, Secretary

TECHNOLOGY ADMINISTRATION

Phillip J. Bond, Under Secretary of Commerce for Technology

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

Arden L. Bement, Jr., Director

 
NISTIR 

1. Introduction 

Consistent design of XML schema within an organization or single integration project can reduce 

the number and the severity of interoperability problems. In addition, this consistency makes the 

XML schema easier to extend, understand, implement, and maintain; and, it paves the way for 

automated testing and mapping. 

Applying best practices is one way to achieve this design consistency. The literatures in the 

reference section advocate a number of recommended best practices for designing business 

message standards. In reviewing the recommendations from different references, we discovered 

that no single agreed upon set of best practices exists. 

Using a coherent subset of these recommendations, NIST researchers developed a collection of 

test requirements. These test requirements are maintained separately and organized according to 

the original reference documents on which they were based. This paper describes some of these 

requirements and provides rationale, explanations, examples, and comments for each. 

These requirements form part of a framework, which can be used to assess the overall quality of 

an XML schema. Other parts of the framework include computer executable test cases and test

profiles. Briefly, test cases are used to verify the conformance to those requirements and test 

profiles are groups of test requirements. Test profiles are entry points for executing a set of test 

cases. More information about test cases and test profiles, which are not described in this paper, 

can be found in [12]. 

The audience of this document includes XML architect and systems integration managers who 

are looking for XML schema guidelines to XML message development. The reader is assumed to 

have working knowledge of XML and XML Schema. 

2. Summary of Test Requirements 

This section summarizes design requirements included in this document. The summaries are 

given for each requirement table in the same order as those included in sections 7-14. 

2.1. Requirement from OAGI Design Document 

The Open Application Group Inc. (OAGI) design document [1] contains eleven (11) design 

requirements. These requirements are elementary practices for an XML architecture. Most are 

fully testable and most are generic across organizations. Consequently, any organization can test 

against these requirements, although slight variations may be required. 

2.2. Requirements from NIST B2B Testbed Recommendation 

Design requirements in Section 8 are obtained over the course of the National Institute of 

Standards and Technology (NIST) Business-to-Business (B2B) Testbed project [22]. Test cases 

written for a number of requirements included in this recommendation require heuristics. 

Consequently, the evaluation is approximation. Moreover, they require reference data and 

organizational specific data. We recommend that XML architect should consider adopting 

requirements #50, #200, #650 as baseline XML schema design practices. 

2.3. Requirements from GCSS-AF BOD Developer’s Guide, Version 1.0 Draft 

The Air Force (AF) Global Combat and Support System (GCSS) BOD developer’s guide [3] is a 

draft document. When completed, several of the practices described in this document, especially 

those related to metadata, could be adopted easily by any organization. This document derives a 

number of practices from the OAGI design document and the ebXML Core Component (ebCC) 

specification [14]. 

2
NISTIR 

2.4. Requirements from UBL Naming and Design Rules 

The Universal Business Language (UBL) [23] is an XML derivative of the ebCC Specification. 

The reader of these requirements must have a good working knowledge of the ebCC 

specification. The UBL approach is (1) to model the data using the ebCC method, and (2) to

automatically generate the XML schema from the ebCC constructs (modeled in a class diagram 

or a spreadsheet). The generated XML schema should normally conform to ebXML and UBL 

naming and design rules [10]. However, it is not possible to apply some rules to the generation. 

For example, the rules may be fuzzy, may require more information that is not accessible from 

the spreadsheet, or may be passive. In addition, final touches or manual changes to the schemas 

typically occur, particularly in the distributed development environment, and some information 

needs manual specification in the spreadsheet. Consequently, checking the generated schemas 

against these test requirements is an important step in quality assurance. For example, 

requirement #550, UBL namespaces exclusion, involves user extension, and requirement #650, 

UBL schema location, checks the schemas Internet accessibility. These two requirements could 

be tested only after the schema has been generated.

The intent to automatically generate XML schemas from the ebCC constructs makes the UBL 

name and design rules document very comprehensive. The rules cover recommended as well as 

disapproved XML schema constructs, XML schema architecture (how schemas are partitioned 

and modularized), versioning, and detail documentation guidelines. Most of the rules are concrete 

and testable. 

The applicable schema type for UBL has the value of ‘LAD’ for every test requirement because 

of the modeling practice promoted by this recommendation. In this practice the low, aggregate, 

and document level constructs can be mixed together in a single schema. 

2.5. XML.GOV Developers Guide 

The XML.GOV guideline [11] has thirteen (13) rules, most of which are partially testable. It 

gives a set of high-level guidelines for developing XML business content specifications for 

federal agencies. 

2.6. KIEC XML Guideline 

The Korean Institute of Electronic Commerce (KIEC) XML guideline [2] contains several unique 

practices that are not organizationally specific. This document identifies several design patterns 

and controlled vocabularies. KIEC divides information entities into four layers including 

messages, components (composing messages), basic information entities (composing 

components), and a code list used by basic information entities. 

Some practices conflict with other guidelines. There are also a number of inconsistencies and 

ambiguities, which must be resolved to improve testability and test coverage. These are described 

inline in the KIEC requirements table in Section 12.

2.7. Requirements from ASC X12 Reference Model for XML Design 

This ASC X12 design guideline [4] contains one of the most comprehensive sets of best practices 

that are architecturally independent (unlike the UBL naming and design rules which are specific 

to the ebCC specification). The guideline implements a philosophy that no single practice fits all 

needs. Its opinion is that what seems an advantageous decision from one viewpoint can be 

disadvantageous from another. 

X12 design rules come in two basic forms: syntax and semantics. The X12 practices seek to 

accomplish two contradictory design goals: (1) reusability of shared schemas and (2) instance 

data validation through fully detailed schema specification. X12 guideline recommends that 

shared document level schemas have as many restrictions as possible yet still create low-level 

schemas that are reusable. The practice relies on placing many of the restrictions in the higherlevel document schemas, which are the ones used in actual business transactions. 

3
NISTIR 

Some differing practices between X12 and OAGI design guidelines include its disallowance of

the xsd:substitutionGroup and xsd:any elements, while OAGI allows those practices. X12 

guideline also believes that the schema should be as prescriptive as possible for tight validation, 

while OAGI practice devises multiple stages of validations using the Schematron [9] and leaves 

the schema as flexible as possible to promote wider adoption. 

2.8. Requirements from AEX Guidelines 

The Capital Facilities Industry (CFI) has published two documents which serve as guidelines for 

XML Schema development work within the AEX (Automating Equipment Exchange) project 

[18]: Using XML Schemas for Facilities Equipment [19] and XML Schema Development 

Guidelines [20]. The first document contains the initial version of the AEX schemas, called 

cfiXML. The second contains the guidelines for developing those schemas. They are not 

completely consistent. When faced with an inconsistency, the later document supersedes. Some 

requirements in the AEX table are based on our experience from the AEX Testbed project. 

3. Test Requirements 

Each reference document (design guideline) has a corresponding requirements table, which 

appears at the end of this document1

. 

Each table has the following fields: 

1. ID: The ID column indicates the test requirement identification number for referencing 

purposes. 

2. Test Requirement: The Test Requirement column is a short name of the requirement. 

3. Test Coverage: The possible values of this column are ‘F’ = ‘Full’, ‘P’ = ‘Partial’, ‘U’ =

‘Unknown’, and ‘NA’ = ‘Not Applicable’. Requirements that can have full (F) or partial 

(P) coverage are testable. The ‘F’ value means that one or more test cases can fully

verify the conformance to the test requirement. The ‘P’ value means that the associated 

test cases can verify the conformance to the test requirement only partially. The ‘U’ value

means that the test coverage cannot be determined. Possible reasons include an external 

factor or variable scope. The ‘NA’ value means that there is no executable test case 

associated with the test requirement and the requirement is not testable via test cases. 

4. Rationale: The Rationale gives one or more reasons why this particular requirement is 

included. The possible choices are described in Section 3.1. 

5. Schema Type: The Schema Type indicates the kinds of schemas applicable to the test 

requirement. The value will be the combination of the ‘L’, ‘A’, and ‘D’. Section 3.2 

describes this in further detail. 

6. Description: The Description explains the practice and general approaches to testing. It 

also gives examples of the recommended construct. 

7. Note: Notes provide extra explanations or opinions that are not contained explicitly in the 

guideline document. A note can be a comparison with other practices, an explanation of 

the test coverage value, and further clarification of the description, to name a few. 

We note that values for the test-coverage field and schema-type field can change over time. For 

example, the availability of better reference data may shift the test-coverage value from “P” to

“F”. Moreover, the suggested values for schema type represent only one way to classify schemas 

 

1 Note that the NIST B2B Testbed recommendation table does not have a corresponding, published,

reference document. The contents of its table are based on our experience with that testbed. 

4
NISTIR 

in business data standards such as OAGI and UBL. In addition, the applicable schema type can 

be test-case dependent. 

3.1. Rationale 

We used a number of justifications for including specific requirements. They are listed below. 

a) Validation and model clarity is used for those practices that make the semantics of a construct 

clear to the user as well as to the machine. Subsequently, an XML parser can better validate 

the content of the instance against the schema. 

b) Structural clarity is used for those practices that contribute to a schema’s readability, which 

can facilitate consistent interpretation of a standard and accelerate adoption/implementation. 

c) Clarity is used for those practices that encapsulate both the structural clarity and validation 

and model clarity rationales. 

d) Extensibility is used for those practices that promote reuse through extension. Hence, 

extensibility also implies reusability. 

e) Common symbolic syntax is used for those practices that foster the use of common naming 

conventions. Such practices enable better automation and improve readability and clarity. 

f) Maintainability is used for those practices that reduce the maintenance burden especially

when changes occur. They help minimize repetitious work and potential errors. 

g) Performance is used for those practices that can reduce computational overhead associated 

with the XML instance parsing, validation, and other XML processing. 

h) Interoperability is used for those practices that promote interoperability among partners 

sharing the same schema. When no other rationale is applicable, this one is used. 

i) Model validity is used for those practices that ensure the schema’s semantic validity (e.g., no 

duplicate contents). The rules associated with this rationale may overlap with the schema 

parser or schema semantic checking functionality (the IBM Schema Quality Checker tool 

offers the schema semantic checking functionality [13]). 

3.2. Schema Types 

Schema types are categorized based on the level of aggregation of constructs included in the 

schema. Three values are used in order of increasing level of aggregation: L, A, and D. 

1. Low-level schema (L) - the schema typically contains simple types and complex types 

with simple content definitions. This may map to terms in business content standards. 

For example, the terms can be core-component types, data types, or basic business 

entities in the ebCC specification [14]. They can also be fields, meta, or enumeration in 

the OAGI specification [15]. The types of schema typically contain reusable, context-free 

vocabulary, and the elements or types included are not by themselves meaningful to a 

business exchange. 

2. Aggregate level schema (A) - the schema typically contains complex type definitions and

corresponding global-element declarations. These may map to terms in business content 

standards such as the aggregate business information entity in the ebCC specification or 

components in the OAGI specification. The constructs in this schema reuse the constructs 

from the low-level schema.

3. Document level schema (D) - the schema typically contains only a few definitions of 

complex types and global element declarations. These may map to terms in business 

content standards such as the assembly document in the ebCC specification, nouns and 

business object documents in the OAGI, or the transaction concept in the RosettaNet 

Implementation Framework specification [21]. The schemas at this level typically do not 

directly reuse the constructs from the low-level schema but the constructs from the 

aggregate level schema. 

5
NISTIR 

If a schema contains more than one level of construct, it should be tested against the requirements 

for all assigned values. 

4. Future work 

A test framework, with a web-based interface, is being developed. A hyperlink will be provided 

on the NIST Manufacturing Business-to-Business Interoperability Testbed web site [22]. Test

cases for a selected set of test requirements will be encoded. Test requirements included in this 

document may be implemented in the web-based repository. In addition, a set of matrices 

providing comparison among test requirements coming from different XML guidelines is being 

developed. 

5. References 

1. Rowell, M., Feblowitz, M. (2002). OAGIS 8 Design Document (Draft 0.93). 

2. Korean Institute for Electronic Commerce. Guidelines for Development of XML Electronic 

Messages in Korea (March 2003). Available online via 

<www.xeni.co.kr/support/KIECGuidelineFinal_english_.pdf>. 

3. Lockheed Martin Federal Systems (October 2002). Global Combat and Support System – Air 

Force BOD Developer’s Guide Draft Version 1.1. Department of Air the Force Headquarters 

Materiel Systems Group (MSG). 

4. ASC X12C Communications and Controls Subcommittee (October 2002). ASC X12 

Reference Model for XML Design. ASC X12C/2002-61. 

5. World Wide Web Consortium (May 2001). XML Schema Part 0: Primer Structure W3C 

Recommendation http://www.w3.org/TR/xmlschema-0/. 

6. ebXML Technical Architecture Specification v1.0.4, 16 February 2001. 

7. Roger Costello XML Schemas: Best Practices 

http://www.xfront.com/BestPracticesHomepage.html. 

8. Roger Costello XML Schema Versioning http://www.xfront.com/Versioning.pdf. 

9. Jelliffe, R., The Schematron Assertion Language 1.5, Academia Sinica Computing Center. 

http://www.ascc.net/xml/resource/schematron/Schematron2000.html. 

10. OASIS UBL Naming and Design Rules Subcommittee (November 2003). Universal Business

Language (UBL) Naming and Design Rules. 

11. US Federal CIO Council Architecture and Infrastructure Committee, XML Working Group

(April 2002). Draft Federal XML Developer’s Guide. 

12. Kulvatunyou, B., Ivezic, N., Buhwan J. Testing Requirements to Manage Data Exchange 

Specifications in Enterprise Integration – A Schema Design Quality Focus. 8th World 

Multiconference on Systemics, Cybernetics and Informatics (SCI), July 2004, Orlando, 

Florida. 

13. IBM Corporation. The IBM Schema Quality Checker. 

http://www.alphaworks.ibm.com/tech/xmlsqc. 

14. DISA UN/CEFACT. EbXML Core Component Specification version 1.9 (December 2002). 

http://webster.disa.org/cefact-groups/tmg/downloads/CCWG/for_review/CCTS_V_1pt90.zip. 

15. Open Application Groups Web Site, accessed March 2002. Open Application Group 

Integration Specification version 8.0. http://www.openapplications.org/downloads. 

16. University of Edinburgh/W3C. XSV 2.7, an Open Source XML Schema Validator. 

http://www.ltg.ed.ac.uk/~ht/xsv-status.html. 

6
NISTIR 

17. The Apache Software foundation. Xerces2 Java Parser Release 2.6.2. 

http://xml.apache.org/xerces2-j/index.html. 

18. Automated Equipment Exchange (AEX) project 

http://www.fiatech.org/projects/idim/aex.htm. 

19. Teague, T. L., Turton, R. W., and Palmer, M. E., Using XML Schemas for Facilities 

Equipment, July 2004. http://www.fiatech.org/projects/idim/aexresources.htm. 

20. Palmer, M.E., Burns, M., and Teague, T.L., FIATECH XML Schema Development 

Guidelines, March 2003. 

21. The RosettaNet Web Site, accessed May 2003. RosettaNet Implementation Framework 

(RNIF) Specification version 2.0. 

http://www.rosettanet.org/RosettaNet/Doc/0/TAO5O8VV3E7KLCRIDD1BMU6N38/RNIF2.

1.pdf. 

22. The Manufacturing Business-to-Business Interoperability Testbed Web Site 

http://www.mel.nist.gov/msid/b2btestbed/. 

23. Unified Business Language. 

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl. 

24. United Nations Directories for Electronic Data Interchange for Administration, Commerce 

and Transport – 3055 Code List, Responsible Agency Code. 

http://www.unece.org/trade/untdid/d03a/tred/tred3055.htm. 

25. Metadata Standards Organization Web Site, ISO/IEC 11179, Information Technology – 

Metadata Registries (MDR). http://metadata-stds.org/. 

26. XML Common Business Library. http://www.xcbl.org/ . 

27. Open Travel Alliance. http://www.opentravel.org/. 

28. United Nation Directories for Electronic Data Interchange for Administration, Commerce, 

and Transport. http://www.unece.org/trade/untdid/welcome.htm. 

6. Disclaimer 

Certain commercial software products are identified in this paper. These products were used only

for demonstration purposes. This use does not imply approval or endorsement by NIST, nor does 

it imply that these products are necessarily the best available for the purpose. 

7
NISTIR 

7. OAGI Design Document 

ID Test Requirement Schema type Test Coverage Ratio

50 Check for non-determinism. LAD P Validation and model clar

Description: This includes the check for data structures that fall into “type by attribute” category such as assigning party 

Party element with a type or qualifier attribute). This unnecessarily limits the extensibility and model (data stru

types are hidden. Separate types should be defined with relationships (e.g., ShipToParty and ShipFromParty as sucase, one can associate any unique property to the two subtypes. In addition, whenever only the ShipToParty type is a

explicitly indicated in the model and validated by the parser. These cannot be done if the type is hidden in the attribute. Note: Example: If there are two types of parties required within an element, this non-determinism pattern cannot be indic

specified. Because there is little structure/model associated with simple types, the non-determinism should apply to only c

The Venetian blind approach suggests that the user should define as many types as necessary and use them to specify the 

the example about Party. In addition to the ShipToParty and the ShipFromParty, DeliveringParty and Receivin

First, this helps relegate the long name to the type definition leaving the element name (which is sent over the wire) succin

semantics of the element clearer which leads to better validation. 

100 Check for conformance to naming conventions. LAD P Common symbolic syntax 

Description: OAGIS 8.0 recommends use of upper camel case. To ensure consistency, the upper-camel-case tag should beach sub-string and to ensure the validity of each substring – words, acronyms, or abbreviations. An all-upper-case substr

specific acronym and ignored or checked against a list of allowable acronyms. Note: ebXML Technical Architecture specification [6] provides guidelines for upper-camel-case convention. Cross-refereand abbreviation should be specified. This allows for information recognition and more efficient processing. Long tag namconvention because of the availability of increased computing power. Upper-camel-case convention is also adopted for suensure common usage of the upper camel case across the organization and will help facilitate some automation as well. Otag name longer than 31 characters be approved by the consortium.

8
NISTIR 

150 Check for improper use of anonymous type. AD F Extensibility 

Description: Content model of an anonymous type is defined locally within an element. It cannot be referenced outside ohence, it cannot be reused. On the other hand, a globally defined type allows it to be referenced and reused. OAGIS adap

design approach -- global types should be defined where necessary, but global elements should be declared only for extenSee also #300. Note: In XML schema, type definitions can be viewed as a content model, but the element definitions are viewed as docu

Content/data model has tight relationship with functional requirements or functional model. Hence, software components corresponding to the content/data model rather than to the document structure. The content model represents entities that a

therefore, software components developed around it can also be reused. Although the use of global types can cause name-clashing problem, the availability of namespace mechanisms reduce this same term with different concepts (perhaps in different domains) can be defined in different namespaces. 

Anonymous type may be used for company’s specific terms and terms that have a very specific and succinct semantics. 

200 Check for use of weak typing. AD F Validation and model clar

Description: Contents (both element and attribute content) within complex structured elements/types (those having these 

complexType/sequence and complexType/complexContent) that are typed as XML Schema primitive Data Type 

typing. This pattern is prone to violate the Venetian Blind [7] design (i.e., it is more like a Russian Doll [7] design). Note: XML schemas, which provide high degree of information aggregation, should not have their structure based on prim

provides little semantics to the users and the integration software. Weak typing also limits the validation capability.

250 Check for feature regression. LAD F Maintainability, extensibi

Description: Deriving a new complex type by restriction of another complex type requires that the derived type repeat all 

base type. This can cause inconsistency within the schema especially when changes are needed. When changes are applied 

derived types must be revised. Note: Alternatives to this functionality are the substitution group or an external restriction specification like Schematron [This can also be viewed as XML Schema limitation. 

9
NISTIR 

300 Check for global element definition LA P Extensibility 

Description: OAGIS uses global element definition only when it is intended to be inline extensible. OAGI views substi

extensibility as a design time and declarative extension approach. The use of xsi:type extension approach is viewed as hidden approach, which does not represent well the intention of the schema designer. Note: Global elements should be used only in an aggregate-level schema or in component-level information. Global elemso they should be very self-contained. In the aggregate level, elements (or schemas) may reference other aggregate-level edeclaring local elements associated with global types of a low-level entity. Low-level element is unlikely to be extended oelement is not necessary.In fact, the xsi:type can indicate the designer’s intention to use the abstract attribute to indicate whether or not it can 

xsi:type requires that an XML processor be more intelligent and prepared for variations that could occur at runtime. In 

not declarative. 

350 Improper use of enumeration type. LAD P Extensibility 

Description: Enumeration is not easily extensible using the XML schema construct. OAGIS practice indicates that enume

stable code list only (not change in years). That means, for example, value list associated with business strategy should no

construct. Note: We conclude that this practice may be applicable only to definitions in the standard. Elements used only internally enumeration construct even if the value list is changeable. In addition, enumeration may be extended using the XML-ScheThe testability is limited because it is hard to determine whether the semantics of a type is appropriate for the enumeration 

references to standard code lists can be created and used for partial detection. UBL and KIEC have identified such a colle

summarized in Section 15). 

400 Non-recommended extension LA P Performance

Description: Some type definitions are not intended to be extensible. OAGIS practice states that its fields and compounds 

due to too much overhead associated with the extensions from these lightweight type definitions. Note: The test coverage may be partial because it is impossible to determine the real intention absolutely. If a schema is id

type, a test case may assume that all included terms are not extensible. This may not be true for the aggregate-level schem

450 Non-recommended use of default namespace LAD F Structural clarity 

Description: Imported schemas are those schemas that come from different namespaces. Industry practice is not to use de

imported schema, so that the user/reader can always recognizes that entities2 with namespaces are from different namespa

namespace. 

2 The term ‘Entity’ used in this document generally refers to both ‘element’ and ‘type’.

10
NISTIR 

Recommended use of default namespace, i.e., non-recommended use of no target namespace 

500 LAD F Structural clarity 

Description: Use of default namespace is recommended in an XML schema because it prevents the use of no target name

Note: In the standards arena, all elements should have an associated namespace. The chameleon namespace approach des

applicable to the standard development. 

Enforce other/other pattern in the enumeration type 

550 LAD F Extensibility 

Description: OAGIS recommends that the other/other enumeration pattern be an easy (and temporary) enumeration exten

recommends that such an extension should be considered into the next release of the OAGIS. Note: In a not-so-stable code list, OAG also recommends a semantically named design pattern as an alternative to enumer

recommends that a set of types be created for each enumerated value. Since this approach is based on type definitions, the definition with new types. 

11
NISTIR 

8. NIST B2B Testbed Recommendation 

ID Test Requirement Schema type Test Coverage Ratio

Check for improper use of no namespace schema. 

50 LAD F Extensibility 

Description: A schema without a namespace can hardly be used across organizations because entities cannot be un

addition, a schema will have limited extensibility before name clashing occurs. The schema’s attribute targetNam

Check the schema for its referential ability to facilitate the use of existing standards. 

100 LAD P Interoperability 

Description: This test requirement will try to do semantic matching and suggest a reference to an existing standard

structured so that their attributes allow specification of meta-data (pointing to associated standards) or they should b

enumerations. Note: A table indicating the cross-referencing between concepts and standards is necessary. UBL and KIEC have idenumerations (code lists, see Section 15). The test coverage is partial, because we may not be able to collect all the 

Check for organizational specific look and feel. 

150 LAD U Structural clarity 

Description: The criteria of this test will be organization dependent, although the patterns will be the same. Some o

target namespace, namespace abbreviation, and consistent use of qualified or non-qualified element and attribute fo

Note: The test coverage is unknown because the scope of the test cannot be predetermined. 

200 Detect unnecessarily long tag name. LAD F Maintainability, Performa

Description: Detect child elements that repeat the name of a parent element (i.e., its context). Note: This rule recommends that the name of child elements not be repeated. On the other hand, if the Venetian blin

tag names can be deferred to the type definition while keeping the element name short. 

250 Enforce Id design pattern LAD P Interoperability 

Description: The Id design pattern recommends that the assigning organization and revision number be specified. Tan object to have multiple Ids. Note: The test coverage is partial, because the test may not be able to recognize all the constructs that should adopt 

12
NISTIR 

300 Code list design pattern LAD P Extensibility, Interoperab

Description: Elements definitions that are based on an enumerated list should allow metadata about the code so thabe used. For example, a currency element using currency code should have an attribute such as code list name and/oNote: The test coverage is partial, because not all constructs based on the code list may be tested without user indicable to recognize all the constructs that should adopt the code design pattern. However, all enumeration types can b

code list construct. 

350 Indicator design pattern LAD P Extensibility, Interoperab

Description: An indicator type should include an indicator –type format attribute. Note: The test coverage is partial, because not all constructs based on the indicator type may be tested without user 

not be able to recognize all the constructs that could adopt the indicator design pattern. 

400 Datetime design pattern LAD P Extensibility, Interoperab

Description: Datetime type should include a Datetime-type format attribute. Note: See also DateTime. Type core component type of ebCC specification. 

The test coverage is partial, because not all constructs based on the datetime type may be tested without user indicat

able to recognize all the constructs that could adopt the Datetime design pattern. 

450 Measure design pattern LAD P Extensibility, Interoperab

Description: Measure type should have a unit attribute and metadata about the unit code list (e.g., name, and agenc

Note: See also Measure. Type core component type of ebCC specification. 

The test coverage is partial, because not all constructs based on the measure type may be tested without user indicatable to recognize all the constructs that could adopt the Measure design pattern. 

500 Quantity design pattern LAD P Extensibility, Interoperab

Description: Quantity type should have a unit attribute and metadata about the unit code list (e.g., name, and agencNote: See also Quantity. Type core component type of ebCC specification. The test coverage is partial, because 

the quantity type may be tested without user indication. The test may not be able to recognize all the constructs that design pattern. 

13
NISTIR 

650 Check for Null content model LAD F Validation and model clar

Description: A document should not contain all optional elements because then the document can be empty. A co

element) must not contain an empty content. That is it should contain either at least one required child element or altype entity should enforce non-empty text content. 

Proper use of the plural element/attribute names 

700 AD P Validation and model clar

Description: There are generally two interpretations associated with the plural form. The first interpretation is that different information entities or objects. The second interpretation is that it is a container of the same information en

represented in multiple ways (for example, an Item Id could be specified with a customer’s version and a supplier’s that a plural form be used for the second interpretation while a singular form associated with a multiplicity cardinaliinterpretation (without a container element). Note: This test requirement may be tested through assumed schema patterns. An attribute name should not be a plur

token. A plural element name should be followed an element with multiplicity cardinality, which must be also a heabased on a type for which various ways of instantiation is possible (e.g., more than one non-abstract extensions exispartial because it is uncertain whether the assumed pattern covers all the cases. 

Duplicative content (hidden nondeterministic content model) 750 AD P Model validity 

Description: This test looks for implicitly duplicative content. For example, two child elements with different namecomplex type. Note: It should be noted that some parsers and grammar checker like the IBM Schema Quality Checker already valwhen an element contains references to the same element. 

14
NISTIR 

9. GCSS-AF BOD Developer’s Guide, Version 1.0 Draft 

ID Test Requirement Schema type Test Coverage Ratio

50 Enforce camel case convention LAD P Common symbolic syntax 

Description: GCSS-AF document reference ebXML technical architecture recommendation. This requirement is th(see #100 in the OAGIS table).

100 Usage of acronyms and abbreviations LAD F Common symbolic syntax 

Description: GCSS-AF recommendations are slightly different from OAGIS in this category. (a) Abbreviations mu

Acronyms should be avoided unless very common; but, when used, they must be in all upper case overriding the ca

Acronyms must be spelled out in the associated annotation element.Note: In this test, the test coverage has been specified as Full; however, this is a theoretical value. The reason is thaunknown values but the flag may or may not be a negative indicator depending on the user’s literary reference. 

150 XML component metadata requirements LAD N/A Interoperability, Common 

Description: GCSS-AF requires that component definition (its type definition) must have pointers to information in 

definition, URL, and registry identifier. This would require that all global complex types (which are classified as cothe metadata is specified.Note: This requirement is not testable because the guide recommends multiple, possibly unstructured, ways of captu

addition, it does not normatively specify the metadata needed.

Check for conformance to ebXML naming convention 

200 LAD P Common symbolic syntax 

Description: This test requirement references the ISO 11179 naming convention. It needs to verify, for example, th

plural forms have been used in the name.Note: The test coverage in this case is partial because the name may or may not be parsed into separate substrings c

multiple functionalities resulting in several false alarms and some false positives. 

250 Check for documentation LAD P Interoperability 

Description: All element and type definitions must have an annotation child element.Note: This only partially checks the documentation. We can never check that the documentation is sufficient.

15
NISTIR 

300 Enumeration reference LAD F Interoperability 

Description: All elements or types based on an enumerated value must provide pointers to where the code lists are 

Note: This requirement is similar to that of #250 in the NIST Recommendation table. However, the scope is limited and elements based on enumeration have placeholders for metadata attributes.

350 Versioning LAD F Configuration control 

Description: Version information must be provided in XML Schemas within the annotation. For a DTD, this inform

in a fixed attribute of the root element. For XML Schema, use <xsd:appInfo> tag under the annotation of the roo

Note: GCSS-AF also recommends that version number of the schema be provided within the XML instance. Every attribute in the root element. 

Metadata in the header of schemas and documents 

400 LAD P Maintainability, Interoper

Description: The following metadata indicated in Appendix F must be provided in the headers of both schema and 

schema version, DOD namespace(s), functional data area, URL to the most current version, a description of the purof the application or program of record that created and and/or manages the schema, among others.Note: These fields cannot be normatively verified for schema, because no normative tags have been specified to datverify that the first <xsd:appInfo> element in the schema contains those information objects in a text format. See 

the guideline document. *This document focuses on requirements for schema only.

Correct use of attribute (attribute vs. element) 

450 LAD P Extensibility 

Description: The followings characteristics (rules) apply to attribute: (a) Attribute should be based on code list (enu

instance. An Attribute value should be a short, simple, single token (no white space). Attribute cannot have a complmetadata about information. (d) Attribute should only be used to describe information units that cannot or will not b

(e) Attributes of an element should generally be applicable to all of its child elements.

Note: The test coverage is partial because the verifying conditions require information that is not available in the schard to generalize. Particularly, (a) can be verified; (b) can be verified through instances; (c), (d), and (e) cannot be knowledge about these conditions cannot be captured in a generic fashion.

16
NISTIR 

10. UBL Naming and Design Rules 

ID Test Requirement Schema type Test Coverage Ratio

50 Schema look and feel LAD P Structural clarity 

Description: The structure of a UBL compliance schema has been specified in Section 3.1 of its guideline. It indica

declarations and the order in which different types of components should be specified. Note: The section covered by this requirement is 3.1, rule GXS1. The test coverage is specified as partial because it 

different types of components can be identified and checked. 

100 One root element is defined in a schema D F Structural clarity 

Description: Each UBL ControlSchema MUST identify one global element declaration that defines the overall bus

conveyed in the Schema expression. That global element MUST include an xsd:annotation child element which 

xsd:documentation child element that declares “This element MUST be conveyed as the root element in any ins

this Schema expression.” A ControlSchema is a schema that conveys a specific business document. Each name will 

control schema. Note: The section covered by this requirement is 3.1.1, rule ELD2. 

Pointer from a dictionary entry name to an element or attribute 

150 LAD F Clarity 

Description: Each dictionary entry name (see ebCC specification for the definition of the dictionary entry name) m

Fully Qualified Path (FQP) to an associated element or attribute. UBL uses truncated names for element and attribudictionary entry name retains the full name. Dictionary entry names are maintained in the UBL documentation dictiNote: The section covered by this requirement is 3.2.1, rule NMC1. 

200 UBL Classes LAD NA Model validity 

Description: UBL Models must define classes based on ccts:BasicBusinessInformationEntities and 

ccts:AggregateBusinessInformationEntities. 

Note: The section covered by this requirement is 3.2.2.1, rule MDC1. The Model validity rationale is from the UBL The testability is identified as not possible because it is uncertain how UBL models are linked to the 

ccts:BasicBusinessInformationEntities and ccts:AggregateBusinessInformationEntities. 

17
NISTIR 

250 Core component type restriction LAD F Model validity 

Description: Each ccts:BasicBusinessInformationEntity must be associated with ebXML Core Compon

ccts:CoreComponentTypes. 

Note: The section covered by this requirement is 3.2.2.2, rule MDC2. The testability and test coverage reflect the as

ccts:CoreComponentType schema is available and ccts:BasicBusinessInformationEntities can be d

annotation. 

Consistent business function in customization 

300 LAD NA Model validity 

Description: Customization of UBL document must retain the original business function of that document. Note: The section covered by this requirement is 3.2.2.3, rule MDC3. The testability is identified as not possible be

methodology available to measure the customization relative to the business function. The model validity rationale requirement is only from the UBL perspective. 

350 Mixed content model LAD F Interoperability 

Description: Mixed content must not be used to pass business data. Mixed content should be disallowed. 

Note: The section covered by this requirement is 3.2.2.4, rule MDC4. Mix content occurs when an XML element ccharacter data. 

400 Reusability LAD F Extensibility

Description: All element declarations must be global except for ID and Code. The section covered by this requirem

rationale that UBL adopts this architecture. When global elements are used, software code can be reused without a cwhen using global type definition.Note: The section covered by this requirement is 3.3, rule ELD2. Although the test coverage is full, a number of fal

identified because it may not be possible to correctly identify the exception cases for ID and Code. 

450 Target namespace declaration LAD F Model validity 

Description: Every schema created (called UBL-defined schemas) and used (called UBL-used schemas) must have Note: The section covered by this requirement is 3.4.1, rule NMS1. The model validity rationale for this particular 

UBL perspective (i.e., it does not mean that a schema without a target namespace has an invalid model). 

18
NISTIR 

Namespace uniqueness and schema version 

500 LAD P Structural clarity, Mainte

Description: UBL uses the namespace scheme to group schemas into Schema Sets. All schemas in a schema set mu

Different versions must also have different target namespaces. Note: The section covered by this requirement is 3.4.1, rule NMS2. The test coverage is partial because we can only 

the same namespace have the same version. We cannot verify a correct target namespace, unless a schema set is idenamespace uniqueness cannot be tested for a similar reason. 

550 UBL namespaces exclusion LAD F Structural clarity 

Description: Only UBL maintained schemas could use UBL namespaces; any extension from a UBL library must d

Note: The section covered by this requirement is 3.4.1, rule NMS3. The full test coverage is based on the assumptio

UBL library can be recognized. This requires a complete set of UBL schemas from its library. 

UBL namespace patterns LAD P Structural clarity, Mainte

syntax 

600 

Description: UBL uses URN format (a subset of URI, IETF RFC 2396) for its namespaces. The UBL draft schema

urn:oasis:names:tc:ubl:schema:<name>:<major>:<minor>[:<revision>], and the UBL schemas holding OASIS stan

pattern, urn:oasis:names:specification:ubl:schema:<name>:<major>:<minor>. The <name>, <major>, <minor>, and while the revision is optional. The major version must be a positive integer. The minor version must be a non-negat

the first version would start at 1:0. The minor version is incremented for every new release that is backward compatremain the same throughout versions unless a new name is needed. This indicates that any change in a schema modnamespace association. UBL takes the approach that such association should not be altered once published. This enschema always imports the intended content and that such content is always available (unchanged). Note: The sections covered by this requirement is 3.4.2 and 3.5, rules NMS4, NMS5, VER1, VER2, VER3, VER4, VER5 on lines 1054 and 1056 (typo in the document), VER6. The status, draft or standard, of a schema must be idenamespace pattern. The rules VER5 and the duplicated VER4 and VER5 could only be checked if a repository of sc

VER6 is the same as the rule NMS2 and is directed to the test requirement #500. The revision number will be assum

integer when presents (this is not explicitly specified in the guideline). 

650 UBL schema location LAD P Structural clarity 

Description: UBL schemas must be hosted at OASIS UBL TC web site and are available at this URL pattern http:/

open.org/comittees/ubl/schema/<schema-mod-name>.xsd. Note: The section covered by this requirement is 3.4.4, rule NMS6. 

19
NISTIR 

700 Namespace persistence LAD P Structural clarity, Mainte

Description: UBL namespaces must never be changed (while the actual location of schemas may change). 

Note: The section covered by this requirement is 3.4.4, rule NMS7. The requirement is partially testable based on a

schemas contain similar set of definitions. 

750 Schema’s version attribute LAD F Common symbolic syntax

Description: UBL schemas must be versioned with the following representations: 1) <major>:<minor>:[<revision>] where the <revision> is optional. 

2) <major>:<minor> The value of <major> version begins with 1. The value of the <minor> begins with 0. The first minor version of a value of 1. Note: The section covered by this requirement is 3.5. The version number should follow what has been described in 

800 Minor versions compatibility LAD P Interoperability 

Description: In a minor version, the name of the version construct must not change (the short name), unless the inte

rename the construct. Minor versions must import their immediately preceding minor version and maintain backwarbackward compatibility is maintained by the restricted use of only xsd:extension and xsd:restriction mech

guarantee of semantic compatibility. The xsd:redefine must not be used. New constructs may be added. 

Note: The section covered by this requirement is 3.5, rules VER5, VER8, VER9, and VER10. While the rule VER5 changes between minor revisions, we interpret the last part of the rule “intent of change is to rename the construct” 

the semantics. Such intentions cannot be recognized completely. However, the likelihood of false negatives increase

testable in full, testing the rule VER9 is not possible because the semantic compatibility with the previous version c

this reason, the test coverage is partial. 

850 Unambiguous schema dependency LAD F Model validity 

Description: UBL classified the schemas into control schemas, internal schema modules (same namespace), and excontrol schema module includes (depends on) the internal schema modules. UBL requires that any external depende

control schema of that namespace and not the internal schemas of that namespace. Note: The section covered by this requirement is 3.6.1.1, rule SSM2 and SSM3.

900 Internal schema module name LAD F Common symbolic syntax

Description: UBL internal schema module name must have the following format <ParentSchemaModuleName/ControlSchema><InternalSchemaModuleFunction><SchemaModuleName>. The intebe in the same namespace as the control schema. Note: The section covered by this requirement is 3.6.3, rule SSM6 and SSM7. 

20
NISTIR 

950 Data Type documentation LAD F Clarity 

Description: The data type must contain a structured set of documentation in the following pattern. 

UniqueIdentifier (M), CategoryCode (M), DictionaryEntryName (M), Definition (M), Version (M), 

(O), ObjectClass (M), QualifierTerm (M), UsageRule (O+). A usage rule is a constraint describing specific c

applicable to the data type. A data type that is defined using restriction on the Content Component must include the 

pattern. RestrictionType (M), RestrictionValue (M), and ExpressionType (O). A data type that is define

Supplementary Component must include the following documentation pattern. SupplementaryComponentName 

(M) and repetitive. The CategoryCode is the category to which the object belongs. For example, ABIE for Aggreg

Entity, BBIE for Basic Business Information Entity, ASBIE for Association Business Information, RT for RepresenNote: M = Mandatory, O = Optional, O+ = Optional with repetitive. The occurrence of the ObjectClass is not sp

assumed mandatory here. The section covered by this requirement is 3.7, rule DOC1, DOC2, and DOC3. Although 

guideline, the CategoryCode for Data Type is assumed DT. 

1000 Basic business information entity documentation LAD F Clarity 

Description: The basic business information entity (BBIE) must contain a structured set of documentation in the fo

UniqueIdentifier (M), CategoryCode (M), DictionaryEntryName (M), Version (M), Definition (M), QualifierTerm (O), UsageRule (O+), ConstraintLanguage (O+), BusinessTerm (O+), Example (O+). A u

conditions that are applicable to the basic business information entity. The Cardinality indicates whether the BBIE r

mandatory, optional, or repetitive characteristic of the Aggregate Business Information Entity (ABIE). The Qualif

Property Term of the associated Core Component Property in the associated Aggregate Core Component. The Cons

formally indicates how the BBIE is derived from the Core Component. The Example contains example values of th

CategoryCode is always BBIE in this case. 

Note: The section covered by this requirement is 3.7, rule DOC4. 

1050 Aggregate business information entity documentation LAD F Clarity 

Description: The Aggregate Business Information Entity (ABIE) must contain a structured set of documentation in 

UniqueIdentifier (M), CategoryCode (M), DictionaryEntryName (M), Version (M), Definition (M), UsageRule (O+), ConstraintLanguage (O+), BusinessTerm (O+), Example (O+). The UsageRule describe

are applicable to the ABIE. The QualifierTerm qualifies the Object Class Term of the Aggregate Core Compone

ConstraintLanguage formally indicates how the ABIE is derived from the stored Core Component and Business 

example of a possible value of the ABIE. The CategoryCode is always ABIE in this case. 

Note: The section covered by this requirement is 3.7, rule DOC5. 

21
NISTIR 

1100 Association business information entity documentation AD F Clarity 

Description: The association business information entity (ASBIE) must contain a structured set of documentation i

UniqueIdentifier (M), CategoryCode (M), DictionaryEntryName (M), Version (M), Definition (MQualifierTerm (O), UsageRule (O+), ConstraintLanguage (O+), BusinessTerm (O+), Example (O+)indicates whether the ASBIE represents a not-applicable, mandatory, optional, or repetitive characteristic of the AB

describes specific conditions that are applicable to the ABIE. The QualifierTerm qualifies the Property Term of 

Component Property in the associated Aggregate Core Component. The ConstraintLanguage formally indicates 

from the stored Core Component and Business Context. The Example is example of a possible value of the BBIE. T

always ASBIE in this case. Note: The section covered by this requirement is 3.7, rule DOC6. 

1125 Core Component documentation LAD F Clarity 

Description: The core component (CC) must contain a structured set of documentation in the following pattern. 

UniqueIdentifier (M), CategoryCode (M), DictionaryEntryName (M), Version (M), Definition (M), PropertyTerm (O), UsageRule (O+), BusinessTerm (O+). A UsageRule is a constraint that describes specific 

applicable to the BBIE. The CategoryCode is always CCT in this case. 

Note: The section covered by this requirement is 3.7, rule DOC7. Although the M/O of the ObjectClass and Pro

indicated in the guideline, mandatory are assumed. 

1150 Element’s documentation LAD F Clarity 

Description: Any element declaration must contain a structured set of documentation in the following pattern, <do

Entry Name</documentation>. The Dictionary Entry name is an official name not the tag name. 

Note: The section covered by this requirement is 3.7.1, rule DOC8. 

1200 Code list used documentation LAD F Interoperability, Clarity 

Description: For each UBL construct containing a code, the UBL documentation MUST identify zero or more code 

minimally supported when the construct is used. The following documentation must be specified. Prefix (M), Cod

CodeListAgency, and CodeListVersion. The Prefix is for example, ‘cnt’ for Country Code List. The CodeL

example ‘ISO 3166-1’. The CodeListAgency indicates maintainer of the code list such as ‘6’. The CodeListVe

‘0.3’ 

Note: The section covered by this requirement is 3.7.1, rule DOC9. Although a test can be performed to validate the annotations, it may not be able to validate the values. 

22
NISTIR 

XML names (element/attribute/type names) 

1250 LAD F Clarity 

Description: XML names must follow the Oxford English dictionary. Element and type names must follow upper c

names must follow lower camel case as described in the ebXML architecture specification document [6]. Note: The section covered by this requirement is 4.1, rule GNR1, GNR9, and GNR10. From the run-time testing pebe validated lexically with Oxford English dictionary. However, some valid Oxford words may not be appropriate f

1300 XML names and dictionary entry name LAD F Clarity 

Description: UBL XML names must be taken from ebCC specification conformant dictionary entry name. Howeve

dictionary entry name that is not allowed in the XML name, as specified by W3C standard, must be omitted. Note: The section covered by this requirement is 4,1, rule GNR2 and GNR3. UBL allows some deviations from of 

dictionary entry name. If such deviation does not have a formal pattern, many false negative flags may result. 

1350 Used of abbreviations or acronyms LAD F Clarity 

Description: Only abbreviations or acronyms documented in the Appendix B of the guideline are allowed in UBL X

Note: The section covered by this requirement is 4.1, rule GNR4. 

1400 Singular form of XML names LAD F Clarity 

Description: UBL XML names must be in singular form unless the concept itself is of plural form by default, e.g., Note: The section covered by this requirement is 4.1, rule GNR8. 

1450 ComplexType name of ABIE LAD F Clarity 

Description: ComplexType name associated with an ABIE must follow the ABIE’s dictionary entry name with sep

‘Details’ replaced with ‘Type’. For example, an ABIE Dictionary Entry Name (DEN) ‘Transport_ Equipment Seal. 

complexType name TransportEquipmentSealType. 

Note: The section covered by this requirement is 4.2.1, rule CTN1. This test will be performed based on the DEN p

documentation. 

1500 ComplexType name of the BBIE LAD F Clarity 

Description: ComplexType name associated with a BBIE must follow the BBIE’s DEN with separators and Objec

‘Type’ suffix to the Representation Term. For example, a BBIE DEN ‘Account. Charge. Indicator’ is converted into 

ChargeIndicatorType. 

Note: The section covered by this requirement is 4.2.2, rule CTN2. This test will be performed based on the DEN p

documentation. 

23
NISTIR 

ComplexType name of the Primary 

Representation Term 

1550 LAD F Clarity 

Description: ComplexType name associated with a Primary Representation Term must follow the name of the cor

Component Type (CCT) with separators omitted and ‘Type’ suffix to the Primary Representation Term name. For eRepresentation Term ‘Amount’ is based on a CCT ‘Amount. Type’, the corresponding complexType name is Amou

Note: The section covered by this requirement is 4.2.3, rule CTN3. This guideline does not require annotated docum

Representation Term. The DEN for checking this conformance may need to be obtained from another source. 

ComplexType name of the Secondary 

Representation Term 

1600 LAD F Clarity 

Description: ComplexType name associated with a Secondary Representation Term must follow the name of the S

Term with a ‘Type’ suffix to the Secondary Representation Term name. For example, the corresponding complexT

Representation Term ‘Value’ is ValueType (the Primary Representation Term of ‘Value’ is ‘Numeric’.

Note: The section covered by this requirement is 4.2.3, rule CTN4. The guideline does not require annotated documRepresentation Term. The DEN for checking this conformance may need to be obtained from another source. 

ComplexType and simpleType name of 

the CCT 

1650 LAD F Clarity 

Description: A CCT may be mapped to a simpleType or a complexType. XML names associated with a CCT m

CCT with the separators removed. For example, the complexType name of the CCT ‘Quantity. Type’ is Quantity

Note: The section covered by this requirement is 4.2.4, rule CTN5 and STD2. See also #1950. 

1700 Element name of the ABIE LAD F Clarity 

Description: Element name of an ABIE must follows the type to which it bounds with the ‘Type’ suffix omitted. Fo

‘Transport_ Equipment Seal. Details’ would have an element name TransportEquipmentSeal. 

Note: The section covered by this requirement is 4.3.1, rule ELN1. 

1750 Element name of the ASBIE LAD F Clarity 

Description: An ASBIE does not have its own complexType, rather it is an association between an element and c

represents the corresponding ABIE). The element name associated with an ASBIE must be its DEN Property Term Object Class Term and Qualifiers of its associated ABIE. All separators must be removed. Redundant words in the qualifiers and the associated ABIE Object Class Term and Qualifiers must be dropped. For example, an ASBIE ‘PeAddress’ is associated with the ABIE ‘US_ Address. Details’. The corresponding global element name of the ASBI

Note: The section covered by this requirement is 4.3.3, rule ELN4. This test will be performed based on the DEN p

documentation. There is no example provided in the UBL guidelines. It is formulated in this document. The truncat

‘Address’ in the example. 

24
NISTIR 

1800 Attribute name LAD F Clarity 

Description: Use of attribute is very restricted in UBL. Attribute is used restrictively with the Supplementary Compa UBL attribute name must be the Property Term and Representation Term of the DEN of one of the Supplementary separators omitted. For example, the CCT ‘Quantity. Content’ would have attributes such as unitCode, unitCode

unitCodeListAgencyID, and more. 

Note: The section covered by this requirement is 4.4, rule ATN1. Not all Supplementary Components need to map 

Either the example given in UBL is wrong or the DENs of the Supplementary Component given in the CCTS versio

CCTS, the ‘Unit’ is not part of the Property Term, so it should not be part of the UBL attribute name. See also #255

1850 Anonymous type LAD F Extension, Maintenance (v

Description: All types must be named. Note: The section covered by this requirement is 5.1.1, rule GTD1. This is equivalent to OAG recommendation #15type. 

1900 Typed by xsd:any LAD F Interoperability 

Description: The type, xsd:any, must not be used. 

Note: The section covered by this requirement is 4.1.1, rule GTD2. 

1950 CCT mapping to XML Schema construct LAD P Extensibility 

Description: Generally, CCT must be mapped to the complexType construct with attributes reflecting its Supplem

However, if the Supplementary Components is already encapsulated by the XML Schema’s built-in data type, then a simpleType. For example, the CCT ‘Date Time. Content’ which has ‘Date Time. Format. Text’ as a Supplement

both the Content and Supplementary Components to the xsd:dateTime XML Schema data type. CCT complexTy

xsd:simpleContent, which is an extension of the XML Schema built-in data type for its Content Component. Th

Components that are represented by xsd:attribute must be associated with XML Schema built-in data type or u

xsd:simpleType. The user-defined xsd:simpleType must only be used when it is based on UBL standardized c

either optional or required must be specified in the schema for all the Supplementary Components. 

Note: The section covered by this requirement is 5.1.2, 5.1.3.4, and 5.1.3.5, rule STD1, CTD9 (both rule are the samCTD12, CTD13, CTD14, and CTD15. See also #1650, #2250. The test coverage is partial because the test case can

whether the Supplementary Component should be a simpleType or a complexType. The example given on line 2

uses xsd:restriction instead of xsd:extension. 

2000 CCT and xsd:restriction LAD F Model validity 

Description: CCT should not be constructed in XML Schema using xsd:restriction based on xsd:simpleTy

Note: The section covered by this requirement is 5.1.2, rule STD3. 

25
NISTIR 

CCTS constructs mapping to the 

complexType

2050 LAD U Extensibility 

Description: Certain types of Core Component constructs must be mapped to complexType with a name.

Note: The section covered by this requirement is 5.1.3, rule CTD1. This rule is still fluid. The rule says that all clas

complexType constructs, but there is a comment indicating that that is not always the case. 

2100 ABIE mapping to XML Schema construct LAD P Extensibility 

Description: Every corresponding xsd:complexType definition of a ABIE must use the xsd:sequence element 

element references, or local element declarations in the case of ID and Code, to reflect each property of its class as d

corresponding UBL model. Note: The section covered by this requirement is 5.1.3.1, rule CTD4. If assume that the test case does not linked to the testability is partial. The test case will only validate that the ABIE uses the xsd:sequence and relies on the ann

the schema itself to recognize that the construct is an ABIE. 

2150 BBIE mapping to XML Schema construct LAD F Extensibility 

Description: Every BBIE xsd:complexType definition content model must use the xsd:simpleContent eleme

xsd:simpleContent element must consist of an xsd:extension element. The base for extension must be deri

Primary Representation Term or from the data type of the Secondary Representation Term. Note: The section covered by this requirement is 5.1.3.2 rule CTD5, CTD6, and CTD8. This extension is a re-nami

Representation Term maps to complexType

2200 LAD F Extensibility 

Description: An xsd:complexType must be defined for Primary as well as Secondary Representation Term. 

Note: The section covered by this requirement is 5.1.3.3, rule CTD2 and CTD3. The test case would check that if ththe term is a Primary/Secondary Representation Term then the xsd:complexType must be used. The rule CTD3 is 

2250 ABIE and BBIE element declaration LAD F Extensibility 

Description: Classes in UBL model (i.e., ABIEs) must be defined as global elements bound to their corresponding 

Note: The section covered by this requirement is 5.2.2, rule ELD3. The test case would assume that classes mean A

26
NISTIR 

2300 Use of the CCT XML Schema construct LAD F Model validity 

Description: xsd:simpleType and xsd:complexType constructs of CCTs must only be bound to elements that 

Component (BCC) or Basic Business Information Entity (BBIE). Note: The section covered by this requirement is 5.2.2, rule ELD4. This rule does not seem to match with #2150, w

has its own xsd:complexType definition which is an extension of the CCT. Hence, the BBIE does not need to ass

CCT schema type definitions. This rule is still fluid. 

2350 ASBIE element declaration LAD F Model validity, Extensibil

Description: A global element based on ASBIE must be declared bound to the associated ABIE xsd:complexType 

Note: The section covered by this requirement is 5.2.2,1 rule ELN3. The rule name should be changed to ELDx (an 

2400 Elements bound to CCT LAD F Model validity 

Description: For each CCT xsd:simpleType, an xsd:restriction element must be declared. 

Note: The section covered by this requirement is 5.2.2.3, rule ELD5. This rule enforces a grammatically ambiguous 

xsd:restriction cannot appear by itself. It also conflicts with #2000, which indicates that xsd:restriction 

2450 Code list import LAD F Model validity 

Description: The code list xsd:import element MUST contain the namespace and schema location attributes. 

Note: The section covered by this requirement is 5.2.3, rule ELD6. 

2500 Empty element LAD F Interoperability 

Description: Empty element must not be declared in an XML schema. Note: The section covered by this requirement is 5.2.4, rule ELD7. 

2550 User-defined attribute LAD F Extensibility 

Description: User-defined attribute should not be used. When used, it should only convey the CCT Supplementary Note: The section covered by this requirement is 5.3.1, rule ATD1. See also #1800. 

2600 Global attribute LAD F Model clarity 

Description: If a UBL xsd:SchemaExpression contains one or more common attributes that apply to all UBL el

included or imported therein, the common attributes must be declared as part of a global attribute group. If the CCTComponent xsd:attribute is common to all UBL elements, it must be declared as part of the XML schema glob

Note: The section covered by this requirement is 5.3.2, rule ATD2 and ATD3. 

27
NISTIR 

Supplementary component attribute declaration 

2650 LAD P Model validity

Description: For the CCT schema construct that uses xsd:extension element, the xsd:extension element mu

declared for each of its Supplementary Component. However, for those CCT XML Schema constructs that are base

xsd:simpleType, an xsd:base attribute must be declared and set to the appropriate xsd:datatype. 

Note: The section covered by this requirement is 5.3.3, rule ATD3, ATD4, and ATD5. The test coverage is partial bnot testable. The test case cannot determine whether an appropriate xsd:datatype is used to define the Suppleme

2700 Schema location LAD F Model validity 

Description: The xsd:schemaLocation attribute must contain a persistent and resolvable URL. The URL must 

Note: The section covered by this requirement is 5.3.4, rule ATD7 and ATD8. Although this rule is testable, the res

2750 xsd:nil attribute LAD F Interoperability 

Description: The XML Schema built-in nillable attribute (xsd:nil) must not be used for any declared UBL eleme

Note: The section covered by this requirement is 5.3.5, rule ATD9. 

2800 xsd:any attribute LAD F Interoperability 

Description: The xsd:any attribute must not be used. 

Note: The section covered by this requirement is 5.3.6, rule ATD10. 

2850 Code list creation and maintenance L NA Reusability 

Description: All UBL Codes must be part of a UBL or externally maintained Code List. The UBL Library should i

standardized code lists rather than develop its own UBL-native code lists. The UBL Library MAY design and use a

existing external code list needs to be extended, or where no suitable external code list exists. If a UBL code list is c

globally scoped (designed for reuse and sharing, using named types and namespaced Schema Modules) rather than designed for others to use and therefore hidden from their use). All UBL-maintained or used Code Lists must be enu

Code List Schema Module. Note: The section covered by this requirement is 6, rule CDL1, CDL2, CDL3, CDL4, and CLD5. These are code li

than design rules. 

2900 UBL Code list schema module name L P Structural clarity 

Description: The name of each UBL Code List Schema Module must be of the form: {Owning Organization}{CodSchema Module} Note: The section covered by this requirement is 6, rule CDL6. The partial test coverage is given for this requireme

necessary for the test may not be available, i.e., the test case would need to ask the user for Owning Organization, C

28
NISTIR 

2950 UBL Code list has its own namespace L P Extensibility 

Description: An xsd:import element must be declared for every code list required in a UBL schema. 

Note: The section covered by this requirement is 6, rule CDL7 and NMS19. This requirement can also be interprete

must has its own unique namespace. The test coverage is partial because the test case many not be able to fully veri

uniqueness. 

3000 UBL Code list namespace pattern L F Model validity 

Description: The namespace of UBL code list schema module must conform to this pattern - urn:oasis:ubl:codeLisIdentifier>:<Code List. Name. Text>:<Code List. Version. Identifier>:<Code List. Agency. Identifier>:<Code List. 

Agency Identifier must be derived from UN/EDIFACT Data Element (DE) 3055 [24]. However, roles defined in DE The token comprising the namespace must adhere to these rules: (1) Not white space, (2) Use only characters in the 

special character, (3) If the version identifier has minor version identified, the minor version must be separated from 

period (.). Note: The section covered by this requirement is 6, rule CLDX, CLDXX. 

3050 UBL Code list importation LAD F Validation and model clar

Description: When UBL code list is imported, the xsd:schemaLocation attribute of the xsd:import statement 

URI identifying the code list schema. Note: The section covered by this requirement is 6, rule CLDXXX. That URI is the namespace.

3100 Maximum use of xsd:simpleType L NA Interoperability

Description: The xsd:simpleType should be used as much as possible. 

Note: The section covered by this requirement is 7.1, rule GXS3. 

3150 W3C schema namespace abbreviation LAD F Structural clarity 

Description: The ‘xsd’ must be used as namespace abbreviation for the W3C meta-schema. That is the following m

xsd:schema element “xmlns:xsd="http://www.w3.org/2001/XMLSchema””. 

Note: The section covered by this requirement is 7.2, rule GXS4. 

3200 No xsd:substitutionGroup LAD F Interoperability 

Description: The xsd:substitutionGroup is inconsistent the UBL guiding principle; hence, it must not be used

Note: The section covered by this requirement is 7.3, rule GXS5. 

29
NISTIR 

3250 The xsd:final LAD NA Extensibility 

Description: The xsd:final attribute must be used to control the extension. 

Note: The section covered by this requirement is 7.4, rule GXS6. The testability is not possible, because it is not poxsd:final should be used. 

3300 No xsd:notation LAD F 

Description: The xsd:notation data type must not be used. 

Note: The section covered by this requirement is 7.5, rule GXS7. 

3350 The xsd:all LAD F Interoperability 

Description: The xsd:all element must not be used. The semantics of the xsd:all element is inconsistent with t

scenarios/transactions. Note: The section covered by this requirement is 7.6, rule GXS8. 

3400 The xsd:choice LAD F Interoperability 

Description: The xsd:choice element compositor must not be used. 

Note: The section covered by this requirement is 7.7, rule GXS9. 

3450 The xsd:include LAD F Model validity 

Description: The xsd:include element must only be used in the Control Schema to avoid circular reference. 

Note: The section covered by this requirement is 7.8, rule GXS10. See also #850. The test case would identify a Co

Internal Schema from their namespaces.

3500 The xsd:union LAD F Extensibility 

Description: The xsd:union must be used only with Code List. 

Note: The section covered by this requirement is 7.9, rule GXS11. The test case would identify a code list from its n

3550 The xsd:appinfo LAD F Interoperability

Description: The xsd:appinfo can cause security threat. Hence, UBL only recommends using it for non-normati

information for the purpose of wider interoperability. Note: The section covered by this requirement is 7.10, rule GXS12. The test case will warn of any use of xsd:app

the information specified in order to obtain the full test coverage. 

30
NISTIR 

The xsd:extension and 

xsd:restriction

3600 LAD NA Extensibility

Description: The xsd:extension and xsd:restriction may be used where appropriate. 

Note: The section covered by this requirement is 7.11, rule GXS13. The testability is not possible, because it is not 

the two elements are appropriate. 

Note:

Requirements in The section 3.6.4 have not been extracted, because it is uncertain right now whether we need to test these core stan

do not evolve that much, it is not worth to write test requirements and test cases.Rule GXS2 in The section 3.7.2 has not been extract. It indicates that two versions of schema must be provided by UBL, one is a fuother is run-time schema which has all documentation stripped out. It is expected that only the fully annotated version will be tested 

because the run-time schema can be automatically generated from the fully annotated schema.Rule GNR5, GNR6, GNR7 in The section 4.1, which talks about creating and maintaining the list of allowable abbreviations and acextracted. Rule CTD7 in The section 5.1.3.2, this rule is already captured by the XML schema grammar itself. Rule CDL8 in The section 6, this is a usage recommendation rather than a schema design rule. 

31
NISTIR 

11. XML.GOV Developers Guide 

ID Test Requirement Schema type Test Coverage Ratio

50 Naming convention LAD P Common symbolic syntax

Description: The camel case convention should follow the one defined in the ebXML technical architecture docum

names should use the UpperCamelCase convention. Attribute name should use the lowerCamelCase convention. Note: The section covered by this requirement is 3.1. 

100 Acronym and abbreviation usages LAD F Structural clarity 

Description: The summary of this guideline includes (1) acronym should not be used, when used should be in uppeshould not be used, (3) the acronym used must be expanded in the xsd:documentation tag, (4) the underscores ( 

( - ) must not be used. Note: The section covered by this requirement is 3.2. 

150 Use of ISO 11179 data element definition LAD F Structural clarity 

Description: The XML element, data type, and attribute names should follow the ISO 11179 part 5 conventions [25

Property Term. Representation Term. The guidelines recommend that the ISO 11179 name be concatenated accordithe element/type, and to lowerCamelCase for the attribute. Note: The section covered by this requirement is 3.3.2. 

200 Meaningful component name LAD NA Structural clarity 

Description: This is a recommendation for the process to come up with a meaningful name. Note: The section covered by this requirement is 3.3.3. Although trivia test can be performed, for example, to detec

prepositional phrase, it is very difficult, if possible at all, to test whether the name is sufficiently meaningful. Hence‘NA’ with the test coverage. 

Schema conformance to W3C standard or DTD conformance to ISO 8879 

250 LAD F N/A 

Description: This requirement is considered outside of the boundary of the schema design quality. It is put here for The requirement, in fact, also includes the recommendation to transition to the XML schema from DTD. However, the transition is arbitrary and is not testable. Note: The section covered by this requirement is 4.1. Generally, any schema or DTD should conform to these two s

32
NISTIR 

300 Schema development methodology LAD NA Validation and model clar

Description: The guideline recommends object-oriented modeling (in place of relational model) of business proces

methodology to drive the schema development. The schema development should be a team effort involving the dom

and the manager. Note: The section covered by this requirement is 4.2. This requirement is not testable because the recommended moarbitrary effect to the resulting schema structures (i.e., the methodologies do not signify schema best practices). 

350 Capturing metadata LAD P Validation and model clar

Description: The guideline recommends that metadata be recorded as much as possible in the schema using the annother schema constructs) and in the DTD using comments. Optionally, a separate guideline document may replace t

addition, two versions of a schema may be created, a verbose one with all the annotations and a lean without any anpurpose. Note: The section covered by this test requirement is 4.3. Note that this test requirement is subjected to quite limite

metadata can be checked for each element. However, other types of metadata can be check in a limited way. OAGIS of weak typing, can be considered as part of this requirement. In fact, requirements falling into the validation and mbe considered part of this requirement. 

400 Capturing application specific metadata LAD P Interoperability 

Description: An XML payload should not be used to capture the programming statements/expressions. It may capt

parameters but this should be in a physically separate file from the business payload. Note: The section(s) covered by this test requirement is 4.3.1. The conformance to this test requirement can be bette

account sample instances. The test coverage is partial because it may not be possible to detect all programmatic patt

450 Capturing XML component definition LAD F Interoperability 

Description: All type definitions and element declarations must have a definition specified in the annotation tag. Uinformation may be specified. An extension to the documentation tag is a recommended way to associate this informNote: The section covered by this test requirement is 4.3.2. This requirement is a child of the requirement #350. Th

specifying this information. Until then, the full test coverage means that all type definitions and element declarationannotation child element. 

33
NISTIR 

500 Enumerations L P Validation and 

Description: Stable code lists should be enumerated in the schema. Unstable code list should be annotated with UR

documentation. Note: The section covered by this test requirement is 4.3.3. The test coverage is partial because it may not be possibfields that should be enumerated. See also OAGIS requirement #350 and NIST B2B Testbed requirement #300. A two test requirements can be taken to verify the conformance (using a code list reference table) to this requirement. 

550 Version documentation in DTD LAD F Interoperability, Mainten

Description: In a DTD, the version number should be specified in the first comment or as a fixed attribute in the ro

Note: The section covered by this test requirement 5.1.1. 

600 Version documentation in Schema LAD F Interoperability, Mainten

Description: In an XML schema, the version number should be specified using the version attribute of the xsd:sc

Note: The section covered by this test requirement is 5.1.2. Using this versioning approach, the schema version assomay not be evident, unless a target schema version is specified in the instance. This is similar to the requirement in associated schema version must be specified in the stylesheet. This requirement is not documented here because it i

schema design quality. See also Roger Costello XML Schema Versioning [8].

650 Element Vs. Attribute LAD P Model validity, Structural 

Description: Attributes should be used to convey metadata to understand the business value associated with the ele

contain a long string value but rather token or number types of values. Attributes should describe information units 

subdivided or extended. Attributes should contain metadata that is applicable to the whole element’s content. Puttin

metadata in the attribute will result in ambiguity about which one is the metadata and vice versa. A long string valuwhite space truncated by the parser. Note: The section covered by this test requirement is 6. This test requirement cannot be effectively verified with sch

Instance data would allow reasoning based on evidence about whether the attribute construct is used according to th

34
NISTIR 

12. KIEC XML Guideline 

ID Test Requirement Schema type Test Coverage Ratio

50 XML tag names should follow ISO 11179 LAD P Common symbolic syntax 

Description: Check that the (element) tag names conform to the ISO 11179 recommendation. Generally, ISO 1117

example, an element name must start with capital letter, an attribute name must start with a lower case letter, names 

singular form unless looping is required, and names should use only Verb, Noun, or Adjective. Note: The sections covered by this test requirement are 2.1.1, 2.1.7, 2.1.11, and 2.1.12. The section 2.1.10 states thaare used by XML library, should be unique. This can be difficult for an XML designer. Typically, only global elemwithin a single namespace. The schema validators may not detect this issue. Preliminary experiment indicates that tthis issue, while the Xerces [17] does not. Similar to the test requirement #200 in the GCSS-AF guide, the test covepartial because the name may or may not be parsed into separate substrings correctly and words have multiple functof false alarms and some false positive. 

100 UID assignment range LAD P Structural clarity 

Description: KIEC recommends ranges of UIDs associated with the level of information construct. See the table in guideline. Note: The section covered by this test requirement is 2.2.2. In order to verify this requirement, the test must be able XML schema to the construct in the ebXML Core Component hierarchy of constructs. For example, identify which is Basic Business Information Entity, or Basic Core Component. The current version of this document quantifies the requirement as partial because it is uncertain whether such mapping can be done precisely (unlike UBL it is annotat

150 UID incremental sequence LAD P Structural clarity 

Description: (a) UID is assigned alphabetically for each layer. In case a new information entity is added, a number, 

the before and after the new entity, is assigned. (b) For composite Business Information Entities (BIEs), UID is sequthe composite core component to which the composite business information elements refer. (c) For messages of domelectronic documents, UID is first classified based on business process and then assigned sequentially in units of 10

UID is assigned by adding 5 sequentially to the message number. (d) In case UID is assigned by developing new incomponents, or updating existing components, the assignment must be made in consultation with KIEC. Note: The sections covered by this test requirement are 2.2.3, 2.2.4, 2.2.5, 2.2.6. The test coverage is partial. The re

by creating an alphabetical ordering of the terms and verifying the sequential numbers. The requirement in (b) is tesbetween the BIEs and their corresponding Core Component can be identified. The requirements in (c) and (d) are no

we have to pay versus its value could make this requirement not worthwhile to test. 

35
NISTIR 

200 UID uniqueness LAD F Interoperability 

Description: All XML elements in the XML schema can have an associated Id attribute. According to XML schem

parser should check for the Id’s uniqueness. However, that validation is limited to a single file. This test requiremenuniqueness across schemas included in a standard. Note: Note that all schemas included in a standard must be supplied for the test coverage to be full. 

250 Use of default namespace LAD F Structural clarity 

Description: Default namespace (no-prefix) can be assigned to either the XML schema namespace (option 1) or the 2). Note: The section covered by this test requirement is 2.3.1. KIEC indicates that the advantage of option 2 is that it anamespace schema to be created. However, this generally is not a good practice for standard development. The disadescribed by KIEC is indicated as a good practice in OAGIS because it differentiates the elements in the same namenamespace (without prefix) from elements in imported namespaces (with prefixes). KIEC describes that the advantareverses the disadvantage in option 2 (i.e., all referenced elements have prefixes). As stated earlier, the disadvantage advantage by others. Then KIEC indicates that the disadvantage of option 1 is that a no-target-namespace schema coption. Again, other organizations suggest that the no-target-namespace schema generally should not be used. How

standards including OAG, XML Common Business Library (xCBL) [26], and Open Travel Alliance (OTA) [26] usoption 2 is viewed as the best practice for the default namespace usage. 

300 Extension LAD P Maintainability

Description: Extension should be done with these principles. (a) The extension should be compatible with others. be done without much extra effort. (c) The user-defined extension should eliminate the need for any core XML sche

should not be dependent on any of those files. (d) Any extension to the current standard should be done in new namNote: The section covered by this test requirement is 2.4.2. The test coverage is partial. The principle in (a) is too v

generation. The principle in (b) could be linked to other test requirements associated with Maintainability rationale regression in the #250 of the OAGI table. The principle in (c) may be checked by verifying the differences between standard specification and the standard specification used by a user. This will notify the user of any unexpected mod(d) can be tested. 

350 Use of UserArea extension LAD F Interoperability 

Description: The UserArea extension is not recommended. The UserArea extension may be viewed as any element 

with the XML Schema data type any, which allows any arbitrary well-formed XML content to be specified. 

Note: The section covered by this test requirement is 2.4.3. This test requirement maybe suitable for only Business-

standards because in the Application-2-Application (A2A) integration there are typically needs for such arbitrary ex

36
NISTIR 

400 Allowable plural tags LAD F Structural clarity 

Description: KIEC at the present allows 12 plural components including Addresses, Attachments, Contacts, DocumDocumentReferences, Locations, Parties, PartyReferences, Prices, Properties, Ranges, and Taxes. Note: The section covered by this test requirement is 2.5.4. There are two interpretations associated with plural formB2B Testbed recommendation #700. The interpretations associated with these terms are not documented in this ver

500 Controlled object class term LAD F Structural clarity 

Description: KIEC defines controlled-object-class terms including Container, Delivery, Location, Message, Order, 

Party, PaymentTerms, Person, Price, Project, Quote, Shipment, Tax, Transaction, Transportation Note: The section covered by this test requirement is 3.2.6. These are quite a limited set of terms comparing with N

defined in OAGIS. 

550 Identifier design pattern LAD P Interoperability 

Description: This guideline recommends an item identifier, document identifier, document reference identifier, cla

Note: The sections covered by this test requirement are 3.3.5, 3.3.6, 3.3.7, and 3.3.8. See also #250 in the NIST recoitem identifier, document identifier, and classification code schemes have the same pattern, which require containerorganization and revision numbers in addition to the code/id itself. The document reference identifier pattern has do

description, name, status, usage, and note. The test coverage is partial because the test case may not be able to recogshould follow these patterns. 

600 Item property design pattern LAD P Interoperability 

Description: KIEC recommends an XML structure for representing item property derived from IMD segment of EDrecommendation translates into a requirement that any recognized Item or object element having a pattern of arbitrafollow the recommended property pattern. Note: The section covered by this test requirement is 3.3.9. The recommended pattern is a plural ‘properties’ eleme

property elements. The property element contains property value, description, effective period, UOM, qualification, user area. The test coverage is partial because it may not be possible to detect all elements pertaining to this pattern. 

37
NISTIR 

650 Item design pattern LAD P Extensibility, Interoperab

Description: KIEC recommends an XML structure for representing an item component. This recommendation tranthat concepts similar to the Item component follow this pattern. Note: The section covered by this test requirement is 3.3.10. This requirement seems to be inconsistent with the reqis not included in the controlled object class term. It is also inconsistent with the requirement #400 because it contai

not listed as allowed plural tags. The item pattern should contain item id, status, name, commodity name, class ids, 

definition, serial number, parent serial number, material details, lot details, attachments, and user area. The test covemay not be possible to detect all elements pertaining to this pattern.

700 Transportation unit design pattern LAD P Extensibility, Interoperab

Description: KIEC recommends an XML structure for representing a physical container/shipment unit. This recomrequirement that concepts having similar or same semantics as a physical transportation unit, e.g., packaging in OAlisted in this pattern. Note: The section covered by this test requirement is 3.3.11. This requirement maps to the Packing, a controlled objrequirement #500. The transportation unit pattern should contain container Id, sealed container Id, container type, fr

tracking number, material, sequence identification, shipper cost, total Id of freight, temperature of the transportation unit, shipping note associated with the unit, charges, and document references. The test coverage is partial because detect all elements pertaining to this pattern.

750 Transportation information design pattern LAD P Extensibility, Interoperab

Description: KIEC recommends an XML structure for representing information about transportation (transit inform

recommendation translates into a requirement that any information entity (e.g., shipment) seeking to indicate its rou

should contain information identified in this pattern. Note: The section covered by this test requirement is 3.3.12. This requirement maps to the Transportation, a control

requirement #500. Note an inconsistency with the requirement #400, the ‘ShippingInstructions’ is not an allowed plcontains a ‘UserArea’ element, which is inconsistent with the requirement #350, which discourages the use of the U

transportation information pattern should contain Id, mode and means of transportation, date time of the transportaticarrier information, transit direction, service level, shipping instructions, route taken, location, transportation equipm

extension. The test coverage is partial because it may not be possible to detect all elements pertaining to this pattern

38
NISTIR 

13. ASC X12 Reference Model for XML Design 

ID Test Requirement Schema type Test Coverage Ratio

50 Versioning LAD F Maintainability, Interoper

Description: This guideline recommends the use of a unique name space for each release. Note: The section covered by this test requirement is 7.1.2. Although it is technically possible to test conformance t

previous schema releases must be provided in order the make the conformance absolute. The question is whether all schemas use the new namespace regardless of whether there are changes from the previotake a holistic interpretation. However, when components are maintained individually in the schema this practice maddition, if components are flagged as changed without in fact any changes, this practice could confuse developers resulting in increasing software maintenance cost. 

100 Spelling LAD P Structural clarity, Commo

Description: Oxford English is recommended for validating the terms used. Note: The section covered by this test requirement is 7.1.3. The test coverage is partial under the assumption that te

parsed and validated with the dictionary.

125 Size of document LAD NA Performance 

Description: Due to concern about the memory usage in software that load the whole document into the memory, it 

document be of a reasonable size. Note: The section covered by this test requirement is 7.1.4. Since the requirement is specified without quantifiable i

requirement is not testable. 

150 Deepest level of nested elements LAD F Performance

Description: The guideline recommends that the deepest level of child element should be in the neighborhood of 10 Note: The section covered by this test requirement is 7.1.4. The test coverage is determined to be full if the recomm10. This practice may not affect the software performance directly, but rather indirectly from the time necessary to i

deep data structure. 

39
NISTIR 

200 Naming convention LAD P Structural clarity, Commo

Description: UpperCamelCase is to be used for element and lower camel case is to be used for attribute. It also recnaming conventions as specified in the section 4.3 of the ebXML Technical Architecture V1.0.4. Note: The section covered by this test requirement is 7.1.5. The requirement only indicates the naming convention fhence, the respective test cases will ignore the type definition naming. The test coverage is indicated as partial beca

able to perfectly parse the name and checking for conformance. 

250 Verbose attribute name LAD F Performance, Structural c

Description: An attribute name should not contain name(s) of parent element(s). If applying the attribute from with

then the contextual value of the attribute name should be contained within the attribute name. An attribute can be vielement (which is a noun). This can result in a rule that attribute name must be an adjective. Note: The section covered by this test requirement is 7.2.5, under the “Benefits of using Attribute” subsection. Sincwithin an AttributeGroup may contain contextual value (e.g., name of the parent element), the attribute names w

will not be checked. 

300 Use of namespace LAD F 

Description: Hierarchical namespaces are recommended. A single namespace holding all common terminologies asubcommittees (or other logical grouping) is recommended. A single namespace should be used for each functional 

ambiguous to whether the document level schema is recommended to have its own namespace or to have the same nfunctional subcommittee. Note: The section covered by this test requirement is 7.3.11. This test requirement suggests that a no target namespused and all schemas should have a target namespace. In order to verify the compliance to this test requirement, the type of schema -- core, subcommittee, or document. Hence, the test coverage is full only if all necessary informatio

350 Processing instruction LAD F Interoperability 

Description: Processing instructions should not be used both in schema and in instance documents. The rationale is instruction usually contains information that should normally be included in the XML data. Note: The section covered by this test requirement is 7.2.8. Rather than using processing instruction, such informati

the XML data structure itself. 

400 String type element design pattern LAD F Validation and model clar

Description: A required element of type string should be defined with a restriction to have at least one character. 

Note: The section covered by this test requirement is 7.3.2. Normally, XML schema considers any Unicode charact

a white space). X12 is still discussing whether to require that the one character to be non-white-space. In fact, this c

to optional element, because the constraint should be activated whenever the element is present. That is, it should ap

string, unless the element is nillable. 

40
NISTIR 

450 Non-nillable required element LAD F Model validity 

Description: Mandatory element should not be nillable. Note: The section covered by this test requirement is 7.3.2. 

500 Nillable optional element LAD F Model validity 

Description: Optional element (minOccur =0) shall be declared nillable. Note: The section covered by this test requirement is 7.3.2. 

550 String type attribute design pattern LAD F Validation and model clar

Description: A required string typed attribute should be defined with a restriction to having at least one character. 

Note: The section covered by this test requirement is 7.3.2.See also #400. 

600 Use of the mixed content LAD F Validation 

Description: Mixed content should not be allowed in documents designed solely for data exchange. Mix content aland child elements to appear. In this case, the textual content cannot be validated or constrained to a particular data Note: The section covered by this test requirement is 7.3.3. A ‘Description’ element may be used in place of the mi

650 Use of the wildcard element and attribute LAD F Model clarity and validati

Description: The recommendation is not to use the any element or anyAttribute attribute. The rationale is that t

be inserted. The moderate recommendation is also that the entities instantiated under the any or anyAttribute sh

namespaces (than the one in the target namespace). Note: The section covered by this test requirement is 7.3.3. The moderate recommendation suggests that whenever 

xsd:anyAttribute is used as type of element, a namespace attribute should be used and that the attribute value ##local. 

700 Use of the abstract types LAD F Model clarity and validati

Description: The recommendation is not to use the abstract type -- although it suggests that such functionality may constraint to be at least one-of. The document cites that this feature makes the instance document ambiguous to whaexchanged. Note: The section covered by this test requirement is 7.3.3. This is analogous to the OAGIS use of substitution

still uses the abstract type to indicate the intention that such type is not instantiable (not as at-least-one-of constraint

be a preferred method. The testability is indicated as full with the assumption that the abstraction type should not be 

41
NISTIR 

750 Use of the group feature LAD F Model clarity and validati

Description: Although the uses of complex type group and attribute group promote reuse, the document argues that 

complicate maintenance. In addition, the functionality of the group feature is very similar to that offered by the type 

recommendation is not to use the group feature at all and instead defines as many types as necessary.Note: The section covered by this test requirement is 7.3.3. Although the recommendation to avoid using too many 

understandability is sound, the rationale that reuse can complicate maintenance is unclear and is counter-intuitive. 

850 Group and Type redefinition LAD F Maintainability 

Description: The group redefinition feature allows the ‘group’ or ‘type’ definition to be redefined. Since the whole 

redefined, this can affect other dependencies (e.g., extension). The document also argues that this functionality is unSchema specification. The recommendation is not to use the redefinition functionality. Note: The sections covered by this test requirement are 7.3.3. and 7.3.4. This is called feature regression in the OAG

redefinition has to repeat the whole content model. See #250 in OAGIS table. 

800 Substitution Groups LAD F Structural clarity 

Description: The substitution group allows the content model to be flexible. Elements can be declared a substitute fThose elements can appear wherever the head element appears in the content model. The document argues that the f

model to be excessively flexible in that anybody can alter the content model substantially using this feature. Conseqsubstitution group is not recommended. Note: The section covered by this test requirement is 7.3.3. This is conflicting with the OAGIS extensibility guideliuse of substitution group to declare extension at design time rather than using the xsi:type. 

900 Type definition LAD F Extensibility 

Description: The document recommends the use of named type (i.e., global type) instead of the anonymous type (i

Note: The section covered by this test requirement is 7.3.4. This recommendation is the same as that of OAGIS desrecommends the use of globally defined type. See #150 in OAGIS table. 

1000 Type derivation LAD F Extensibility 

Description: The document recommends that type derivation based on restriction and extension be allowed

Note: The section covered by this test requirement is 7.3.4. Test cases generated for this test requirement may verify 

does not have the finalDefault attributed defined and that type definitions do not have the attribute final defin

This requirement is less restrictive than the OAGIS recommendation. OAGIS recommends that type restriction be udue to feature regression associated with restriction on complex type. See #250 in OAGIS table. It also relates to #8

42
NISTIR 

950 Built-in simple type LAD NA Interoperability 

Description: The document recommends that built-in simple types defined by XML schema specification should be 

these types should be used as will be defined in X12’s XML equivalent of X12.6. Note: The section covered by this test requirement is 7.3.4. The requirement is not possible to test because it may nwhich type definition should override the built-in simple type. In addition, the XML equivalent of X12.6 data type hThis requirement is opposite from the OAGIS recommendation that the built-in schema simple types as weak typing

used in the aggregate and document level schemas. 

1050 Type substitution LAD F Interoperability 

Description: Type substitution feature allows base types to be replaced by derived types. The document argues that 

for to an application processing an instance document in which an unknown derived type is used. Therefore, type su

disallowed. Note: The section covered by this test requirement is 7.3.4. The test cases derived from this test requirement will ei

xsd:schema element has an attribute blockDefault equals #all or that all type definitions have an attribute bl

1100 Locally defined element and attribute LA F Maintainability 

Description: The document recommends that elements and attributes be locally defined except the root element. Thglobal element and attribute can create name-clashing problem, although they are more extensible and reusable. 

Note: The section covered by this test requirement is 7.3.5. This requirement is different from the OAGIS practice. elements to satisfy its favored substitutionGroup extensibility mechanism. See #300 of OAGIS. It is also oppo

requires that all elements are global. 

1150 Use of default or fixed value LAD F Interoperability 

Description: The default value feature used with attribute or element can present problems when a schema is not pr

to obtain the default value from the schema). The recommendation is to disallow these two features. Note: The section covered by this test requirement is 7.3.6. There are different processing behaviors associated with element default. The processor assigns a default value to the attribute when the attribute is not present at all in the inother hand, the processor assigns default value to the element when the element appears with empty content in the ddoes not appear then it is null. 

43
NISTIR 

1150 Uniqueness constraint LAD F Interoperability 

Description: The document describes three different features of similar functionalities (linking entities and uniquen

with IDREF, Key/KeyRef with Uniqueness, and XLink with XPointer. The document recommends the Key/KeyRenow. The rationale is that the ID/IDREF has major limitations including the strict format of the ID value, which mu

must be alphanumeric character except underscore. In addition, the ID values have to be unique for all elements and document. XLink and XPointer are relatively immature and inherit some limitations from the ID/IDREF. Key can b

of a customer can be the same as Key/ID of an invoice). The uniqueness constraint of Key can be specified with resattribute. Note: The section covered by this test requirement is 7.3.7. Two caveats associated with the Key/KeyRef feature ar

may not validate the XPATH expressions in the xsd:field and xsd:selector field. In addition, when the uniqu

required the element or attribute specified in the xsd:field must be mandatory. Test cases for this requirement sh

two caveats. 

Use of the xsd:annotation vs. the XML 

comment 

1200 LAD F Structural clarity 

Description: Although the document argues that extensive use of the xsd:annotation can reduce the schema rea

processing time, use of the xsd:annotation element is recommended for all type definition for clarity. It also rec

and structure of the annotation follow the meta-data described in Section 6 of the guideline. Use of XML comment Note: The section covered by this test requirement is 7.3.8. Use of the xsd:annotation element is good because 

application and XSLT. Test cases associated with this test requirement will flag any use of XML comment. 

1250 Use of the Notation LAD F Interoperability 

Description: Since there is no standard way to process a ‘Notation’, use of the ‘Notation’ can cause interoperability 

discouraged. Notation indicates the type of external files associated with the XML document. The document argues know how to process the file anyway; consequently, the Notation is deemed unnecessary.Note: The section covered by this test requirement is 7.3.8. The argument about the unessential of the Notation may 

Although the application needs to know how to process the file, it needs to know first what type of file it is and that 

(as analogous to the MIME type). 

Use of the xsd:documentation vs. the 

XML Comment 

1300 LAD F Structural Clarity 

Description: Use of the xsd:documentation element is recommended. This is similar to the requirement #1200. 

xsd:documentation element is a child element of the xsd:annotation element. 

Note: The section covered by this test requirement is 7.3.8. Test cases associated with this test requirement will flag 

44
NISTIR 

Use of the xsd:appInfo or DTD’s 

ProcessingInstruction

1350 LAD F Interoperability 

Description: Te xsd:appInfo of the XML schema serves the same functionality as the ProcessingInstructi

xsd:appInfo is considered risky because there is no mature recommendation yet to how the XML processor will p

the application; hence, this feature is not recommended. Note: The section covered by this test requirement is 7.3.9. 

1400 Use of the Length LAD F Interoperability 

Description: The document does not recommend the use of fixed or maximum length constraint except for the case 

Note: The section covered by this test requirement is 7.3.10. Usage of the ‘Length’ facet will be rejected because of 

unless it is recognized that coded value is expected. Although the test coverage is full, a number of false positives a

45
NISTIR 

14. AEX Design Guidelines 

ID Test Requirement Schema type Test Coverage Ratio

50 Conformance to naming conventions. LAD P Validation and model clar

Description: Use of upper camel case is recommended. To ensure consistency, an upper-camel-case tag should be parsed string and ensure the validity of each substring – words, acronyms, or abbreviations—against the published table of terms

substring may be recognized as a specific acronym and ignored or checked against a list of allowable acronym. Note: See “Using AEX” The section 2.11. Along with the cfiXML specifications is a published list of the terms used incl

acronyms. Names can be parsed to verify that their component terms are included in the published list; however, in some 

be ambiguity in the parsing. A test can flag these situations, which can then be examined by a person. One convention the different from others is that an element name is lower camel case while the type name is upper camel case. 

100 Conformance to choice ordering conventions LAD F Validation and model clar

Description: Check to see that in choice or sequence lists the items are ordered alphabetically with the exception of those 

ordering” makes more sense, such as addresses. Note: See “Using AEX” The section 2.11. This requirement is only partially testable because there is no listing of excepalphabetical listings, yet the exceptions are allowed for. A tool can flag occurrences of exceptions and a person can then d

acceptable exceptions. 

150 Correct use of object references. LAD F Validity 

Description: This guideline refers to a technique for referencing objects from an XML instance document. This means t

that every object that may be referenced by another object, whether externally or internal to the XML instance data, shoul

complex type “Object.” Note: See “Using AEX” The section 2.12. The test for this guideline is really more of an aid. A program can flag types the complex type “Object,.” and a person needs to determine whether the modeling is correct. 

Use of “custom” item in sequence and choice definitions 

200 LAD F Extensibility

Description: The AEX Guidelines document recommends a mechanism for customizing sequence or choice type schema 

mechanism requires that every sequence or choice type definition include an element called “custom.” This test checks f

custom element in those definitions. Note: See “Using AEX” The sections 2.13 and 5.2c. This practice is similar to OAGI’s ‘UserArea’ element, which is a pr

not documented in its design guideline. New releases of OAGI specification intend to deprecate this practice though. 

46
NISTIR 

250 All Elements Optional By Default LAD F Clarity, Extensibility, Mai

Description: The cfiXML Schema development process calls for all elements to be optional by default. The position is tbe validated outside of the schema, as they will differ for different transactions. Note: See “XML Schema Development Guidelines” The section 5.3.9. This practice is similar to OAGI architectural prac

specification enforces a set of minimal requirements in the schema.

300 Check for improper use of anonymous type. LAD F Extensibility 

Description: Content models of an anonymous type are defined locally within an element. They cannot be referenced out

definition; hence, they cannot be reused. On the other hand, a globally defined type allows it to be referenced and hence re

Venetian Blind [7] design approach in that global types should be defined where necessary and global elements be declarcomponents. Note: This principle has yet to be documented; however, it is used in cfiXML Version 1. This practice is similar to that of 

The test of this requirement can be partially automated by flagging the use of anonymous types thereby assisting a person correctness of the usage. Since the test flags all anonymous type definitions, the test coverage value is Full.In XML schema, type definitions can be viewed as a content model, while the element definitions are viewed as documenmodel has tight relationship with functional requirements or functional model. Hence, software components should be dev

the content/data model rather than to the document structure. The content model represents entities that are used and reusecomponents developed around it can also be reused. Although the use of global types can cause name-clashing problem, the available of namespace mechanism reduces this psame term with different concepts (perhaps in different domain) can be defined in different namespaces. 

350 Global elements exist for all extensible types. LA F Extensibility 

Description: Since the cfiXML approach is based on the idea of “users” defining their own documents as needed using tthe building blocks, it is recommended that extensible, globally defined types have corresponding global elements as well

Note: This principle has yet to be documented; however, it is used in cfiXML Version 1. The test of this requirement can flagging the global types that do not have a corresponding global element. Since the test flags all global types not having a element, the test coverage value is Full. 

47
NISTIR 

15. An Example Code List Reference Table This is an example code list table that can be used to check whether the schema has taken into account the code list rather than allowUBL has also made potential code lists available as international standards; however, it does not give specific details about the intewith them. 

Data Standard (s) Note

Currency ISO 4217

Country ISO 3166-3:1999 Part 1

Unit UN/ECE Recommendation No. 20

Payment method code ISO 10962:2001, KIEC

Language code IETF RFC 3066

Product code EAN-13, UPC EAN-13 is widely used in distribution, UPC is 

in retail. 

Classification code UNSPSC, HS, NAIC 

Property code EDIFACT 7081 This is product property code such as dimensio

Message function code EDIFACT 1225

Response type code EDIFACT 4343 This code indicates response type of messages. 

48