NDR Main Document s1
Total Page：16
File Type：pdf, Size：1020Kb
1
2Universal Business Language (UBL) 3Naming and Design Rules
4Working Draft 21, 13 December 2002
5Document identifier: 6 wd-ublndrsc-ndrdoc-21 (Word, PDF) 7Location: 8 http://www.oasis-open.org/committees/ubl/ndrsc/drafts/ 9Editors: 10 Bill Burcham, Sterling Commerce
1wd-ublndrsc-ndrdoc-21 1 13 December 2002 2 3 4 5 6 34 email message to [email protected] with the word "subscribe" 35 as the body of the message. 36 For information on whether any patents have been disclosed that may be essential to 37 implementing this specification, and any offers of patent licensing terms, please refer to 38 the Intellectual Property Rights section of the Security Services TC web page 39 (http://www.oasis-open.org/committees/security/).
40Copyright © 2001, 2002 The Organization for the Advancement of Structured Information 41Standards [OASIS]
7wd-ublndrsc-ndrdoc-21 2 13 December 2002 8 9 10 11 12 42Table of Contents
431 Introduction...... 6 44 1.1 Audiences...... 6 45 1.2 Terminology and Notation...... 6 46 1.3 Guiding Principles...... 6 47 1.3.1 Adherence to general UBL guiding principles...... 6 48 1.3.2 Design For Extensibility...... 8 49 1.3.3 Code Generation...... 8 502 Choice of schema language...... 9 513 Relationship to ebXML Core Components...... 10 52 3.1 Rules for Mapping Business Information Entities, Their Properties, and Primitive Types 53 to XML...... 11 544 XML Constructs...... 15 55 4.1 UBL Documentation...... 15 56 4.1.1 The UBL Dictionary...... 15 57 4.1.2 Other UBL Documentation...... 15 58 4.1.3 Embedded documentation...... 15 59 4.2 Naming and Design of XML Constructs...... 16 60 4.2.1 General Naming Rules...... 16 61 4.2.2 Rules for Mapping the UBL Syntax-Neutral Model to XML Constructs...... 17 62 4.2.3 Rules for Mapping the Core Component Types to XML Constructs...... 18 63 4.2.4 Rules for Using Code Lists with XML Constructs...... 19 64 4.2.5 Rules for Embedding Documentation into XML Constructs...... 19 65 4.3 Containership and element design...... 20 66 4.3.1 Nil Values...... 20 675 Modularity, Namespaces, and Versioning...... 21 68 5.1 Schema Module Concepts...... 21 69 5.2 Rules for Creating Namespaces...... 24 70 5.3 Rules for Namespace Identification...... 24 71 5.4 Rules for Schema Module Schema Location...... 25 72 5.5 Rules for Versioning...... 25 736 Restrictions and Facets...... 26 74 6.1 Introduction...... 26 75 6.2 Rules...... 26 767 Rules for Context...... 29 778 Core Component Types...... 30 78 8.1 Code Lists...... 45 79 8.2 Identifier...... 45
13wd-ublndrsc-ndrdoc-21 3 13 December 2002 14 15 16 17 18 80 8.2.1 Necessary Attributes...... 46 81 8.2.2 Specific use for global and/or proprietary identifier...... 47 82 8.3 Date and Time...... 49 83 8.3.1 Introduction...... 49 84 8.3.2 Rules for specific points of date/time...... 49 85 8.3.3 Rules for duration...... 49 86 8.3.4 Core Component Types and Representation Terms...... 49 87 8.3.5 Period...... 49 88 8.3.6 Frequency of recurrent period...... 51 899 Code Lists...... 55 9010 UBL Messages...... 56 91 10.1 General Message Rules...... 56 9211 References...... 57 9312 Technical Terminology...... 58 94Appendix A. UBL NDR Rules...... 61 95Appendix B. Notices...... 62 96
19wd-ublndrsc-ndrdoc-21 4 13 December 2002 20 21 22 23 24 971 Introduction 98This specification documents the rules and guidelines for the naming and design of XML 99components for the UBL library. It contains only rules that have been agreed on by the OASIS 100UBL Naming and Design Rules Subcommittee (NDR SC). Proposed rules, and rationales for 101those that have been agreed on, appear in the accompanying NDR SC position papers, which 102are available at http://www.oasis-open.org/committees/ubl/ndrsc/. 103The W3C XML Schema form of the UBL library is currently constructed automatically from the 104metamodel developed by the OASIS UBL Library Content Subcommittee (LC SC). As such, most 105of the rules in this document are used to guide the development of the engine, produced by the 106OASIS UBL Tools and Techniques Subcommittee (TT SC), that generates the XSD schema 107modules. However, some of the rules address the creation of XML instance constructs and other 108practices that must be undertaken by humans, such as developers, who are customizing UBL for 109their own purposes.
1101.1 Audiences 111There are two primary audiences for this document – the internal TC member/perl scriptwriter, 112and the UBL customizer. 113Unless otherwise specified, the rules in this document apply to both the UBL Library and 114customizations thereof.
1151.2 Terminology and Notation 116The key words must, must not, required, shall, shall not, should, should not, recommended, may, 117and optional in this document are to be interpreted as described. Error: Reference source not 118found Non-italicized forms of these words are used in the regular English sense. 119The notation [Rn] indicates a rule that requires conformance. Only rules are normative; all other 120text is explanatory. The value of R is a prefix for a rule; and n (1..n) indicates the sequential 121number of the rule. 122The adding of brackets “[ ]” around a document title or reference refers the reader to the 123Reference Section 11, for further information. These are also in bold. 124Bold - The bolding of words is used to represent example names or parts of names taken from 125the library. 126Italics – All words appearing in italics, when not titles or used for emphasis, are special terms 127defined in Appendix B. 128The terms “W3C XML Schema” and “XSD” are used throughout this document. They are 129considered synonymous; both refer to XML Schemas that conform to the W3C XML Schema 130Recommendations Error: Reference source not found. See Section 12 for additional term 131definitions.
25wd-ublndrsc-ndrdoc-21 5 13 December 2002 26 27 28 29 30 1311.3 Guiding Principles
1321.3.1 Adherence to general UBL guiding principles 133The UBL NDRSC is following the high-level guiding principles for the design of UBL as approved 134by the UBL TC. These principles are: 135 Internet Use - UBL shall be straightforwardly usable over the Internet. 136 Interchange and Application Use–UBL is intended for interchange and 137 application use. 138 Tool Use and Support - The design of UBL will not make any assumptions about 139 sophisticated tools for creation, management, storage, or presentation being 140 available. The lowest common denominator for tools is incredibly low (for example, 141 Notepad) and the variety of tools used is staggering. We do not see this situation 142 changing in the near term. 143 Time Constraints–Urgency is a key item in the development of UBL. Many facets 144 of XML are still being debated. UBL will make rapid “informed” decisions that may not 145 agree with the ultimately “right” design decisions subsequently reached elsewhere. 146 Legibility - UBL documents should be human-readable and reasonably clear 147 Simplicity - The design of UBL must be as simple as possible (but no simpler). 148 80/20 Rule - The design of UBL should provide the 20% of features that 149 accommodate 80% of the needs. 150 Component Reuse -The design of UBL document types should contain as many 151 common features as possible. The nature of e-commerce transactions is to pass 152 along information that gets incorporated into the next transaction down the line. For 153 example, a purchase order contains information that will be copied into the purchase 154 order response. This forms the basis of our need for a core library of reusable 155 components. Reuse in this context is important, not only for the efficient development 156 of software, but also for keeping audit trails. 157 Standardization - The number of ways to express the same information in a UBL 158 document is to be kept as close to one as possible. 159 Domain Expertise - UBL will leverage expertise in a variety of domains through 160 interaction with appropriate development efforts. 161 Customization and Maintenance - The design of UBL must facilitate 162 customization and maintenance. 163 Context Sensitivity - The design of UBL must ensure that context-sensitive 164 document types aren’t precluded. 165 Prescriptiveness - UBL design will balance prescriptiveness in any one usage 166 scenario with prescriptiveness across the breadth of usage scenarios supported. 167 Having precise, tight content models and datatypes is a good thing (and for this 168 reason, we might want to advocate the creation of more document type “flavors” 169 rather than less; see below). However, in an interchange format, it is often difficult to 170 get the prescriptiveness that would be desired in any one usage scenario. 171 Content Orientation - Most UBL document types should be as “content-oriented” 172 (as opposed to merely structural) as possible. Some document types, such as
31wd-ublndrsc-ndrdoc-21 6 13 December 2002 32 33 34 35 36 173 product catalogs, will likely have a place for structural material such as paragraphs, 174 but these will be rare. 175 XML Technology - UBL design will avail itself of standard XML processing 176 technology wherever possible (XML itself, XML Schema, XSLT, XPath, and so on). 177 However, UBL will be cautious about basing decisions on “standards” (foundational 178 or vocabulary) that are works in progress. 179 Relationship to Other Namespaces - UBL design will be cautious about making 180 dependencies on other namespaces. UBL does not need to reuse existing 181 namespaces wherever possible. For example, XHTML might be useful in catalogs 182 and comments, but it brings its own kind of processing overhead, and if its use is not 183 prescribed carefully it could harm our goals for content orientation as opposed to 184 structural markup. 185 Legacy formats - UBL is not responsible for catering to legacy formats; 186 companies (such as ERP vendors) can compete to come up with good solutions to 187 permanent conversion. This is not to say that mappings to and from other XML 188 dialects or non-XML legacy formats wouldn’t be very valuable. 189 Relationship to xCBL - UBL will not be a strict subset of xCBL, nor will it be 190 explicitly compatible with it in any way.
1911.3.2 Design For Extensibility 192Many e-commerce document types are, broadly speaking, useful but require minor structural 193modifications for specific tasks or markets. When a truly common XML structure is to be 194established for e-commerce, it needs to be easy and inexpensive to modify. 195Many data structures used in e-commerce are very similar to “standard” data structures, but have 196some significant semantic difference native to a particular industry or process. In EDI, there has 197been a gradual increase in the number of published components to accommodate market-specific 198variations. Handling these variations are a requirement, and one that is not easy to meet. A 199related EDI phenomenon is the overloading of the meaning and use of existing elements, which 200greatly complicates interoperation. 201To avoid the high degree of cross-application coordination required to handle structural variations 202common to EDI and DTD based systems - it is necessary to accommodate the required variations 203in basic data structures without either overloading the meaning and use of existing data elements, 204or requiring wholesale addition of new data elements. This can be accomplished by allowing 205implementers to specify new element types that inherit the properties of existing elements, and to 206also specify exactly the structural and data content of the modifications. 207This can be expressed by saying that extensions of core elements are driven by context [need ref 208here]. Context driven extensions should be renamed to distinguish them from their parents, and 209designed so that only the new elements require new processing. 210Similarly, data structures should be designed so that processes can be easily engineered to 211ignore additions that are not needed.
2121.3.3 Code Generation 213Most of the schema modules in the UBL Library are generated automatically from the underlying 214model in order to ensure faithful adherence to the model. Therefore, the UBL design process 215needs to ensure successful automation. For example, the model needs to provide enough
37wd-ublndrsc-ndrdoc-21 7 13 December 2002 38 39 40 41 42 216information to take advantage of schema constraint opportunities, and the design rules that apply 217to these need to avoid requiring human judgment at generation time 218
43wd-ublndrsc-ndrdoc-21 8 13 December 2002 44 45 46 47 48 2192 Choice of schema language 220[R 1] All UBL schema design rules must be based on the W3C XML Schema 221 Recommendations: XML Schema Part 1: Structures; and XML Schema Part 2: Datatypes 222[R 2] All UBL schemata and messages must be based on the World Wide Web Consortium 223 (W3C) suite of technical specifications holding recommendation status 224We need information here about how we made this decision. 225Some of the benefits of the above decisions are: 226 Elements and types can be managed separately 227 Type inheritance and derivation allows for deep type hierarchies 228 Elements, datatypes, and attributes can independently be locally or globally 229 scoped 230 Namespace support allows for federation of component creation and reuse 231 And importing (outer) schemas can reset some settings
49wd-ublndrsc-ndrdoc-21 9 13 December 2002 50 51 52 53 54 2323 Relationship to ebXML Core Components 233UBL employs the methodology and model described in UN/CEFACT Draft Core Components 234Specification 30 September 2002, Version 1.85, [CCTS]. In the terminology of that specification, 235the UBL vocabulary consists primarily of Aggregate Business Information Entities (ABIE). An 236ABIE is similar to a Class in object-oriented modeling (e.g. UML). An ABIE is also similar to an 237entity in Entity Relationship modeling. 238According to the [CCTS], each ABIE must have a unique name (Object Class Term). Each ABIE 239must have one or more BIE Properties. Each BIE Property must have a name (Property Term). 240That name must be unique within that ABIE. 241There are two kinds of BIE Property. A Basic BIE Property represents an intrinsic property of an 242ABIE. An Association BIE Property represents an extrinsic property – in other words an 243association from one ABIE instance to another ABIE instance. It is the Association BIE Property 244that expresses the relationship between ABIEs. 245In order to actually define the intrinsic structure of an ABIE, a set of Basic Business Information 246Entities (BBIE) is defined. These are the “leaf” types in the system in that they contain no 247Association BIE Properties, and no Basic BIE Properties. A BBIE must have a single Content 248Component and one or more Supplementary Components. A Content Component is of some 249Primitive Type. 250Here’s a picture of the relevant parts of the Core Components metamodel: 251Figure 3.1 The Core Component Metamodel
Association BIE Property -Property Term -cardinality
0..* 0..* 1 -from1 -to
Basic BIE Property 0..* 1 Aggregate Business Information Entity -Property Term -Object Class Term -cardinality
0..* 1
Basic Business Information Entity -Object Class Term 1..* -supplementaryComponents
0..* 0..* Primitive Type -name
-contentComponent 1 (part of) Core Components Metamodel 252
55wd-ublndrsc-ndrdoc-21 10 13 December 2002 56 57 58 59 60 253 254The preceding diagram depicts a summary of the Core Components metamodel. Whereas the 255Core Components metamodel encompasses two broad categories of model element, the Core 256Component and the Business Information Entity, UBL is concerned with only the latter. 257Since UBL is concerning itself only with the development of Business Information Entities, and 258their realization in XML, the UBL metamodel speaks only in terms of BIE concepts. For instance, 259while the Core Components metamodel specifies that each BIE is “based on” a particular Core 260Component – that detail is not considered by UBL. UBL defines no Core Components. 261Similarly, the Core Components metamodel describes parallel model elements to capture low- 262level types, such as Identifiers and Dates. In that metamodel, a Core Component Type describes 263these low-level types for use by Core Components, and (in parallel) a “Data Type” – 264corresponding to that Core Component Type, describes these low-level types for use by Business 265Information Entities. UBL is not; therefore concerned with Core Component Types since again, 266they pertain only to the Core Components model, which UBL is not specifying. UBL defines no 267Core Components, and UBL defines no Core Component Types. 268That being said, you might rightly expect to see Data Type appear in the diagram above, 269however, since in the Core Components metamodel there is a one-to-one correspondence 270between a Data Type and a Business Information Entity, UBL has elected to define only the 271latter. The alternative would be for UBL to define Data Types (e.g. AmountType, CodeType, 272DateTimeType, etc.) and also to define corresponding BIE’s. To do so would add no value to the 273work product, so we will model only one. UBL defines no Data Types separate from BIE’s – there 274is only the BIE’s.
2753.1 Rules for Mapping Business Information Entities, Their 276 Properties, and Primitive Types to XML 277A primary deliverable of the UBL effort is XML Schemas. These schemas declare a complex type 278for each ABIE, and a complex type for each BBIE. Each Association BIE Property becomes an 279element definition (within the appropriate complex type). Similarly each Basic BIE Property 280becomes an element definition within a complex type. 281This diagram depicts the relationship between the ABIE model and the XML Schema/XML 282instance models: 283Figure 3.2 ABIE and XML schema instance models 284 285
61wd-ublndrsc-ndrdoc-21 11 13 December 2002 62 63 64 65 66 XML Schema
TypeName
1 -identifies Association BIE Property 1 -Property Term -describes -cardinality 1 Type 0..* 0..* 1 1 1 -from1 -to
Basic BIE Property 0..* 1 Aggregate Business Information Entity 1 1 -defines -Property Term -contains -Object Class Term 1 -cardinality 1 TypeDefinition 1 0..* 1 -defines 1 1 Basic Business Information Entity -Object Class Term 1..* -supplementary 1 0..*0..* 0..* 0..* Primitive Type ElementDeclaration -name -defines 11 0..* 1 -describes -contentComponent 1 (part of) Core Components Metamodel TagName
-describes 1 -implements 0..* Element 0..* 1..*-child 1 -parent XML Instance 286 XML Model 287 288Each ABIE results in a complex type declaration in the XML Schema. The complex type name is 289derived like this: 290 291
295 67wd-ublndrsc-ndrdoc-21 12 13 December 2002 68 69 70 71 72 296Each BBIE results in a complex type declaration in the XML Schema. The name of the complex 297type is derived like this: 298 299
303 304Each Basic BIE Property results in an element in the XML Schema. The tag name is derived like 305this: 306 307
Party Identifier PartyID
319 320 321Each Association BIE Property results in an element definition in the XML Schema. The tag name 322is derived like this: 323
73wd-ublndrsc-ndrdoc-21 13 13 December 2002 74 75 76 77 78 324
331 332TODO: we need to add the excruciating details of mapping Basic Business Information Entities, 333and their associated content component and supplementary components to XSD and XMl.
79wd-ublndrsc-ndrdoc-21 14 13 December 2002 80 81 82 83 84 3344 XML Constructs 335In W3C XML Schema, elements are defined in terms of complex or simple types and attributes 336are defined in terms of simple types. The rules in this section govern the consistent naming and 337structuring of these constructs and the manner for unambiguously and thoroughly documenting 338them in the UBL Library
3394.1 UBL Documentation
3404.1.1 The UBL Dictionary 341The primary component of the UBL documentation is its dictionary. The entries in the dictionary 342fully define the pieces of information available for use in UBL business messages. Each 343dictionary entry has a full name that ties the information to its standardized semantics, while the 344name of the corresponding XML element or attribute is only shorthand for this full name. The 345rules for element and attribute naming and dictionary entry naming are different. 346[R 3] Each dictionary entry name must define one and only one fully qualified path (FQP) for 347 an element or attribute. 348The fully qualified path anchors the use of that construct to a particular location in a business 349message. The dictionary definition identifies any semantic dependencies that the FQP has on 350other elements and attributes within the UBL library that are not otherwise enforced or made 351explicit in its structural definition. The dictionary serves as a traditional data dictionary, and also 352serves some of the functions of traditional implementation guides.
3534.1.2 Other UBL Documentation 354The UBL documentation also includes definitions of: 355 XSD complex and simple types in the UBL library, including whether and how 356 that type maps to a core component type 357 The top-level whole message elements in UBL 358 Global attributes 359 Summaries of Code Lists 360 UBL-specific Core Component Types 361 UBL-specific representation terms 362The UBL documentation should be automatically generated to the extent possible, using 363embedded documentation fields in the structural definitions.
3644.1.3 Embedded documentation 365Sent info to Arofan, waiting for answer. 366(Incorporate: [R ] Element declarations must be accompanied by documentation in the form of an 367
3714.2 Naming and Design of XML Constructs 372The rules in this section make use of the following special concepts related to XML elements and 373attributes. 374Top-level element: An element that encloses a whole UBL business message. Note that UBL 375business messages might be carried by messaging transport protocols that themselves have 376higher-level XML structure. Thus, a UBL top-level element is not necessarily the root element of 377the XML document that carries it. 378Lower-level element: An element that appears inside a UBL business message. 379Intermediate element: An element not at the top level that is of a complex type, only containing 380other elements and attributes. 381Leaf element: An element containing only character data (though it may also have attributes). 382Note that, because of the XSD mechanisms involved, a leaf element that has attributes must be 383declared as having a complex type, but a leaf element with no attributes may be declared with 384either a simple type or a complex type. 385Common attribute: An attribute that has identical meaning on the multiple elements on which it 386appears. A common attribute might or might not correspond to an XSD global attribute.
3874.2.1 General Naming Rules 388[R 4] Names must be in the English language, using the primary English spellings provided in 389 the Oxford English Dictionary. 390If the UBL Library is translated into other languages for localization purposes, these additional 391languages might require additional restrictions. Such restrictions are expected be formulated as 392additional rules and published as appropriate. 393[R 5] XML names constructed from dictionary entry names must not include periods, spaces, 394 or other separators. 395[R 6] Names must not use acronyms, abbreviations, or other word truncations, with the 396 following list of exceptions: 397 A Dun & Bradstreet number must appear as “DUNS”. [TBD: need example.] 398 “Identifier” must appear as “ID”. 399 “Uniform Resource Identifier” must appear as “URI” (example: the “Uniform 400 Resource. Identifier” portion of the Binary Object. Uniform Resource. Identifier 401 supplementary component becomes “URI” in the resulting XML name). This rule 402 takes precedence over the rule that dictates a substitution of “ID” for “Identifier”. 403[R 7] Names must not contain non-letter characters unless required by language-specific rules. 404[R 8] Names must be in singular form unless the concept itself is plural (example: Goods). 405[R 9] Names for XML constructs must use camel-case capitalization, such that each internal 406 word in the name begins with an initial capital followed by lowercase letters (example: 407 AmountContentType). All XML constructs other than attributes must use upper camel-case, 408 with the first word initial-capitalized, while attributes must use lower camel-case, with the first 409 word all in lowercase (example: unitCode), with the exception of attribute names consisting 410 of one of the allowed acronyms, abbreviations, or truncations given in R3. 91wd-ublndrsc-ndrdoc-21 16 13 December 2002 92 93 94 95 96 4114.2.2 Rules for Mapping the UBL Syntax-Neutral Model to XML 412 Constructs 413The naming of Core Components is based on the following concepts taken from the ISO/IEC 41411179 specification for data dictionaries [TBD: move stuff here from Eve’s paper]: 415 416The names of elements and types are not faithful reproductions of the naming scheme used in 417the UBL Library’s syntax-neutral model for object classes and properties; truncation rules are 418applied to allow for reuse of element names across parent element environments and to maintain 419brevity and clarity. 420[R 10] Every UBL business message must have a single corresponding top-level element. 421[R 11] Every top-level element must be named according to the portion of the business process 422 that it initiates. 423 Examples: Order, OrderResponse, ChangeOrder, AdvanceShipNotice, 424 AdvanceShipNoticeResponse. 425[R 12] For every object class (Aggregate BIE) identified in the syntax-neutral model, a complex 426 type definition and a corresponding global element declaration bound to that type must be 427 created. 428 Example: from a Party. Details object class, a complex type/global 429 element declaration pair is created. [TBD: complete the 430 local/global decision and implement in this rule and below.] 431The element thus created is useful for reuse in the building of new business messages. The 432complex type thus created is useful for both reuse and customization, in the building of both new 433and contextualized business messages. [TBD: point to a context methodology document or 434section from here.] 435[R 13] The name of a complex type based on an object class must be the name of the object 436 class, with the separators removed and with the “Details” suffix replaced with “Type”. 437 Example: The Party. Details object class becomes the PartyType 438 complex type. 439[R 14] An element name in a global element declaration based on an object class must be the 440 name of the object class, with the separators removed and with “Details” removed. 441 Example: The Party. Details object class becomes a global Party 442 element. 443[R 15] For every complex type definition based on an object class, its content model must be 444 defined such that it reflects each property of the object class as an element declaration, with 445 its cardinality and positioning within the content model determined by the details of the 446 syntax-neutral model. 447 Example: an optional Party. Address. Address property appearing as 448 the first content of a Party. Details object class becomes the 449 first element declaration inside the PartyType complex type, with 450 a minOccurs value of “0”. [TBD: an element ref= declaration, or 451 an element name= declaration?] 452[R 16] An element name in an element declaration [TBD: ref= or name=?] based on a property 453 must be the full dictionary name of the property in the syntax-neutral model, with the
97wd-ublndrsc-ndrdoc-21 17 13 December 2002 98 99 100 101 102 454 separators and object class term removed, and with the property term removed if it is 455 identical or similar to the representation term. 456The following term pairs are considered similar: Identification/Identifier and Identification/Code. If 457the representation term is “Text”, it must be removed. If the representation term is “Identifier”, it 458must be replaced with “ID”. 459 Examples: Person. Name. Text becomes Name, Person. Residence. 460 Address becomes ResidenceAddress, and Address. Country. Identifier 461 becomes CountryID. 462If the object class term would have been helpful in the resulting XML name for clarity, it should be 463repeated in the property qualifier field. For example, if Party. Identification. Identifier would result 464in an element name of ID, and if this name would be confusing because a Party object has many 465different identifiers as properties, then the property should have been named Party. Party 466Identification. Identifier instead, resulting in an element name of PartyID. 467[R 17] Every element declaration corresponding to a property must be bound to a type 468 corresponding to the property’s representation term. Where the representation term 469 corresponds to an object class (aggregate BIE), the complex type corresponding to that 470 object class must be used. Where the representation term corresponds to a Core Component 471 Type, the complex type corresponding to that Core Component Type must be used. 472 Examples: A BuyerParty element declaration based on the Order. 473 Buyer Party. Party property is bound to the PartyType complex 474 type, and a CountryID element declaration based on the Address. 475 Country. Identifier property is bound to the Identifier type that 476 is defined in the CCT schema module. [TBD: what about restrictions 477 and faceting of CCTs?]
4784.2.3 Rules for Mapping the Core Component Types to XML 479 Constructs 480[R 18] A namespace schema module dedicated to defining types corresponding to the Core 481 Component Types must be created. 482[R 19] Each CCT must have at least one corresponding unique complex type and simple type, 483 where the element’s content (governed by the xs:simpleContent construct and the CCT’s 484 simple type) represents the content component of the CCT and whose attributes (defined in 485 the complex type) each represent a supplementary component of the CCTs. 486[TBD: need example.] 487Note that this rule relegates attribute usage to supplementary components only; all “primary” 488business data appears exclusively in element content. Note also that because all CCTs have a 489content component and because all object classes have at least one property, the UBL Library 490does not have any elements that are required to be empty by design. [TBD: do we once again 491need an empty-element rule, so that we can discourage customizers from adding their own and 492using them as booleans?] 493[R 20] The complex type name corresponding to a CCT must be the CCT name, with the 494 periods and spaces removed. 495 Example: The Quantity. Type CCT becomes the QuantityType complex 496 type.
103wd-ublndrsc-ndrdoc-21 18 13 December 2002 104 105 106 107 108 497[R 21] The name of the simple type corresponding to the content component of a CCT must be 498 the content component name, with the periods and spaces removed and with “Type” added to 499 the end. 500 Example: The content component Amount. Content becomes 501 AmountContentType. 502[R 22] The name of the attribute corresponding to a supplementary component must be the 503 name of the supplementary component, with the periods and spaces removed. The first field 504 (the “object class” field) may be truncated, reworded, or removed as necessary for brevity 505 and clarity. If the final field (the “representation term” field) is “Text”, it must be removed. If the 506 final field is “Identifier”, it must be replaced with “ID”. 507 Examples: Binary Object. Format. Text becomes format, Code List 508 Identifier becomes codeListID, and Quantity. Unit. Code becomes 509 unitCode. 510[R 23] Mixed-content elements should not be used. [TBD: Rule about “Prose” RT? Or just wait 511 until we have an actual case of mixed content?] 512Note that mixed content in business documents is undesirable because white space in mixed 513content is difficult to handle and complicates processing, and because mixed-content models 514allow little useful control over the cardinality of elements. 515[R 24] The CCT schema module may define a set of one or more common attributes that apply 516 to all UBL elements. 517[R 25] A common attribute should be declared as a global attribute only in cases where the 518 attribute’s meaning is identical no matter what element it is used on, and where the attribute 519 is useful on every UBL element. This rule applies to both external (such as xml:lang) and 520 UBL-specific global attributes. 521Note that this rule allows for the creation of common attributes that are allowed on every element 522but are not globally declared, and that need documentation of their meaning in each XML 523environment in which they are used. 524[R 26] The names of UBL-specific global attributes must be based on assigned object class 525 property names, as is done for elements that are properties. 526 [TBD: need example.]
5274.2.4 Rules for Using Code Lists with XML Constructs 528[TBD: need to figure out interface of external code list schema modules with a handcrafted UBL 529module that incorporates their use.]
5304.2.5 Rules for Embedding Documentation into XML Constructs 531[R 27] Every type definition and element declaration must contain a structured set of 532 annotations in following pattern, where the keyword is typically based on the spreadsheet 533 column heading in the syntax-neutral model and the description is typically based on the 534 content of the spreadsheet field:
535
109wd-ublndrsc-ndrdoc-21 19 13 December 2002 110 111 112 113 114 539 540
546[R 28] The following sets of annotations are required in type definitions and element 547 declarations: [TBD: replace this list with Arofan’s table, I have sent list and updated position 548 paper to Arofan] 549 UBL UID: The unique identifier assigned to the type in the UBL library. 550 UBL Name: The complete name (not the tag name) of the type per the UBL 551 library. 552 Object Class: The Object Class represented by the type. 553 UBL Definition: Documentation of how the type is to be used, written such that it 554 addresses the type’s function as a reusable component. 555 Code Lists/Standards: A list of potential standard code lists or other relevant 556 standards that could provide definition of possible values not formally expressed in 557 the UBL structural definitions. 558 Core Component UID: The UID of the Core Component on which the Type is 559 based. 560 Business Process Context: A valid value describing the Business Process 561 contexts for which this construct has been designed. Default is “In All Contexts”. 562 Geopolitical/Region Context: A valid value describing the Geopolitical/Region 563 contexts for which this construct has been designed. Default is “In All Contexts”. 564 Official Constraints Context: A valid value describing the Official Constraints 565 contexts for which this construct has been designed. Default is “None”. 566 Product Context: A valid value describing the Product contexts for which this 567 construct has been designed. Default is “In All Contexts”. 568 Industry Context: A valid value describing the Industry contexts for which this 569 construct has been designed. Default is “In All Contexts”. 570 Role Context: A valid value describing the Role contexts for which this construct 571 has been designed. Default is “In All Contexts”. 572 Supporting Role Context: A valid value describing the Supporting Role contexts 573 for which this construct has been designed. Default is “In All Contexts”. 574 System Capabilities Context: A valid value describing the Systems Capabilities 575 contexts for which this construct has been designed. Default is “In All Contexts”. 576Following is an example of a complete set of annotations for a definition: 577 [TBD]
115wd-ublndrsc-ndrdoc-21 20 13 December 2002 116 117 118 119 120 5784.3 Containership and element design
5794.3.1 Nil Values 580[R 29] The nillable attribute must not be used in any UBL schema. The element declaration of 581 xsi:nil shall not appear in any UBL conforming instance. 582
121wd-ublndrsc-ndrdoc-21 21 13 December 2002 122 123 124 125 126 5835 Modularity, Namespaces, and Versioning 584For an overview of current thinking on issues of modularity, namespace and versioning, consult 585the Modnamver position paper. 586 587[R 30] The top-level element must be globally declared in a UBL root schema.
5885.1 Schema Module Concepts 589This section describes the mapping of XML namespaces onto XSD files: 590Schema Module: A schema document containing type definitions and element declarations. 591Namespace Schema Module: A Schema Module that declares a target namespace and is likely 592to pull in (by including or importing) Schema Modules. 593Internal Schema Module: A Schema Module that does not declare a target namespace. 594[R 31] If a definition depends on named constructs found in another namespace, then that other 595 namespace must be imported as a namespace schema module. The referenced constructs 596 must not be directly included as Internal Schema Modules. 597If a namespace is small enough then it can be completely specified within the Root Schema. For 598larger namespaces, more schema modules may be defined – call these internal modules. The 599root schema for that namespace then include those Internal Modules. 600This structure provides encapsulation of namespace implementations. 601A namespace “A” dependent upon type definitions or element declaration defined in another 602namespace “B” must import B’s root schema. “A” must not import internal schema modules of “B”. 603The only place XSD “include” is used is within a root schema. When a namespace gets large, its 604type definitions and element declarations may be split into multiple schema modules (called 605internal modules) and included by the root schema for that namespace. 606 607[Need to look at capitalization – on hold til I get answers. LISA 608] 609Thus a namespace is an indivisible grouping of types. A “piece” of a namespace can never be 610used without all its pieces. 611Here is a depiction of the component structure we’ve described so far. This is a UML Static 612Structure Diagram. It uses classes and associations to depict the various concepts we’ve been 613discussing: 614Figure 5.1 UML Static Structure Diagram
127wd-ublndrsc-ndrdoc-21 22 13 December 2002 128 129 130 131 132 File
1 TypeDefinition 0..* 1 1 1 ElementDeclaration 0..* SchemaModule 0..*
0..* -imported 1 1 InternalModule RootSchema Namespace
-included 0..* 1
616You can see that there are two kinds of schema module: RootSchema and “InternalModule”. A 617RootSchema may have zero or more InternalModules that it includes. Any SchemaModule, be it a 618RootSchema or an InternalModule may import other RootSchemas. 619The diagram shows the 1-1 correspondence between RootSchemas and namespaces. It also 620shows the 1-1 correspondence between files and SchemaModules. A SchemaModule consists of 621type definitions and element declarations. 622Another way to visualize the structure is by example. The following informal diagram depicts 623instances of the various classes from the previous diagram. 624Figure 5.2 Classes
133wd-ublndrsc-ndrdoc-21 23 13 December 2002 134 135 136 137 138 urn:oasis: urn:oasis: names:tc:ubl names:tc:ubl: :Order Invoice
Order Invoice
urn:oasis:names:tc:ubl: CommonAggregateTypes
Common Aggregate Types Root schema
Internal Common Module LeafTypes urn:oasis:names:tc:ubl: import CommonLeafTypes include
X:y:z Namespace
626The preceding diagram shows how the order and invoice RootSchemas import the 627“CommonAggregateTypes” and “CommonLeaf Types” RootSchemas. It also shows how e.g. the 628order RootSchema includes various InternalModules – modules local to that namespace. The 629clear boxes show how the various SchemaModules are grouped into namespaces. 630UBL is structured so that a user can import a piece without getting the whole. It must be possible, 631for instance, for a user to import the CommonLeafTypes namespace without causing the 632CommonAggregateTypes to be imported. It must be possible for a user to import the 633CommonAggregateTypes namespace without causing the Order namespace to be imported. It 634must be possible to import any one of the “vertical” namespaces, e.g. Order without causing 635another, e.g. Invoice to be imported. 636 637[Is this clear, and the issues and constraints clear enough. Should there be rules for this? LISA] 638
139wd-ublndrsc-ndrdoc-21 24 13 December 2002 140 141 142 143 144 639If two namespaces are mutually dependent then clearly, importing one will cause the other to be 640imported as well. For this reason there must not exist circular dependencies between UBL 641SchemaModules. By extension, there must not exist circular dependencies between 642namespaces. This rule is not limited to direct dependencies – transitive dependencies must be 643taken into account also.
6445.2 Rules for Creating Namespaces 645Given the conceptual framework of the previous section, important questions remain: how many 646namespaces are needed? What is the function of each? 647This section makes explicit the namespace structure given implicitly in the previous section. The 648UBL library consists of four namespaces. The Common Leaf Types namespace defines all the 649Basic Business Information Entities. A Common Aggregate Types namespace defines reusable 650Aggregate Business Information Entities based on the types defined in the Common Leaf Types 651namespace. 652Two higher-level “domain” namespaces are defined, one for the “ordering” domain and another 653for the “invoicing” domain. The Order Domain namespace defines message types and ABIEs 654specific to the ordering domain. Similarly, the Invoice Domain namespace defines message types 655and ABIEs specific to the invoicing domain. 656 Purpose Namespace name Common Leaf Types -- this urn:oasis:names:tc:ubl:CommonLeafTypes[TBD version is where Basic Business info] Information Entities are defined. Common Aggregate Types – urn:oasis:names:tc:ubl:CommonAggregateTypes[TBD this is where Aggregate BIE’s version info] used across various domains are defined. Order Domain – this is where urn:oasis:names:tc:ubl:Order[TBD version info] ordering-related message types and their order-specific ABIE’s are defined. Invoice Domain – this is urn:oasis:names:tc:ubl:Invoice[TBD version info] where invoicing-related message types and their invoicing-specific ABIE’s are defined.
6575.3 Rules for Namespace Identification 658[R 32] The namespace names for UBL namespaces must have the following structure while the 659 schemas are at draft status: 660urn:oasis:names:tc:ubl:schema{:subtype}?:{document-id} 661[R 33] When they move to specification status the form must change to: 145wd-ublndrsc-ndrdoc-21 25 13 December 2002 146 147 148 149 150 662urn:oasis:names:specification:ubl:schema{:subtype}?:{document-id} 663[R 34] Where the form of {document-id} is TBD but it should match the schema module name 664 (see section).
6655.4 Rules for Schema Module Schema Location 666[R 35] Schema location must include the complete URI which is used to identify schema 667 modules. 668[R 36] [R ] In the fashion of other OASIS specifications, UBL schema modules will be located 669 under the UBL committee directory: 670http://www.oasis-open.org/committees/ubl/schema/
6735.5 Rules for Versioning 674[R 37] Each namespace should have a version. TBD: 675 676[INSERT TEXT FROM MINUTES] Recommendation is to adopt versioning approach wherein 677each minor version would be given separate namespace. Minor versioning will be limited to 678declaring new constructs, extending existing constructs, and refinement (XSD normative 679definition). Minor version namespaces will import preceeding minor version root schemas. All 680such changes will thus be backward compatible to previous minors and its … 681 682
151wd-ublndrsc-ndrdoc-21 26 13 December 2002 152 153 154 155 156 6836 Restrictions and Facets 684
6856.1 Introduction 686The following rules have been defined for the handling of restrictions and facets for Core 687Component Types (CCT), Basic Core Components (BCCs) and Basic Business Information 688Entities (BBIEs).
6896.2 Rules 690[R 38] A Core Component Type without any restriction of the Content Component must be 691 defined by a complexType. This complexType includes a simpleContent group with a 692 extension for all relevant global and local attributes (Supplementary Components) of this 693 Core Component Type. The base type definition of this extension must be based on one of 694 the decided built-in datatypes (see table ###). 695 For Example: 696
774 775[R 44] If a global attribute or a Supplementary Component (local attribute) should be restricted 776 within a Basic Core Component as well as a Basic Business Information Entity, there must be
163wd-ublndrsc-ndrdoc-21 28 13 December 2002 164 165 166 167 168 777 a restriction of a simpleContent. The base type definition of the restriction must refer to the 778 complexType of the relevant Core Component Type. This restriction includes the attribute or 779 attributes, which should be restricted. The simpleType of each attribute must be a restriction, 780 again. This restriction includes all relevant facets. 781For Example: 782 791 value="EUR"/> 792
169wd-ublndrsc-ndrdoc-21 29 13 December 2002 170 171 172 173 174 8277 Rules for Context 828 829For an overview of current thinking on Context Rules, consult the Specialization Architecture 830position paper from the Context Methodology Subcommittee.
175wd-ublndrsc-ndrdoc-21 30 13 December 2002 176 177 178 179 180 8318 Core Component Types 832The following spreadsheet shows the list of all defined Core Component Types and their 833equivalent Representation Terms:
CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
Amount. Type Amount. [xsd:decimal] Amount Currency. currencyID - required (Amount): Content: Identifier: [string] [xsd:token] [decimal] A number of Note: We agreed The currency of the monetary units A number of amount. (Reference not to restrict the Note: This should be the specified in a monetary units fractional digits. UN/ECE Rec. 9, using currency where the specified in a 3-letter alphabetic content type of the schema unit of currency is currency where codes. The UN/ECE that corresponds to this explicit or implied. the unit of Rec. 9 is also code list. currency is explicit published as ISO We recommend to use the or implied. 4217, but is available “Currency Coded A” of Rec. in electronic form and 9. free of charge.)
Amount Currency. codeListVersionID - Code List Version. optional Identifier: [xsd:token] [string]
The version of the Note: The default version is UN/ECE Rec. 9 code Rec. 9 - 2002. list.
Binary Object. Type Binary Object. [xsd:base64Bina Binary Object. format – optional (Binary Object, Content: [binary] ry] Format. Text: [mime] [xsd:token] Graphic, Picture, A set of finite- The format of the Sound, Video): length sequences binary content. A set of finite-length of binary octets. Note: Defines the type of sequences of binary binary content without any octets. coding list.
Note: format itself could be the same as mimeCode. Therefore is this attribute might be not necessary.
Binary Object. Type. typeCode – prohibited Code: [??] ?? [xsd:token]
Note: not necessary
Binary Object. encodingCode – prohibited Encoding. Code: [??] [xsd:token] ?
181wd-ublndrsc-ndrdoc-21 31 13 December 2002 182 183 184 185 186 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
Note: Better will be better: Binary Object. Charset. Code. Because this charsetCode – optional supplementary [xsd:token] component corresponds to the charset code of MIME Note: The attribute [RFC 2045 and RFC “charsetCode” could be 2046]. used for subtypes of format "text". It gives a name of a character set, as "character set" is defined in RFC 2045. An initial list of predefined character set names can be found at the end of this section. Additional character sets may be registered with IANA. Other media types than subtypes of "text" might choose to employ the charset parameter as defined here. Therefore, all character sets that conform to the general definition of "character set" in RFC 2045 can be registered for MIME use.
Binary Object. URI – optional Uniform Resource. [xsd:anyURI] Identifier: [string] The Uniform Resource Identifier that identifies better where the Binary Object is located. xlink:href – optional [xsd:anyURI]
Note: The attribute “xlink:href” has a value that is the URI of the binary object referenced. It shall conform to the XLINK specification criteria for a simple link.
Note: Refers to local MIME- Attachenments within the same Message-Envelope. By using MIME- Attachments, no another supplementary components 187wd-ublndrsc-ndrdoc-21 32 13 December 2002 188 189 190 191 192 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
for describing the MIME- chararcteristics are necessary. The URI scheme name for referencing to the specific MIME-attachments is cid (see: [IETF RFC 2392])
xlink:type – optional [xsd:token]
Note: The attribute type defines the element as being an XLINK simple link. It has a fixed value of “simple”.
Issue: Binary Object. typeCode ?? – optional Type. Code is listed in [xsd:token] Table 8-1 but not Table 8-2. Note: ??
Issue: Binary Object. encodingCode – optional Encoding. Code is [xsd:token] listed in Table 8-1 but not Table 8-2. Is it supposed to be the Note: Not necessary, see same as Binary above Object. Encoding. Type, which is mentioned in Table 8- 2? The remarks for the latter say “Reference IETF RFC 2047.”
Issue: Binary Object. mimeCode – optional Mime. Type is listed [xsd:token] in Table 8-2, but not Table 8-1. Is it a duplicate of Binary Note: Defines the type of Object. Format. MIME Format according Text? The remarks for IETF RFC 2046 and the the latter say formats, which build on it. “Reference IETF RFC 2046.” Note: “Type” does not existing as Representation Term. It should be either ID oder Code. It is recommended to use “Code” because the MIME Format is a very stable list of MIME Types.
193wd-ublndrsc-ndrdoc-21 33 13 December 2002 194 195 196 197 198 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
Issue: Binary Object. filename – optional Filename. Text is not [xsd:token] existing in CCTS 1.85 but should be included, because this Note: The identification of is a part of MIME- the filename of the specific Type (IETF RFC binary object. 1341)
Code. Type (Code): Code. Content: [xsd:token] Code List. Identifier: listID – optional A character string [string] [string] The [xsd:token] (letters, figures or A character string identification of a list of codes. (Can be symbols) that for (letters, figures or Note: listID is unique within brevity and/or symbols) that for used to identify the URL of a source that the responsible agency, language brevity and/or only. independence may language defines the set of be used to represent independence currently approved or replace a may be used to permitted values.) definitive value or represent or Code List. Agency. listAgencyID – optional text of an attribute replace a Identifier: [string] An together with definitive value or [xsd:token] agency that maintains relevant text of an attribute. one or more code supplementary lists. (Defaults to the information. Note: Default is UN/EDIFACT data UN/CEFACT data element element 3055 code 3055 code list without the list.) specific codes for partner role.
Note: If another identification scheme for defining the responsible agency will be taken, this identification scheme for identifying this agency and the responsible agency for it must be defined by the additional supplementary components listAgencySchemeId and listAgencySchemeAgencyId.
Code List. Agency listAgencyName – optional Name. Text: [string] [xsd:token] The name of the agency that maintains the code list. Note: listAgencyName should be not used, because all code list should be recognized in a standardized global environment.
Code List. Name. listName – optional Text: [string] The [xsd:token] name of a list of codes. Note: listName should be not used, because all code list should be recognized in 199wd-ublndrsc-ndrdoc-21 34 13 December 2002 200 201 202 203 204 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
a standardized global environment.
Code List. Version. listVersionID – optional Identifier: [string] The [xsd:token] version of the code list. (Identifies the version of the UN/EDIFACT data element 3055 code list.)
Code. Name. Text: name – optional [string] The textual [xsd:token] equivalent of the code content. (If no code content exists, the Note: It might be not code name can be necessary to use name for used on its own.) the exchange of instances.
Language. Identifier: languageID – optional [string] The identifier [xsd:language] of the language used in the corresponding text string. better:
xml:lang – optional [xsd:language]
Note: The language should be base on the recommendation IETF RFC 1766 and/or IETF RFC 3066.
Note: For parser processing reasons should be useful, to use the recommended attribute xml:lang for representing the supplementary component Language. Identifier. (see Kapitel 2.12 in Extensible Markup Language (XML) 1.0 (Second Edition)). The values of the attribute are language identifiers as defined by [IETF RFC 1766], Tags for the Identification of Languages, or its successor on the IETF Standards
205wd-ublndrsc-ndrdoc-21 35 13 December 2002 206 207 208 209 210 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
Track.
Code List. Uniform listURI – optional Resource. Identifier: [xsd:anyURI] [string] The Uniform Resource Identifier that identifies where better: the code list is located. xlink:href – optional [xsd:anyURI] or
Note: The attribute “xlink:href” has a value that is the URI of the code list referenced. It shall conform to the XLINK specification criteria for a simple link.
Code List Scheme. listSchemeURI – optional Uniform Resource. [xsd:anyURI] Identifier: [string] The Uniform Resource Identifier that identifies better: where the code list scheme is located. xlink:role – optional [xsd:anyURI]
Note: the xlink:role attribute indicates the location of the code list scheme that the entire link has.
xlink:type – optional [xsd:token]
Note: The attribute type defines the element as being an XLINK simple link. It has a fixed value of “simple”.
Code List Agency. listAgencySchemeId – Scheme. Identifier: optional [string] Identifies the [xsd:token] the specific identification scheme for identifying the Note: This attribute is responsible agency for necessary, if the value in 211wd-ublndrsc-ndrdoc-21 36 13 December 2002 212 213 214 215 216 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
the identifier within the listAgencyID is not based supplementary on UN/CEFACT data component Code List. element 3055. Agency. Identifier
Code List Agency. listAgencySchemeAgencyI Scheme Agency. d – optional Identifier [string]: [xsd:token] Identifies the agency of the specific identification scheme Note: This attribute is for identifying the necessary, if the value in responsible agency for listAgencyID is not based the identifier within the on UN/CEFACT data supplementary element 3055. component Code List. Agency. Identifier (This identifier based on UN/EDIFACT data element 3055 code list.)
Date Time. Type Date Time. [xsd:dateTime] Date Time. Format. format – prohibited (Date Time, Date, Content: [string] Text: [string] The [xsd:token] Time): format of the date/time The particular Note: It is A particular point in point in the content. (Reference recommended the ISO 8601 and W3C Note: This attribute is not the progression of progression of extended format time together with time. (For times note on date time.) necessary, because the of the built-in built-in datatype relevant use an ISO 8601 datatpye supplementary compliant format xsd:dateTime have an xsd:dataTime unique format. information. that includes the (YYYY-MM-DD). UTC offset.)
Identifier. Type Identifier. [xsd:token] Identification schemeID – optional (Identifier): Content: [string] Scheme. Identifier: [xsd:token] A character string to A character string [string] The identify and to identify and identification of the distinguish uniquely, distinguish identification scheme. Note: Identifies an one instance of an uniquely, one identification scheme. The object in an instance of an identification scheme identification scheme object in an represents the context used from all other objects identification to identify an object. in the same scheme scheme from all SchemeId is only unique together with other objects within the agency that relevant within the same administrates this supplementary scheme. identification scheme. information. Note: If another identification scheme for defining the responsible agency will be taken, this identification scheme for identifying this agency and the responsible agency for it must be defined by the additional supplementary components schemeAgencySchemeId and
217wd-ublndrsc-ndrdoc-21 37 13 December 2002 218 219 220 221 222 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
schemeAgencySchemeAge ncyId.
Identification schemeName – optional Scheme. Name. Text: [xsd:token] [string] The name of the identification scheme. Note: schemeName should be not used, because all identification schemes should be recognized in a standardized global environment.
Identification schemeAgencyID – Scheme Agency. optional Identifier: [string] The [xsd:token] identification of the agency that maintains the identification Identifies the agency that scheme. (Defaults to administrates an the UN/EDIFACT data identification scheme. The element 3055 code agencies from DE 3055 are list.) used as the default, whereby the roles defined in DE 3055 cannot be used.
Note: If another identification scheme for defining the responsible agency will be taken, this identification scheme for identifying this agency and the responsible agency for it must be defined by the additional supplementary components schemeAgencySchemeId and schemeAgencySchemeAge ncyId.
Identification schemeAgencyName – Scheme. Agency optional Name. Text: [string] [xsd:token] The name of the agency that maintains the identification Note: schemeAgencyName scheme. should be not used, because all identification schemes should be recognized in a standardized global environment.
Identification schemeVersionID – Scheme. Version. optional Identifier: [string] The [xsd:token] version of the identification scheme. 223wd-ublndrsc-ndrdoc-21 38 13 December 2002 224 225 226 227 228 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
Note: Identifies the version of this identification scheme.
Identification schemeDataURI – optional Scheme Data. [xsd:token] Uniform Resource. Identifier: [string] The Uniform Resource better: Identifier that identifies where the identification scheme xlink:href – optional data is located. [xsd:anyURI]
Note: The attribute “xlink:href” has a value that is the URI of the identification scheme data referenced. It shall conform to the XLINK specification criteria for a simple link.
Identification schemeURI – optional Scheme. Uniform [xsd:token] Resource. Identifier: [string] The Uniform Resource Identifier better: that identifies where the identification scheme is located. xlink:role – optional [xsd:anyURI]
Note: the xlink:role attribute indicates the location of the identification scheme that the entire link has.
xlink:type – optional [xsd:token]
Note: The attribute “xlink:type” defines the element as being an XLINK simple link. It has a fixed value of “simple”.
Identification schemeAgencySchemeId Scheme – optional Agency. Scheme. [xsd:token] Identifier: [string] Identifies the identification scheme Note: This attribute is that represents the necessary, if the value in context for identifying schemeAgencyID is not the agency. based on UN/CEFACT data 229wd-ublndrsc-ndrdoc-21 39 13 December 2002 230 231 232 233 234 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
element 3055.
Identification schemeAgencySchemeAg Scheme Agency. encyId – optional Scheme Agency. [xsd:token] Identifier: [string] Identifies the agency that administrates the Note: This attribute is SchemeAgencySche necessary, if the value in meId. This attribute schemeAgencyID is not can only contain based on UN/CEFACT data values from DE 3055 element 3055. (without roles).
Indicator. Type Indicator. [xsd:boolean] Indicator. Format. format – prohibited (Indicator): Content: [string] Text: [string] Whether [xsd:token] A list of two mutually The value of the the indicator is exclusive Boolean indicator. (For numeric, textual or values that express example on, off, binary. Note: This attribute is not the only possible true, false.) necessary, because the states of a Property. built-in datatype xsd:boolean have an unique format.
Measure. Type Measure. [xsd:decimal] Measure Unit. Code: unitCode – required (Measure): Content: [string] The type of [xsd:NMTOKEN] [decimal] unit of measure. A numeric value Note: We agreed determined by The numeric value (Reference UN/ECE not to restrict the Rec. 20 and X12 355.) Note: This should be the measuring an object determined by fractional digits. along with the measuring an content type of the schema object. (For that corresponds to this specified unit of code list. measure. example, 24.387 kilograms (24.387 We recommend to use the is the Measure. “comecode” of Rec. 20. Content).) Measure Unit. Code unitCodeListVersionID – List Version. optional Identifier: [string] The [xsd:token] version of the measure unit code list. Note: The default version is Rec. 20 - 2002.
Numeric. Type Numeric. [xsd:decimal] Numeric. Format. format – prohibited (Numeric, Value, Content: [as Text: [string] Whether [xsd:token] Rate, Percent): defined by the number is an Note: We agreed Numeric information Numeric. Format. integer, decimal, real Text] not to restrict the number or Note: This attribute is not that is assigned or is fractional digits. determined by Numeric percentage. necessary, because the calculation, counting, information that is built-in datatype xsd:decimal or sequencing. It assigned or is have an unique format. does not require a determined by unit of quantity or calculation, unit of measure. couting, or sequencing. (May be decimal.)
Quantity. Type Quantity. [xsd:decimal] Quantity. Unit. Code: unitCode – required
235wd-ublndrsc-ndrdoc-21 40 13 December 2002 236 237 238 239 240 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
(Quantity): Content: [string] The unit of the [xsd:NMTOKEN] A counted number of [decimal] Note: We agreed quantity. (May use UN/ECE non-monetary units A counted number not to restrict the Note: This should be the possibly including of non-monetary fractional digits. Recommendation #20.) content type of the schema fractions. units possibly that corresponds to this including fractions. code list. (For example 7 bales (7 is the We recommend to use the Quantity. “comecode” of Rec. 20. Content).) Quantity Unit. Code unitCodeListID – optional List. Identifier: [xsd:token] [string] The quantity unit code list. Note: The default version is Rec. 20 - 2002.
Quantity Unit. Code unitCodeListAgencyID – List Agency. optional Identifier: [string] The [xsd:token] identification of the agency which maintains the quantity Note: The default version is unit code list. Rec. 20 - 2002. (Defaults to the UN/EDIFACT data element 3055 code list.)
Quantity Unit. Code unitCodeListAgencyName List Agency Name. – optional Text: [string] The [xsd:token] name of the agency which maintains the quantity unit code list. Note: The default version is Rec. 20 - 2002.
Note: unitCodeListAgencyName should be not used, because all identification schemes should be recognized in a standardized global environment.
Text. Type (Text, Text. Content: [xsd:string] Language. Identifier: languageId – optional Name): [string] [string] The identifier [xsd:language] A character string A character string of the language used (i.e. a finite set of (i.e. a finite set of in the corresponding characters) generally characters) text string. better: in the form of words generally in the of a language. form of words of a language. xml:lang – optional [xsd:language]
Note: The language should 241wd-ublndrsc-ndrdoc-21 41 13 December 2002 242 243 244 245 246 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
be base on the recommendation IETF RFC 1766 and/or IETF RFC 3066.
Note: For parser processing reasons should be useful, to use the recommended attribute xml:lang for representing the supplementary component Language. Identifier. (see Kapitel 2.12 in Extensible Markup Language (XML) 1.0 (Second Edition)). The values of the attribute are language identifiers as defined by [IETF RFC 1766], Tags for the Identification of Languages, or its successor on the IETF Standards Track.)
Language. Locale. languageLocaleID – Identifier: [string] The optional identification of the [xsd:token] locale of the language.
Note: unitCodeListAgencyName should be not used, because all locales of the languages can be represented by the recommendation IETF RFC 1766 and/or IETF RFC 3066.
ElectronicAddress. ElectronicAddres [xsd:anyURI] Electronic Address. protocolID - required Type s. Content: Protocol. Identifier: [xsd:token] (ElectronicAddress [string] A Uniform [string] A more ): A Uniform Resource specific identification Resource Identifier Identifier that of the transfer Note: If the schema of that identifies an identifies an protocol. anyURI does not specify the electronic address electronic (Reference: correct transfer protocol, this address. UN/EDIFACT Data transfer protocol can be Element 3155 expressed by protocolID. This Uniform “Communication Address Code Resource Note: Identifier based on Qualifier”) the Electronic Address. languageID - optional recommendations Language. Identifier: [xsd:language] . IETF RFC 1738, IETF RFC 1808, [string] The identifier IETF RFC 2396 of the language used better: and IETF RFC in the referenced 2732 object. xsl:lang - optional
247wd-ublndrsc-ndrdoc-21 42 13 December 2002 248 249 250 251 252 CCT (Primary RT, Content Component: Supplementary Components: Secondary RTs): [data-type] Definition. (Remarks.) [data-type] Definitions. (Remarks.) CCT Definition.
[xsd:language]
Note: The language should be base on the recommendation IETF RFC 1766 and/or IETF RFC 3066.
Note: For parser processing reasons should be useful, to use the recommended attribute xml:lang for representing the supplementary component Language. Identifier. (see Kapitel 2.12 in Extensible Markup Language (XML) 1.0 (Second Edition)). The values of the attribute are language identifiers as defined by [IETF RFC 1766], Tags for the Identification of Languages, or its successor on the IETF Standards Track.
834
8358.1 Code Lists 836See the separate Code List Recommendation paper for details of the NDRSC's recommendations 837for code lists.
8388.2 Identifier 839By using the Core ComponentType “Identifier” it is possible to represent identifiers for using in the 840global environment as well as in the proprietary environment. Master data identification requires 841that both standardized and proprietary identifiers within a message are exchanged. 842Standardized Identifiers: 843Standardized identifiers already have globally unique and valid names that are known at 844implementation time. These names can, therefore, be mapped generally using the attribute 845"schemeAgencyName" and fixed values in the ERP systems. 846Proprietary Identifiers: 847Proprietary identifiers are not usually valid generally and are not known at implementation time, 848meaning that they cannot be mapped using fixed values in the ERP systems. Various 849specifications enable uniqueness at runtime to be removed. These specifications are detailed in 850this document. 851The identifier is created for these requirements based on the following object model:
253wd-ublndrsc-ndrdoc-21 43 13 December 2002 254 255 256 257 258 Identifier Object -identification -scheme : IdentificationScheme 1 *
*1
IdentificationSchemeAgency IdentificationScheme -administrates -identification -identification -scheme -version -agency 1 * -agency : IdentificationSchemeAgency 852 853
8548.2.1 Necessary Attributes 855The following attributes for these requirements need to be considered:
CCT Category Object Class Property Term Represen- Datatype Card- tation nality Term
Identifier complexType Identifier Identifier Content xsd:token
schemeId Attribute IdentificationScheme Identification Identifier xsd:token 0..1
schemeVersionId Attribute IdentificationScheme Version Identifier xsd:token 0..1
schemeAgencyId Attribute IdentificationScheme- Identification Identifier xsd:token 0..1 Agency
schemeAgency- Attribute IdentificationScheme- Scheme Identifier xsd:token 0..1 SchemeId Agency
schemeAgency- Attribute IdentificationScheme- SchemeAgency Identifier xsd:token 0..1 SchemeAgencyId Agency
856 SchemeId identifies an identification scheme. The identification scheme 857 represents the context used to identify an object. SchemeId is only unique within the 858 agency that administrates this identification scheme. 859 SchemeVersionId identifies the version of this identification scheme. 860 SchemeAgencyId identifies the agency that administrates an identification 861 scheme. The agencies from DE 3055 are used as the default, whereby the roles 862 defined in DE 3055 cannot be used. 863 SchemeAgencySchemeId identifies the identification scheme that represents 864 the context for identifying the agency. 865 SchemeAgencySchemeAgencyId identifies the agency that administrates the 866 SchemeAgencySchemeId. This attribute can only contain values from DE 3055 867 (without roles).
259wd-ublndrsc-ndrdoc-21 44 13 December 2002 260 261 262 263 264 8688.2.2 Specific use for global and/or proprietary identifier 869The data type identifier is used for all elements or attributes that are to enable unique 870identification of logical or real objects in communication between partners or systems. The 871number of attributes is not to be "limited" but rather should increase continually (such as with 872ProductId, OrderId, and so on). More and more IDs are added. 873If the agency administrating the identification scheme is not named explicitly but rather specified 874using a role, this occurs in the tag name. 875The following types of identifier can be mapped: 876 877[R 46] Standardized identifiers whose identification schemes are administrated by an agency 878 from the code list DE 3055. 879The relevant attributes are: Identifier Standard schemeId Identification scheme for the standard identifier schemeVersionId Version of the identification scheme schemeAgencyId Agency from DE 3055 (without roles) schemeAgencySchemeId - schemeAgencySchemeAgencyId -
880Fore Example: 881
887For Example:
265wd-ublndrsc-ndrdoc-21 45 13 December 2002 266 267 268 269 270 888
895For Example: 896
905For Example: 906
271wd-ublndrsc-ndrdoc-21 46 13 December 2002 272 273 274 275 276 9088.3 Date and Time
9098.3.1 Introduction 910Rules for the following aspects of time have been formulated. These aspects of time are: 911 specific point of date and/or time 912 durations, i.e. measurements of time 913 periods between particular points in date and or time 914 frequency of a defined period 915ISO 8601 (as described in XML Schema Part 2) is used for the lexical description of the built in 916datatypes DateTime, Date, Time and Duration. Its periods and recurrence rules are not 917satisfactory for the description of these aspects. Rather an XML structure is more flexible for this 918purpose.
9198.3.2 Rules for specific points of date/time 920[R 50] For each specific point in time the built in datatype from XML schema (Part 2) must be 921 used. These are xsd:time, xsd:date, xsd:dateTime.
9228.3.3 Rules for duration 923The expression of duration requires the use of an additional secondary Representation Term 924called Duration. Type. 925[R 51] For the expression of the Representation Term Duration. Type the XSD built in 926 datatype xsd:Duration must be used. For example 927
9398.3.4 Core Component Types and Representation Terms 940[Gunther still to look into this further] There is a one to one correspondence between Core 941Component Types and Representation Terms. Where additional property terms like Year, 942YearMonth, are used then the additional built in datatypes from XML Schema part 2 must be 943used. These additional datatypes are: xsd:gYear, xsd:gYearMonth, xsd:gMonth, 944xsd:gMonthDay, and xsd:gDay.
9458.3.5 Period 946[R 52] A period can be expressed using the Aggregate Core Component (ACC) 947 PeriodDetails. The ACC is divided into 3 representation types, Date, Time and DateTime.
277wd-ublndrsc-ndrdoc-21 47 13 December 2002 278 279 280 281 282 948 One of these must be selected. Each option has a start and end date, start and end time or 949 start DateTime and end DateTime. 950
951 952 953XML-Schema: 954 955
283wd-ublndrsc-ndrdoc-21 48 13 December 2002 284 285 286 287 288 9858.3.6 Frequency of recurrent period 986This represents a recurring times and/or dates within a duration period (start and end date/-time) 987or a duration (measure of time). There are four different types of recurrence: 9881. By a number of recurrences at points over a defined period of time 9892. By recurrences at time intervals over a period, with the indicated duration for each time- 990 interval between recurrences. 9913. By a number of recurrences over a duration. 9924. By recurrences at time intervals over a duration, with the indicated duration for each time- 993 interval between recurrences. 994It is possible to represent each of these four types of recurrent periods by a single structure. This 995structure looks as follows:
996
9978.3.6.1 Number of recurrences at points over a defined period of time 998
289wd-ublndrsc-ndrdoc-21 49 13 December 2002 290 291 292 293 294 Beginning Date and/or Ending Date and/or Time Time Time
Frequency
1000To represent defined points in a time period, the following components of the structure are 1001required:
1002 1003[R 54] The start and end times may be represented by the BCCs i.e. StartTime, EndTime, 1004 StartDate, EndDate etc. 1005[R 55] The recurrence of these periods in time may be represented by the BCC 1006 RecurrenceValue.
Beginning Date and/or Ending Date and/or Time Time Time
FrequencyIntervals 10078.3.6.2 Recurrences at time intervals over a period 1008To represent defined interval in a time period, the following components of the structure are 1009required:
295wd-ublndrsc-ndrdoc-21 50 13 December 2002 296 297 298 299 300 1010 1011[R 56] The start and end times may be represented by the BCCs i.e. StartTime, EndTime, 1012 StartDate, EndDate etc. 1013[R 57] The intervals in a point in time should be represented by a single BCC indicated by the 1014 choice operator i.e. FrequencyDuration, FrequencyYear etc.
10158.3.6.3 Number of recurrences over a duration
Duration
Time
Frequency
1017To represent the number of recurrences over a duration, the following components of the 1018structure are required:
301wd-ublndrsc-ndrdoc-21 51 13 December 2002 302 303 304 305 306 1019 1020[R 58] Duration may be expressed by the BCC Duration. 1021[R 59] The number of recurrences may be expressed by the BCC RecurrenceValue.
10228.3.6.4 Recurrences at time intervals over a duration 1023 Duration
Time
FrequencyIntervals 1024 To represent the recurrences of intervals over a duration, the following components of the 1025structure are required:
1026 1027[R 60] Duration may be expressed by the BCC Duration. 1028[R 61] The intervals in a point in time should be represented by a single BCC indicated by the 1029 choice operator i.e. FrequencyDuration, FrequencyYear etc. 1030
307wd-ublndrsc-ndrdoc-21 52 13 December 2002 308 309 310 311 312 10319 Code Lists 1032See the separate Code List Recommendation paper for details of the NDRSC's recommendations 1033for code lists.
313wd-ublndrsc-ndrdoc-21 53 13 December 2002 314 315 316 317 318 103410UBL Messages
103510.1General Message Rules 1036The following general rules for messages must be applied. 1037[R 62] A UBL message set may be extended where desirable if the business function of the UBL 1038 original is retained., but the message exists within its own business context. 1039According to the XML Recommendation [XML], the legal characters in XML character data are 1040tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646, as these 1041standards are updated from time to time. It further notes that "The mechanism for encoding 1042character code points into bit patterns may vary from entity to entity" and requires all XML 1043processors (parsers) to accept the UTF-8 and UTF-16 encodings of 10646. UBL has the same 1044requirements for legal characters in XML instance documents and the same minimal 1045requirements for character encoding support in UBL-aware software. 1046[R 63] UBL documents must use the same legal characters in XML character data that are listed 1047 in the XML Recommendation. Including tab, carriage return, line feed, and the legal 1048 characters of Unicode and ISO/IEC 10646. 1049[R 64] Trading partners may agree on other character encodings to use among themselves. It is 1050 recommended in all case that encoding declarations be provided in the XML declarations of 1051 UBL documents. 1052[R 65] UBL messages must express semantics fully in schemas and not rely merely on well- 1053 formedness. 1054[R 66] Instances conforming to schemas should be readable and understandable, and should 1055 enable reasonably intuitive interactions. 1056[R 67] In the context of a schema, information that expresses correspondences between data 1057 elements in different classification schemes (“mappings”) may be regarded as metadata. This 1058 information should be accessible in the same manner as the rest of the information in the 1059 schema.
319wd-ublndrsc-ndrdoc-21 54 13 December 2002 320 321 322 323 324 106011References 1061 [CCTS] UN/CEFACT Draft Core Components Specification 30 September, 2002, 1062 Version 1.85 1063 [CCFeedback] Feedback from OASIS UBL TC to Draft Core Components Specification 1064 1.8, version 5.2, May 4, 2002, http://oasis- 1065 open.org/committees/ubl/lcsc/doc/ubl-cctscomments-5p2.pdf. 1066 [GOF] Design Patterns, Gamma, et al. ISBN 0201633612 1067 [ISONaming] ISO/IEC 11179, Final committee draft, Parts 1-6. 1068 (RFC) 2119 S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 1069 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 1070 [UBLChart] UBL TC Charter, http://oasis-open.org/committees/ubl/charter/ubl.htm 1071 [XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C 1072 Recommendation, October 6, 2000 1073 (XSD) XML Schema, W3C Recommendations Parts 0, 1, and 2. 2 May 2001. 1074 1075 (XHTML) XHTML™ Basic, W3C Recommendation 19 December 2000: 1076 http://www.w3.org/TR/2000/REC-xhtml-basic-20001219 1077 1078
325wd-ublndrsc-ndrdoc-21 55 13 December 2002 326 327 328 329 330 107912Technical Terminology 1080 Ad hoc schema processing Doing partial schema processing, but not with official schema validator software; e.g., reading through schema to get the default values out of it. Application-level validation Adherence to business requirements, such as valid account numbers. Assembly Using parts of the library of reusable UBL components to create a new kind of business document type.
Common attribute An attribute that has identical meaning on the multiple elements on which it appears. A common attribute might or might not correspond to an XSD global attribute. Context A particular set of context driver values. DTD validation Adherence to an XML 1.0 DTD. Generic BIE A semantic model that has a “zeroed” context. We are assuming that it covers the requirements of 80% of business uses, and therefore is useful in that state. Instance constraint checking Additional validation checking of an instance, beyond what XSD makes available, that relies only on constraints describable in terms of the instance and not additional business knowledge; e.g., checking co-occurrence constraints across elements and attributes. Such constraints might be able to be described in terms of Schematron. Instance root/doctype This is still mushy. The transitive closure of all the declarations imported from whatever namespaces are necessary. A doctype may have several namespaces used within it.
Intermediate element An element not at the top level that is of a complex type, only containing other elements and attributes. Internal schema module: A schema module that does not declare a target namespace.
Leaf element An element containing only character data (though it may also have attributes). Note that, because of the XSD mechanisms involved, a leaf element that has attributes must be declared as having a complex type, but a leaf element with no attributes may be declared with either a simple type or a complex type.
331wd-ublndrsc-ndrdoc-21 56 13 December 2002 332 333 334 335 336 Lower-level element An element that appears inside a business message. Namespace schema module: A schema module that declares a target namespace and is likely to pull in (by including or importing) schema modules. Root Schema A schema document corresponding to a single namespace, which is likely to pull in (by including or importing) schema modules. Issue: Should a root schema always pull in the “meat” of the definitions for that namespace, regardless of how small it is? Schema Never use this term unqualified! Schema Module A “schema document” (as defined by the XSD spec) that is intended to be taken in combination with other such schema documents to be used. Schema module: A schema document containing type definitions and element declarations. Schema Processing Schema validation checking plus provision of default values and provision of new infoset properties. Schema Validation Adherence to an XSD schema.
Top-level element An element that encloses a whole UBL business message. Note that UBL business messages might be carried by messaging transport protocols that themselves have higher- level XML structure. Thus, a UBL top-level element is not necessarily the root element of the XML document that carries it. Syntax Neutral Model TBD Need definition. Aggregate Business A collection of related pieces of business information that Information Entity (ABIE) together convey a distinct business meaning in a specific Business Context. Expressed in modelling terms, it is the representation of an Object Class, in a specific Business Context. Object Class The logical data grouping (in a logical data model) to which a data element belongs (ISO11179). The Object Class is the part of a Core Component’s Dictionary Entry Name that represents an activity or object in a specific Context. Well-Formedness Checking Basic XML 1.0 adherence.
1081 1082 1083(This is text to be used in defining Parent type and type bindings.) General Overview of Types
337wd-ublndrsc-ndrdoc-21 57 13 December 2002 338 339 340 341 342 1084In XSD, elements are declared to have types, and most types (those complex types that are 1085defined to have “complex contents”) are defined as a pattern of subelements and attributes. Thus, 1086XSD has an indirect nesting structure of elements and types (where, for example, Type 1 below is 1087the parent type of Element A and where Type 2 is the parent type of Element B and the type 1088bound to Element A): 1089 Type 1 1090Element A 1091Type 2 1092Element B 1093 1094 1095 1096
343wd-ublndrsc-ndrdoc-21 58 13 December 2002 344 345 346 347 348 1097Appendix A. UBL NDR Rules
1098
349wd-ublndrsc-ndrdoc-21 59 13 December 2002 350 351 352 353 354 1099Appendix B. Notices
1100OASIS takes no position regarding the validity or scope of any intellectual property or other rights 1101that might be claimed to pertain to the implementation or use of the technology described in this 1102document or the extent to which any license under such rights might or might not be available; 1103neither does it represent that it has made any effort to identify any such rights. Information on 1104OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 1105website. Copies of claims of rights made available for publication and any assurances of licenses 1106to be made available, or the result of an attempt made to obtain a general license or permission 1107for the use of such proprietary rights by implementors or users of this specification, can be 1108obtained from the OASIS Executive Director. 1109OASIS invites any interested party to bring to its attention any copyrights, patents or patent 1110applications, or other proprietary rights which may cover technology that may be required to 1111implement this specification. Please address the information to the OASIS Executive Director. 1112Copyright © The Organization for the Advancement of Structured Information Standards [OASIS] 11132001. All Rights Reserved. 1114This document and translations of it may be copied and furnished to others, and derivative works 1115that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 1116published and distributed, in whole or in part, without restriction of any kind, provided that the 1117above copyright notice and this paragraph are included on all such copies and derivative works. 1118However, this document itself does not be modified in any way, such as by removing the 1119copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 1120specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 1121Property Rights document must be followed, or as required to translate it into languages other 1122than English. 1123The limited permissions granted above are perpetual and will not be revoked by OASIS or its 1124successors or assigns. 1125This document and the information contained herein is provided on an “AS IS” basis and OASIS 1126DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1127ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1128ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1129PARTICULAR PURPOSE.
355wd-ublndrsc-ndrdoc-21 60 13 December 2002 356 357 358 359 360