ࡱ>    % Pbjbj%% J GG*2ax3 l$$$$Xe.$ƂP\LƂll6( r$R  r jQdb%%P0%.dbb Rt'Sd U3Ƃbb J<]v b 0 ,ƂƂ%%%% Data Format Description Language (DFDL) v1.0 Core Specification (Internal Committee Working Document)  Status of This Document This memo provides information to the Grid community regarding the specification of a Data Format Description Language. The specification is currently a working group internal draft. It does not define any standards or technical recommendations. Distribution is unlimited. Copyright Notice Copyright Global Grid Forum 2004, 2005,,2006. All Rights Reserved. Copyright Open Grid Forum,2006, 2007. All Rights Reserved. Abstract This document provides a definition of a standard Data Format Description Language (DFDL). This language allows description of dense binary and legacy data formats in a vendor-neutral declarative manner. DFDL is an extension to the XML Schema Description language (XSD). Revision History Latest entry at the top please VersionAuthor/ContributorHistoryDate(yyyy-mm-dd)019Mike Beckerleupdated "full copyright notice" to OGF text. Merged changes from Martin's 018. Fixed UML diagrams to match slides. (also got rid of base64binary type from simple types) Merged in comments on Version 017 by S. Hanson, G. Judd, A. Powell. (Some comments were not applied, just merged in as comment "bubbles" for now..)2007-05-02018Martin WestheadAdded section "What is DFDL"2007-04-24017Mike BeckerleDistributed 016 to S. Hanson, so started a new rev. Got the parse strategies to the point where this needs more review. The optional handling can definitely deal with the nulls/missing/optional/default complexity. I was able to directly leverage the flow-charts for parse for this.2007-04-19016Mike BeckerleContinuing work on parse strategies and organization for that. Fixed concept of opaque 'any' wildcards. This required adding a couple more cases to the semantics of 'any', but still these are just source-to-source rewrites for their semantics. Folded 'uncertainty' material about choices into parse strategy for choice, which does not have varying specialized parse strategies. Fixed variables discussion. Syntax then semantics. Broke out array and optional separately. This simplifies the parse strategy discussion substantially. Factored out all the handling of context and assertions and variable annotations into a common description of the P parse function instead of having it repeated in C, G, S, A, etc. Finished parse functions (general framework) for arrays and optionals. Didn't really for arrays, but enough is there for the concept to be clear. This framework can handle null/optional/missing/default issue now. I put back in the defineProperty annotation because the framework now lets us really bootstrap the definitions of the properties from a very very tiny core DFDL.2007-04-15015Mike BeckerleWorked on Parse Strategies Section. Changed BOMRequired to byteOrderMarkPolicy. Changed enum names. 2007-04-02014Mike BeckerleReorganization of sections into better order. Put in some changes requested during earlier review cycle. Handled Unordered Groups by way of source-to-source transformation and a data postprocessing step. This is far better than complicating the semantics to deal with unordered stuff. Filled in Choice parse rule. Added 'Nested Delimited Constructs' section. Added a bunch of topics about regexp delimiting, end-of-data delimiting, length protocols and such. These are "tossed into" the parse strategy section, which is currently very disorganized, but at least the notions are captured.2007-03-25013Mike BeckerleIncorporated comments on v12 by S. Hanson. Prepared for reordering grammar section to after parse-strategies section.2007-03-25012Mike BeckerleGGF->OGF throughout. Integrated Tom Sugdens rewrite to the scoping section, and mods to the Syntax section (which is still not only about syntax) Put basic arrays material into the properties description section for the occurrences properties. Much other editing. Removed these to parking lot: Variables Usage Scenarios, Extensibility, Schematron appendix, defineStream and stream changing, conversions search example. Got rid of DPath. Its now XPath, albeit with some semantic restrictions (since our model is simpler than the full XML model e.g., no attributes to address with XPaths) Merged in and reorganized the Length Protocols material. Introduced Parse Strategies concept. incorporated "conversions" into parse strategies. 2007-03-18011Mike Beckerleupdate to validation error definition. Minor changes elsewhere.2007-02-14010Geoff JuddUpdate Default and Nulls section2007-01-24009Geoff JuddMoved some of the Uncertainty material back to the Core document. Specifcially DFDL assertions and unresolvable points of uncertainty. 2006-09-20008Geoff JuddRemoved most of Uncertainty material (including properties) except for a brief summary.2006-08-23007Mike BeckerleApplied simplifications as discussed in DFDL WG call on 2006-08-032006-08-10006Mike BeckerleImproved examples in uncertainty section based on feedback from Suman, Steve H. Integrated user-defined properties and Variables material.2006-07-21005Mike BeckerleMany, many, (MANY) changes as a result of big full-pass read through. 2006-07-17004Mike Beckerleintegrated material about uncertainty. Point of departure was the document: "Support of Uncertainty in DFDL-007.doc", by Geoff Judd. Also integrated material about null/default/optional handlings. Point of departure is "Support of Default and Null Values in DFDL-008.doc" by Geoff Judd2006-07-14003Mike Beckerleadded properties list, and layering material2006-07-13002Robert E. McGrathText from notes on arrays. Section 12 and 17. 2006-07-07001Mike BeckerleCreated this new framework document to combine all the sub-team documents into a combined spec. Started over from version 001 since this is being put together from pieces from all over.2006-06-23 TBD: TODO List Parse strategies: add example -for arrays that handles the tricky defaulting up to minOccurs. add examples that illustrate tricky things like finalTerminatorCanBeMissing add examples of regexp and discuss scanability Need to switch to a real programming language to develop many more of these things though. Throughout: To eliminate ambiguity, is it worth always qualifying a DFDL property with dfdl: ? Or maybe by using underbar in anticipation of making them hyperlinks? For example, it gets difficult sometimes to know whether the word 'separator' refers to the property or to the concept. These are TBDs in the document that it would be great to address before OGF 20: 5. What is DFDL, including a sub-section giving scope of DFDL 1.0. 8.1. A schema for DFDL would be great but not sure if Suman will have the time to do this. Random Note: On possible extensibility mechanism: source-to-source schema declaration rewrite specified with XSLT. data post-processing rewrite via XQuery or XSLT to match the original logical model. This would allow new keywords to be given meaning by end users. Example is the way 'initiatorSeparator' is defined for Any Element Wildcards in unordered groups. Issue: everywhere in the semantics it needs to specifically accommodate evaluation of expressions which produce property bindings. evaluation of variable definitions evaluation of variable assignments evaluation of assertions evaluation of inputValueCalc There are ambiguities here. E.g., a property can have an expression as its value which can depend on a set-variable which depends on a property that uses an expression in its evaluation. The order of evaluation here isn't clear. Furthermore, a variable can inquire of the value of an element; hence, the set-variable expression might need to be evaluated after the element has received its logical value. We can force people to introduce scopes to make it clear. That is, we can be heavy handed here and say that first the properties are evaluated, then any set-variable expressions, and then any assertions. Contents  TOC \o "1-5" \h \z \u  HYPERLINK \l "_Toc165626304" Data Format Description Language (DFDL) v1.0  PAGEREF _Toc165626304 \h 1  HYPERLINK \l "_Toc165626305" Abstract  PAGEREF _Toc165626305 \h 1  HYPERLINK \l "_Toc165626306" Revision History  PAGEREF _Toc165626306 \h 2  HYPERLINK \l "_Toc165626307" TBD: TODO List  PAGEREF _Toc165626307 \h 6  HYPERLINK \l "_Toc165626308" Contents  PAGEREF _Toc165626308 \h 7  HYPERLINK \l "_Toc165626309" TBD: Hints to Authors and Editors  PAGEREF _Toc165626309 \h 13  HYPERLINK \l "_Toc165626310" 1 Introduction  PAGEREF _Toc165626310 \h 14  HYPERLINK \l "_Toc165626311" 1.1 Why is DFDL Needed?  PAGEREF _Toc165626311 \h 15  HYPERLINK \l "_Toc165626312" 1.2 What is DFDL?  PAGEREF _Toc165626312 \h 15  HYPERLINK \l "_Toc165626313" 1.2.1 Simple Example  PAGEREF _Toc165626313 \h 15  HYPERLINK \l "_Toc165626314" 1.3 What DFDL is not  PAGEREF _Toc165626314 \h 17  HYPERLINK \l "_Toc165626315" 1.4 Scope of version 1.0  PAGEREF _Toc165626315 \h 17  HYPERLINK \l "_Toc165626316" 1.5 Related standards  PAGEREF _Toc165626316 \h 18  HYPERLINK \l "_Toc165626317" 2 Notational and Definitional Conventions  PAGEREF _Toc165626317 \h 18  HYPERLINK \l "_Toc165626318" 2.1 Failure Types  PAGEREF _Toc165626318 \h 18  HYPERLINK \l "_Toc165626319" 2.2 Schema Definition Error  PAGEREF _Toc165626319 \h 18  HYPERLINK \l "_Toc165626320" 2.3 Processing Errors: Parse Error, Unparse Error  PAGEREF _Toc165626320 \h 18  HYPERLINK \l "_Toc165626321" 2.4 Validation Errors  PAGEREF _Toc165626321 \h 19  HYPERLINK \l "_Toc165626322" 3 Glossary  PAGEREF _Toc165626322 \h 20  HYPERLINK \l "_Toc165626323" 4 Outline of the Specification  PAGEREF _Toc165626323 \h 21  HYPERLINK \l "_Toc165626361" 5 DFDL Information Model  PAGEREF _Toc165626361 \h 22  HYPERLINK \l "_Toc165626362" 5.1 DFDL Subset of XML Schema  PAGEREF _Toc165626362 \h 24  HYPERLINK \l "_Toc165626363" 6 Syntax Basics  PAGEREF _Toc165626363 \h 25  HYPERLINK \l "_Toc165626364" 6.1 Namespaces  PAGEREF _Toc165626364 \h 25  HYPERLINK \l "_Toc165626365" 6.2 The DFDL Annotation Elements  PAGEREF _Toc165626365 \h 25  HYPERLINK \l "_Toc165626366" 6.2.1 Additional Specialized Annotation Elements  PAGEREF _Toc165626366 \h 26  HYPERLINK \l "_Toc165626367" 6.3 String Literals in DFDL  PAGEREF _Toc165626367 \h 27  HYPERLINK \l "_Toc165626368" 6.3.1 Hex Escape for String Literals  PAGEREF _Toc165626368 \h 27  HYPERLINK \l "_Toc165626369" 7 Syntax and Basic Usage of DFDL Annotation Elements  PAGEREF _Toc165626369 \h 28  HYPERLINK \l "_Toc165626370" 7.1 dfdl:format: Putting Formats to Use  PAGEREF _Toc165626370 \h 28  HYPERLINK \l "_Toc165626371" 7.1.1 Attributes of dfdl:format  PAGEREF _Toc165626371 \h 28  HYPERLINK \l "_Toc165626372" 7.1.2 Representation Property Binding Syntax: Attribute Form  PAGEREF _Toc165626372 \h 28  HYPERLINK \l "_Toc165626373" 7.1.3 Representation Property Binding Syntax: Element Form  PAGEREF _Toc165626373 \h 29  HYPERLINK \l "_Toc165626374" 7.1.4 Short Form Syntax for Format Annotations  PAGEREF _Toc165626374 \h 29  HYPERLINK \l "_Toc165626375" 7.1.5 Empty Bindings  PAGEREF _Toc165626375 \h 30  HYPERLINK \l "_Toc165626376" 7.2 dfdl:defineFormat - Reusable Data Format Definitions  PAGEREF _Toc165626376 \h 30  HYPERLINK \l "_Toc165626377" 7.2.1 Inheritance for dfdl:defineFormat  PAGEREF _Toc165626377 \h 31  HYPERLINK \l "_Toc165626378" 7.2.2 Using/Referencing a Named Format Definition  PAGEREF _Toc165626378 \h 31  HYPERLINK \l "_Toc165626379" 7.3 The dfdl:assert Annotation Element  PAGEREF _Toc165626379 \h 31  HYPERLINK \l "_Toc165626380" 7.4 The dfdl:escapeScheme Annotation Element  PAGEREF _Toc165626380 \h 32  HYPERLINK \l "_Toc165626381" 7.5 The dfdl:hidden Annotation Element  PAGEREF _Toc165626381 \h 32  HYPERLINK \l "_Toc165626382" 7.6 The dfdl:numberScheme Annotation Element  PAGEREF _Toc165626382 \h 33  HYPERLINK \l "_Toc165626383" 7.7 The dfdl:defineVariable Annotation Element  PAGEREF _Toc165626383 \h 33  HYPERLINK \l "_Toc165626384" 7.8 The dfdl:setVariable Annotation Element  PAGEREF _Toc165626384 \h 33  HYPERLINK \l "_Toc165626385" 7.8.1 Short Form Syntax for Variable Assignment  PAGEREF _Toc165626385 \h 34  HYPERLINK \l "_Toc165626386" 7.9 The dfdl:defineProperty annotation element  PAGEREF _Toc165626386 \h 34  HYPERLINK \l "_Toc165626387" 8 Expression language  PAGEREF _Toc165626387 \h 34  HYPERLINK \l "_Toc165626388" 8.1 Expression Language Data Model  PAGEREF _Toc165626388 \h 34  HYPERLINK \l "_Toc165626389" 8.2 Location Paths  PAGEREF _Toc165626389 \h 34  HYPERLINK \l "_Toc165626390" 8.3 Predicates  PAGEREF _Toc165626390 \h 35  HYPERLINK \l "_Toc165626391" 8.4 True and False  PAGEREF _Toc165626391 \h 35  HYPERLINK \l "_Toc165626392" 8.5 Property-Valued Expressions  PAGEREF _Toc165626392 \h 35  HYPERLINK \l "_Toc165626393" 8.6 Variable-Valued Expressions  PAGEREF _Toc165626393 \h 35  HYPERLINK \l "_Toc165626394" 8.7 Regular Expression Matching  PAGEREF _Toc165626394 \h 35  HYPERLINK \l "_Toc165626395" 8.8 Dynamic Representation Properties  PAGEREF _Toc165626395 \h 36  HYPERLINK \l "_Toc165626396" 9 Scoping Rules  PAGEREF _Toc165626396 \h 36  HYPERLINK \l "_Toc165626397" 9.1 Annotation Positioning  PAGEREF _Toc165626397 \h 37  HYPERLINK \l "_Toc165626398" 9.2 Annotation Overloading  PAGEREF _Toc165626398 \h 38  HYPERLINK \l "_Toc165626399" 9.3 Annotation Overriding  PAGEREF _Toc165626399 \h 38  HYPERLINK \l "_Toc165626400" 9.4 Scoping of Type References  PAGEREF _Toc165626400 \h 39  HYPERLINK \l "_Toc165626401" 9.5 Scoping of Element and Group References  PAGEREF _Toc165626401 \h 39  HYPERLINK \l "_Toc165626402" 9.6 Scoping of Type Derivations  PAGEREF _Toc165626402 \h 40  HYPERLINK \l "_Toc165626403" 9.7 Scope Resolution Rules for Format Properties  PAGEREF _Toc165626403 \h 41  HYPERLINK \l "_Toc165626404" 10 Semantics  PAGEREF _Toc165626404 \h 44  HYPERLINK \l "_Toc165626405" 10.1 DFDL Parser and Unparser  PAGEREF _Toc165626405 \h 45  HYPERLINK \l "_Toc165626406" 10.2 Unparsing Must be Unambiguous  PAGEREF _Toc165626406 \h 45  HYPERLINK \l "_Toc165626407" 10.3 Parser Specification Overview  PAGEREF _Toc165626407 \h 45  HYPERLINK \l "_Toc165626408" 10.4 DFDL Logical Parse Function  PAGEREF _Toc165626408 \h 46  HYPERLINK \l "_Toc165626409" 10.4.1 Context  PAGEREF _Toc165626409 \h 47  HYPERLINK \l "_Toc165626410" 10.4.2 Variable Memory  PAGEREF _Toc165626410 \h 47  HYPERLINK \l "_Toc165626411" 10.4.3 Position and Length  PAGEREF _Toc165626411 \h 50  HYPERLINK \l "_Toc165626412" 10.4.3.1 Value and Element Start Position, Length, and End Position  PAGEREF _Toc165626412 \h 50  HYPERLINK \l "_Toc165626413" 10.4.3.2 Dynamic Extent  PAGEREF _Toc165626413 \h 50  HYPERLINK \l "_Toc165626414" 11 Parsing Functions  PAGEREF _Toc165626414 \h 50  HYPERLINK \l "_Toc165626415" 11.1 General Parse Processing - P  PAGEREF _Toc165626415 \h 50  HYPERLINK \l "_Toc165626416" 11.2 Assertion Evaluation  PAGEREF _Toc165626416 \h 51  HYPERLINK \l "_Toc165626417" 11.3 Element Declaration - E  PAGEREF _Toc165626417 \h 52  HYPERLINK \l "_Toc165626418" 11.4 Sequence Groups - G  PAGEREF _Toc165626418 \h 53  HYPERLINK \l "_Toc165626419" 11.4.1 Ordered Sequence Groups  PAGEREF _Toc165626419 \h 53  HYPERLINK \l "_Toc165626420" 11.4.2 Unordered Sequence Groups  PAGEREF _Toc165626420 \h 54  HYPERLINK \l "_Toc165626421" 11.5 Optional - O  PAGEREF _Toc165626421 \h 55  HYPERLINK \l "_Toc165626422" 11.6 Array - A  PAGEREF _Toc165626422 \h 55  HYPERLINK \l "_Toc165626423" 11.7 Parse Strategy Selection Algorithm for Elements, Arrays, Optionals, and Groups  PAGEREF _Toc165626423 \h 57  HYPERLINK \l "_Toc165626424" 11.8 Choice - C  PAGEREF _Toc165626424 \h 58  HYPERLINK \l "_Toc165626425" 11.8.1 Resolvable Choices  PAGEREF _Toc165626425 \h 58  HYPERLINK \l "_Toc165626426" 11.8.2 Unresolvable Choice  PAGEREF _Toc165626426 \h 59  HYPERLINK \l "_Toc165626427" 11.9 Rewrite R  PAGEREF _Toc165626427 \h 60  HYPERLINK \l "_Toc165626428" 11.9.1 Any Element Wildcard  PAGEREF _Toc165626428 \h 60  HYPERLINK \l "_Toc165626429" 11.9.1.1 Strict Any-Element Wildcard in Ordered Group  PAGEREF _Toc165626429 \h 60  HYPERLINK \l "_Toc165626430" 11.9.1.2 Lax Element Wildcard in Ordered Group  PAGEREF _Toc165626430 \h 61  HYPERLINK \l "_Toc165626431" 11.9.1.3 Skip Element Wildcard in Ordered Group  PAGEREF _Toc165626431 \h 61  HYPERLINK \l "_Toc165626432" 11.9.1.4 Any Element Wildcard in Unordered Group  PAGEREF _Toc165626432 \h 62  HYPERLINK \l "_Toc165626433" 11.9.2 Element Reference  PAGEREF _Toc165626433 \h 62  HYPERLINK \l "_Toc165626434" 11.9.3 Group Reference  PAGEREF _Toc165626434 \h 62  HYPERLINK \l "_Toc165626435" 11.10 Complex Type Definition T  PAGEREF _Toc165626435 \h 62  HYPERLINK \l "_Toc165626436" 11.11 Simple Types - S  PAGEREF _Toc165626436 \h 62  HYPERLINK \l "_Toc165626437" 11.11.1 Length Strategies  PAGEREF _Toc165626437 \h 62  HYPERLINK \l "_Toc165626438" 11.11.2 Conversions  PAGEREF _Toc165626438 \h 63  HYPERLINK \l "_Toc165626439" 11.11.2.1 Conversion Search Algorithm  PAGEREF _Toc165626439 \h 64  HYPERLINK \l "_Toc165626440" 11.11.2.2 Conversion specifications  PAGEREF _Toc165626440 \h 64  HYPERLINK \l "_Toc165626441" 12 Value Calculation, Representation Calculation  PAGEREF _Toc165626441 \h 65  HYPERLINK \l "_Toc165626442" 13 Kernel DFDL  PAGEREF _Toc165626442 \h 65  HYPERLINK \l "_Toc165626443" 14 External Control of the DFDL Processor  PAGEREF _Toc165626443 \h 66  HYPERLINK \l "_Toc165626444" 15 Completeness and Default-values for Representation Properties  PAGEREF _Toc165626444 \h 66  HYPERLINK \l "_Toc165626445" 16 Core Properties Detail  PAGEREF _Toc165626445 \h 67  HYPERLINK \l "_Toc165626446" 16.1 Properties that describe physical representation  PAGEREF _Toc165626446 \h 67  HYPERLINK \l "_Toc165626447" 16.1.1 Properties common to many physical representations  PAGEREF _Toc165626447 \h 68  HYPERLINK \l "_Toc165626448" 16.1.2 Properties specific to physical representation text  PAGEREF _Toc165626448 \h 70  HYPERLINK \l "_Toc165626449" 16.1.2.1 Properties Specific to text String Logical Types Only  PAGEREF _Toc165626449 \h 71  HYPERLINK \l "_Toc165626450" 16.1.2.2 Properties specific to text number logical types only  PAGEREF _Toc165626450 \h 71  HYPERLINK \l "_Toc165626451" 16.1.2.3 Properties specific to text boolean logical types only  PAGEREF _Toc165626451 \h 71  HYPERLINK \l "_Toc165626452" 16.1.3 Properties specific to physical representation binaryInteger  PAGEREF _Toc165626452 \h 72  HYPERLINK \l "_Toc165626453" 16.1.4 Properties specific to physical representation binaryFloat  PAGEREF _Toc165626453 \h 72  HYPERLINK \l "_Toc165626454" 16.1.5 Properties specific to physical representation binaryStream  PAGEREF _Toc165626454 \h 72  HYPERLINK \l "_Toc165626455" 16.1.6 Properties specific to physical representation xml  PAGEREF _Toc165626455 \h 73  HYPERLINK \l "_Toc165626456" 16.1.7 Number Scheme properties  PAGEREF _Toc165626456 \h 73  HYPERLINK \l "_Toc165626457" 16.2 Properties independent of physical representation  PAGEREF _Toc165626457 \h 75  HYPERLINK \l "_Toc165626458" 16.2.1 General properties  PAGEREF _Toc165626458 \h 75  HYPERLINK \l "_Toc165626459" 16.2.2 Properties for text markup  PAGEREF _Toc165626459 \h 75  HYPERLINK \l "_Toc165626460" 16.2.3 Properties for aligned data  PAGEREF _Toc165626460 \h 76  HYPERLINK \l "_Toc165626461" 16.2.4 Properties for repeating data  PAGEREF _Toc165626461 \h 77  HYPERLINK \l "_Toc165626462" 16.2.5 Properties for null and default value handling  PAGEREF _Toc165626462 \h 78  HYPERLINK \l "_Toc165626463" 16.2.6 Escape Scheme properties  PAGEREF _Toc165626463 \h 81  HYPERLINK \l "_Toc165626464" 17 Parse Strategies, Length Strategies, and Conversions  PAGEREF _Toc165626464 \h 82  HYPERLINK \l "_Toc165626465" 17.1 Common Functions  PAGEREF _Toc165626465 \h 82  HYPERLINK \l "_Toc165626466" 17.1.1 Function characterWidth()  PAGEREF _Toc165626466 \h 82  HYPERLINK \l "_Toc165626467" 17.1.2 Function LEX Lexical Analyzer  PAGEREF _Toc165626467 \h 83  HYPERLINK \l "_Toc165626468" 17.1.3 Function REGEXP Regular expression extractor  PAGEREF _Toc165626468 \h 83  HYPERLINK \l "_Toc165626469" 17.2 Length Strategy Examples  PAGEREF _Toc165626469 \h 84  HYPERLINK \l "_Toc165626470" 17.3 Conversion Examples  PAGEREF _Toc165626470 \h 86  HYPERLINK \l "_Toc165626471" 17.4 Element Parse Strategy Examples  PAGEREF _Toc165626471 \h 86  HYPERLINK \l "_Toc165626472" 17.4.1 Basic Binary Element Strategy  PAGEREF _Toc165626472 \h 87  HYPERLINK \l "_Toc165626473" 17.4.2 Alignment  PAGEREF _Toc165626473 \h 87  HYPERLINK \l "_Toc165626474" 17.4.3 Skip Bytes  PAGEREF _Toc165626474 \h 88  HYPERLINK \l "_Toc165626475" 17.5 Optional Element Parse Strategies  PAGEREF _Toc165626475 \h 89  HYPERLINK \l "_Toc165626476" 17.5.1 Optional by Initiator Tag  PAGEREF _Toc165626476 \h 89  HYPERLINK \l "_Toc165626477" 17.5.2 Input Default, Null, Missing, Optional Flow Charts  PAGEREF _Toc165626477 \h 91  HYPERLINK \l "_Toc165626478" 18 Clarifying Examples  PAGEREF _Toc165626478 \h 94  HYPERLINK \l "_Toc165626479" 18.1 Clarifying Examples - Opaque and HexBinary  PAGEREF _Toc165626479 \h 94  HYPERLINK \l "_Toc165626480" 18.1.1 String Type  PAGEREF _Toc165626480 \h 94  HYPERLINK \l "_Toc165626481" 18.1.2 HexBinary Type  PAGEREF _Toc165626481 \h 95  HYPERLINK \l "_Toc165626482" 18.1.3 Byte Array type  PAGEREF _Toc165626482 \h 95  HYPERLINK \l "_Toc165626483" 18.1.4 Opaque 'any' wildcard type  PAGEREF _Toc165626483 \h 96  HYPERLINK \l "_Toc165626484" 19 Built-in Specifications  PAGEREF _Toc165626484 \h 96  HYPERLINK \l "_Toc165626485" 20 Properties Supported by Specialized Annotation Elements  PAGEREF _Toc165626485 \h 96  HYPERLINK \l "_Toc165626486" 21 Security Considerations  PAGEREF _Toc165626486 \h 98  HYPERLINK \l "_Toc165626487" 22 Contributors  PAGEREF _Toc165626487 \h 98  HYPERLINK \l "_Toc165626488" 23 Intellectual Property Statement  PAGEREF _Toc165626488 \h 98  HYPERLINK \l "_Toc165626489" 24 Disclaimer  PAGEREF _Toc165626489 \h 99  HYPERLINK \l "_Toc165626490" 25 Full Copyright Notice  PAGEREF _Toc165626490 \h 99  HYPERLINK \l "_Toc165626491" 26 References  PAGEREF _Toc165626491 \h 99  HYPERLINK \l "_Toc165626492" 27 Appendix: About UTF-16 and Unicode Character Codes above 0xFFFF  PAGEREF _Toc165626492 \h 100  HYPERLINK \l "_Toc165626493" 28 TBD: Extra Material and Misc Parse Topics  PAGEREF _Toc165626493 \h 102  HYPERLINK \l "_Toc165626494" 28.1.1 Textual Data where lengthUnits='characters'  PAGEREF _Toc165626494 \h 102  HYPERLINK \l "_Toc165626495" 28.1.2 String Length Given in Bytes  PAGEREF _Toc165626495 \h 104  HYPERLINK \l "_Toc165626496" 28.2 Binary type length protocol  PAGEREF _Toc165626496 \h 104  HYPERLINK \l "_Toc165626497" 28.2.1 S7 Delimited Scan Length Protocol and Escape Schemes  PAGEREF _Toc165626497 \h 104  HYPERLINK \l "_Toc165626498" 28.2.2 Fixed Size  PAGEREF _Toc165626498 \h 105  HYPERLINK \l "_Toc165626499" 28.3 Parsing an Optional Element of a Group  PAGEREF _Toc165626499 \h 105  HYPERLINK \l "_Toc165626500" 28.4 Parsing Groups and Arrays Using the Length Protocol  PAGEREF _Toc165626500 \h 105  HYPERLINK \l "_Toc165626501" 28.4.1 Regular Expression Length and End-of-Data Delimiter  PAGEREF _Toc165626501 \h 106  HYPERLINK \l "_Toc165626502" 28.4.2 End-of-Data Termination  PAGEREF _Toc165626502 \h 106  HYPERLINK \l "_Toc165626503" 28.4.3 Scanability  PAGEREF _Toc165626503 \h 106  HYPERLINK \l "_Toc165626504" 28.4.3.1 Nests of Specified Length within Delimited Constructs  PAGEREF _Toc165626504 \h 106  HYPERLINK \l "_Toc165626505" 28.4.4 Groups and Arrays: Delimited Length and Terminators  PAGEREF _Toc165626505 \h 107  HYPERLINK \l "_Toc165626506" 28.4.5 Arrays with lengthUnits="items"  PAGEREF _Toc165626506 \h 107  HYPERLINK \l "_Toc165626507" 29 TBD: Misc Default Value, Null Values, and Optional Data  PAGEREF _Toc165626507 \h 107  HYPERLINK \l "_Toc165626508" 29.1 Definitions  PAGEREF _Toc165626508 \h 107  HYPERLINK \l "_Toc165626509" 29.2 Examples  PAGEREF _Toc165626509 \h 109  HYPERLINK \l "_Toc165626510" 29.3 Defaults values on input and output  PAGEREF _Toc165626510 \h 111  HYPERLINK \l "_Toc165626511" 29.4 Default Values on input without null values being considered  PAGEREF _Toc165626511 \h 112  HYPERLINK \l "_Toc165626512" 29.5 Null Handling on input without default values being considered  PAGEREF _Toc165626512 \h 114  HYPERLINK \l "_Toc165626513" 29.6 Using both Default Values and Null Handling on input  PAGEREF _Toc165626513 \h 116  HYPERLINK \l "_Toc165626514" 29.7 Default Values on output without null values being considered  PAGEREF _Toc165626514 \h 116  HYPERLINK \l "_Toc165626515" 29.8 Null Handling on output without default values being considered  PAGEREF _Toc165626515 \h 116  HYPERLINK \l "_Toc165626516" 29.9 Flowcharts for Null and Default Behaviour  PAGEREF _Toc165626516 \h 117  HYPERLINK \l "_Toc165626517" 29.9.1 Output Flowcharts  PAGEREF _Toc165626517 \h 118  HYPERLINK \l "_Toc165626518" 30 Parse Strategies for Elements, Arrays, Optionals, and Groups  PAGEREF _Toc165626518 \h 121  HYPERLINK \l "_Toc165626519" 30.1 Sequence Group Parse Strategies  PAGEREF _Toc165626519 \h 121  HYPERLINK \l "_Toc165626520" 30.2 Grammar of DFDL-described data  PAGEREF _Toc165626520 \h 121  HYPERLINK \l "_Toc165626521" 30.2.1 Position by Offset  PAGEREF _Toc165626521 \h 122  HYPERLINK \l "_Toc165626522" 31 Misc Grammar Bits  PAGEREF _Toc165626522 \h 122  HYPERLINK \l "_Toc165626523" 31.1.1 Base Parse Strategy binary sequence group  PAGEREF _Toc165626523 \h 123  HYPERLINK \l "_Toc165626524" 31.1.2 Base Parse Strategy delimited text ordered-sequence group (G)  PAGEREF _Toc165626524 \h 124  HYPERLINK \l "_Toc165626525" 31.2 Array Parse Strategies  PAGEREF _Toc165626525 \h 125  HYPERLINK \l "_Toc165626526" 31.2.1 Length Methods for Arrays/Vectors  PAGEREF _Toc165626526 \h 125  HYPERLINK \l "_Toc165626527" 31.2.2 Properties Affecting Length of Simple Types  PAGEREF _Toc165626527 \h 127  HYPERLINK \l "_Toc165626528" 31.2.3 Length Methods for Scalar Simple Types  PAGEREF _Toc165626528 \h 127  TBD: Hints to Authors and Editors Write in the present tense. We are describing how DFDL IS defined, not how it "Will be" defined someday. Many more people will see this document once DFDL is complete than while it is in formulation. Please put in lots of TBDs and/or comments about things unresolved or unclear. Please put the letters "TBD" in notes to the authors/editors, not "TODO" or other markers. Move discussion of design alternatives and rationale for why things were decided into separate sections which are put in the Appendices in the back matter. Eventually we'll move these out to a separate document for safekeeping. Standardize terminology: use 'element' instead of 'field', 'item', 'object etc. Use 'item' as the generalization from element to elements and other things such as model groups. Any property that can have empty string as its value must say so in the documentation of the property. E.g., separator. List of Changes still needed throughout: Code Examples: use style 'codeblock' indent 2 spaces per level use all spaces, not tabs colorize per our standard color scheme to emphasize the important bits. (are we happy with the colorization in the scoping part? I'd propose that as a standard) no outline frames around them. Change discussions of boolean true like "non-null node not equal to FALSE" to just say 'true'. since we have a central discussion of what true and false are for expressions now. Change all the "Is an error and DFDL Processors must fail" to specify just 'is a schema definition error', or "is a processing error". Introduction Data interchange is critically important for Grid computing. Grid computing is about getting distributed software and hardware resources to work together. Inevitably these resources read and write data in different formats. General tools for data interchange are essential to solving such problems. Grid computing is also at least partly about high-performance including high-performance data handling. DFDL enables powerful data interchange as well as very high-performance data handling for the Grid. We envisage 3 dominant kinds of data in the future: Textual XML data. Binary data in standard formats. Data with DFDL descriptors Textual XML data is the most successful data interchange standard to date. All such data is by definition new, by which we mean created in the XML era. In addition it is usually small data because of the large overhead that XML tagging imposes and the high-cost of compression and decompression. Standardized binary data is also relatively new, and is more reasonable for larger data because of the reduced costs of encoding and more compact size. Examples standard binary formats are data described by modern versions of ASN.1, or the use of XDR. These techniques lack the self-describing nature of XML-data. Scientific formats such as NetCDF and HDF are used in some communities provide self-describing binary data. In the future there may be binary-encoded XML data as there is a w3c working group that has been formed on this subject. It is an important observation that both XML format and standardized binary formats are prescriptive in that they specify or prescribe a representation of the data. To use them your applications must be written to conform to their encodings and mechanisms of expression. DFDL suggests an entirely different scheme. The approach is descriptive in that one chooses an appropriate data representation for an application based on its needs and one then describes the format using DFDL so that multiple programs can directly interchange the described data. DFDL descriptions can be provided by the creator of the format, or developed as needed by third parties intending to use the format. That is, DFDL is not a format for data; it is a way of describing any data format. DFDL is intended for data commonly found in all kinds of calculations including scientific and numeric computations as well as the record-oriented representations found in commercial data processing. DFDL can be used to describe legacy data files, to simplify transfer of data across domains without requiring global standard formats, or to allow third-party tools to easily access multiple formats. DFDL can also be a powerful tool for supporting backward compatibility as formats evolve. DFDL is designed to provide this flexibility but to admit implementations to achieve very high levels of performance. DFDL descriptions are separable and native applications do not need to use DFDL libraries to parse their data formats. DFDL parsers can also be highly efficient. The DFDL language is designed to admit implementations that use lazy evaluation of formats and to support seekable, random access to data. The following goals are achievable by DFDL implementations: Density: fewest bytes to represent information content (without resorting to compression). Fastest possible I/O. Optimized I/O. Applications can write data aligned to byte, word, or even page boundaries and to use memory-mapped I/O to insure access to data content with the smallest number of machine cycles for common use cases without sacrificing general access. DFDL can describe the same kinds of abstract data that other binary or textual data formats can describe, but can go further and describe almost any possible representation scheme for them, For example, DFDL can provide multiple representations for the same logical data but that are optimized for specific uses. It is the spirit of DFDL to support canonical data descriptions that correspond closely to the original in-memory representation of the data, and also to provide sufficient information to write as well as to read the given format. Why is DFDL Needed? Many people ask why DFDL is needed in an era where there are so many standard data formats available. There are a number of social phenomena in the way software is developed which have lead to the current situation where DFDL is needed to standardize description of diverse data formats. First, programs are very often written speculatively, that is, without any advance understanding of how important they will become. Appropriately given this situation, little effort is expended on data formats since it remains easier to program the I/O in the most straightforward way possible given the programming tools in use. Even something as simple as using an XML-based data format is harder than simply using the native I/O libraries of a programming language. At some point however, it is realized that the program is important because either lots of people are using it, or it has become important for business or organizational needs to start using it in larger scale deployments. At that point it is often too late to go back and change the data formats. For example, there may be real or perceived business costs to delaying a deployment of a program for a rewrite just to change the data formats, particularly if such rewriting will reduce performance of the program and increase costs of deployment. (It takes longer to program, but at least it's slower when you are done() Additionally, the need for data format standardization for interchange with other software may not even be clear at the point where a program first becomes 'important'. Eventually, however, the need for data interchange with the program becomes apparent. The above phenomena are not something that is going away any time soon. There are of course efforts to much more smoothly integrate standardized data format handling into programming languages. Nevertheless we see a critical role for DFDL since it allows after-the-fact description of a data format. What is DFDL? DFDL is a language for describing data formats. A DFDL description allows data to be read from its native format and be presented as a logical XML model or indeed converted to the corresponding XML document. DFDL also allows data to be taken from an XML model and written out to its native format. DFDL achieves this by leveraging W3C XML Schema. An XML Schema description is written for the logical model of the data. The Schema description is then augmented with special DFDL annotations. These annotations are used to describe the native representation of the data. This is an established approach that is already being used today in commercial systems such as IBMs WebSphere Business Integrator Message Broker and Microsofts BizTalk flat file. Simple Example Consider the following XML data: 5 7839372 8.6E-200 -7.1E8 The logical model for this data can be described by the following fragment of XML Schema which simply provides descriptsions for the name and type of each element: Now, suppose we have the same data but represented in a non-XML format. A (hex encoded) binary representation of the data could look like this: 0000 0005 0077 9e8c 169a 54dd 0a1b 4a3f ce29 46f6 Now to describe this in DFDL we take our original XML Schema that described the data model and annotate it as follows: This simple DFDL annotation expresses that the data is represented in a binary format and that the byte order will be big endian. This is all that a DFDL parser needs to read the data. Similarly consider if the same data were represented in a text format: 5, 7839372, 8.6E-200, -7.1E8 Once again we can annotate the same data model, this time with properties that provide the character encoding, the field separator (comma) and the decimal separator (period): separator=","/> What DFDL is not DFDL maps data from a non-XML representation to an XML data model. This can be thought of as a data transformation. However, DFDL is not intended to be a general transformation language and in particular DFDL does not intend to provide a mechanism to map data to arbitrary XML models. There are a couple of specific limitations on the data models that DFDL can work to: DFDL uses a subset of XML Schema, in particular you cannot use XML attributes in the data model The order of the data in the data model must correspond to the order of the data that is being read. That is to say DFDL can describe data formats with unordered sequences of data and choices etc. but DFDL cannot be used to reorder the data when it is mapped from its native representation to the XML model. Scope of version 1.0 Goals: Leverage XML technology and concepts Support very efficient parsers/formatters Avoid mistake of specs which require data copying Support round-tripping i.e., read and write data in described format from same description Keep simple cases simple Simple descriptions should be "human readable" to the same degree that XSD is. General Features: Basic Text/Binary data capabilities Inclusion of static info, e.g. units Validated input (from XML Schema) Defaulted input for missing values Reference use of a previously read value in subsequent expressions Choice use of a previously read value to select among format variations Multi-layer description of an intermediate representation not exposed in the final result Basic Math in DFDL expressions Very general parsing capability: Lookahead/Push-back Extensibility New type/transform specification Version 1.0 of DFDL is a language capable of expressing a wide array of binary and text-based data formats. DFDL is capable of describing binary data as found in the data structures of Cobol, C, PL1, Fortran, etc. In particular, it is able to describe repeating sub-arrays where the length of an array is stored in another location of the structure. DFDL is capable of describing a wide variety of textual data formats. These include TBD:list of examples. TBD: mixtures. Composition properties. I.e., two formats can be nested, concatenated, etc. The following topics have been deferred to future versions of the standard: Extensibility: There are real examples of proprietary data format description languages that we use as our base of experience from which to derive standard DFDL. However, there are no examples of extensible format description languages; hence, while extensibility is desirable in DFDL, there is not yet a base of experience with extensibility from which to derive a standard. Layering: Some formats require data to be described in multiple layers. That is, where one element's contents becomes the representation of another element. DFDL V1.0 allows description of only one layer. Related standards Prescriptive systems: W3C binary XML (http://www.w3.org/XML/Binary/) Descriptive systems: ASN1 Encoding Control Notation ITU-T X.692 Notational and Definitional Conventions The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this Working Draft are to be interpreted as described in [ HYPERLINK "http://www.oasis-open.org/committees/download.php/4952/wd-entity-xml-catalogs-1.0_2e.html" \l "rfc2119" RFC 2119]. Note that for reasons of style, these words are not capitalized in this document. Failure Types Herein where the phrase "must be consistent with" is used, it is assumed that a conforming DFDL implementation must check for the consistency and issue appropriate diagnostic messages and fail when an inconsistency is discovered. There are several kinds of failures that can occur when a DFDL processor is handling data and/or a DFDL schema. Schema Definition Error When the DFDL schema itself contains an error, it implies that the DFDL processor cannot process data because the DFDL schema itself is not meaningful. It may be ambiguous, or contain conflicting definitions. Equivalently, we can say that there is no possible data that conforms to the schema; hence, the schema cannot be meaningful. All conforming DFDL processors must detect all schema definition errors, and must fail and will typically issue some kind of appropriate diagnostic message. The DFDL schema cannot mask or otherwise continue after a schema definition error is detected. It is desirable, though not required by the DFDL standard, that Schema definition errors be able to be detected given only the schema. That is, these should be statically determined given the content of the schema only. Processing Errors: Parse Error, Unparse Error If a DFDL schema contains no schema definition errors, then there is the additional possibility that when processing data using a DFDL schema, the data itself does not conform to the format described by the schema. In the input direction this is known as a parse error. In the output direction an unparse error. In addition, using the expression language of DFDL, it is possible to have runtime errors (for example, mathematical underflow or division by zero). These are also processing errors, and can be classified as parse or unparse errors depending on the action of the DFDL processor at the time of the error. Parse errors can be suppressed by certain uses of the choice construct. See section (TBD: xref to choice). We will use the phrase suppressed parse error to describe this situation. A parse error that is not suppressed in this way is an effective parse error. DFDL does not describe the behavior of parsers when effective parse errors occur. It is expected that DFDL implementations will provide a variety of mechanisms for dealing with effective parse errors such as means of specifying retry points or means of skipping some data so as to recover from the error in some way. Note that neither schema definition errors nor validation errors can ever be suppressed in this manner. DFDL assertions used to discriminate a choice or other point of uncertainty will cause parse errors if any error occurs during their evaluation.  Validation Errors Logical validation errors are constraints expressed in XSD and they apply to the logical content of the model. DFDL processors may provide both validating and non-validating behaviors on either or both of parse and unparse. (A DFDL implementation could support validate on parse, but not support it on unparse and still be considered conforming.) This implies that validation errors cannot affect the ability of a DFDL processor to successfully parse or unparse data. The behavior of a DFDL processor when a validation error occurs is not specified by the DFDL language. An unparse validation error is defined in terms of a parse validation error. Specifically, an unparse validation error occurs when the physical representation being output would generate a validation error on parsing using the same DFDL schema. Unlike parse errors, the DFDL choice construct can not be used to suppress validation errors. The following DFDL schema constructs are checked for validation: DFDL Assertions (these are always evaluated. Not only when validation is used.) XSD pattern facet XSD minOccurs, maxOccurs for variable-length data, and for fixed length data when the number of occurrences can be determined from markup in the representation. XSD minLength, maxLength (note: length should be used for fixed length case) XSD minInclusive, minExclusive, maxInclusive, maxExclusive XSD enumeration When a DFDL assertion is used to discriminate a choice or other point of uncertainty when parsing, that assertion, which is called a discriminator, is essential to parsing and it is evaluated irrespective of whether validation is enabled or disabled. It is a processing error, specifically a parse error if any error occurs when evaluating a discriminator during parsing. Glossary DFDL Data Format Description Language Data Item, or Item - Used to describe part of the data described by part of the schema. Can be an element, or can be a part of the data described by the other schema constructs. Data Element, or Element - Used to describe part of the data described by an element declaration in the schema. We avoid confusion with the schema constructs for describing elements by describing the schema constructs as element declarations. Byte - The term byte herein refers to an 8-bit octet. DFDL Processor - A program that uses DFDL descriptors in order to process data described by them. DFDL Schema - an XML Schema containing DFDL annotations to describe data format. Array - An XML element whose XSD element declaration specifies the potential for it to have more than one occurrence. An optional element (maxOccurs=1, minOccurs=0) is not considered to be an array as described in this document. An array has either minOccurs and maxOccurs both > 1, or has minOccurs=0, and maxOccurs > 1. Of course any given array instance can have any number of elements, including zero elements or exactly 1 element. Optional Element - this term refers to an element with maxOccurs=1, and minOccurs=0. Implied XML Schema - The XML Schema that results from erasing all DFDL annotations in an DFDL Schema. An obvious application of DFDL technology is to convert data back and forth between a DFDL-described format and XML data described by the corresponding implied XML schema. Rep. Prop. Or Rep property an abbreviation of representation property. Physical layer A DFDL Schema adds format annotations onto a XSD language schema. The annotations describe the physical representation or physical layer of the data. Logical layer - A DFDL Schema with all the DFDL annotations erased is an ordinary XSD language schema. The logical structure described by this XSD is called the DFDL logical layer. Format Annotations - the syntactic elements by which format information is decorated onto XML Schemas Format Properties - the attributes on format annotations which specify characteristics of data format. These are distinguished from the control attributes on format annotations which control whether the annotations are to be used as a whole, or the scoping of those annotations over what parts of the XML Schema. Full Schema - The set of all declarations and definitions in the schema, including all included and imported schemas taken together. This includes both the XSD declarations and definitions, and the DFDL definitions provided in the top-level DFDL annotations. Contiguous - An element has a contiguous representation if all parts of its representation are adjacent in the input/output stream. Most simple types have contiguous representations naturally. Groups containing elements that are themselves contiguous are also considered to have contiguous representations irrespective of alignment fill or padding of any kind that exists within the group. Similarly, arrays containing elements that are themselves contiguous are also contiguous. Adjacent - Two parts of the input/output stream are adjacent if they are at consecutive addresses. Addressable Unit, or Unit - This is the unit of storage that makes up the input or output stream holding the representation of the data. Commonly the units are bits, bytes, or characters. Scalar Not an array. Specifically maxOccurs=1 and minOccurs=1 (or both are defaulted). Note specifically that sequence groups and choice groups can be scalar or array. Scalar is not to be confused with 'simple'. Scalar is only about the dimensionality of the data, not its complexity/simplicity. Array Having maxOccurs > 1 and minOccurs <= maxOccurs. Note that a sequence is not to be confused with an array. A sequence is a kind of group which is about the type of the element, not the dimensionality. Note that arrays always have the potential to have more than 1 element. Optional - Having maxOccurs = 1 and minOccurs = 0. Note that an optional element is not an array. Outline of the Specification This document is organized as follows: Language basics syntax scoping and context expressions variables layering Detailed semantics properties and conversions Built-in specifications DFDL Information Model When using DFDL, the format of data in a data stream, file, buffer or other is described by means of a DFDL Schema. Data described by DFDL schemas obeys the DFDL Information Model. The DFDL Information Model is shown in conceptual UML below. First the model for elements, groups, wildcards and the top of the type hierarchy:  EMBED PowerPoint.Slide.8  The simple types are shown below. The graph shows all the types defined by XML Schema version 1.0, and the subset of these types supported by DFDL are shown in green.  These types are defined as they are in XML Schema, with exceptions for: String In DFDL a string can contain any character codes. None are reserved. (Including particularly, the character with character code 0, which is not allowed in XML documents.) HexBinary In DFDL the HexBinary type is used for opaque binary "blob" types. In the DFDL information model, this type is used to represent opaque binary data. We express the DFDL Information Model for data using a subset of the XML Schema Description Language (XSD). XSD provides a standardized schema language suitable for capturing hierarchical data models such as the DFDL Information Model. A DFDL Schema is an XML Schema containing only a restricted subset of the constructs available in full W3C XML Schema Description Language. Within this XML Schema, special DFDL annotations are distributed which carry the information about the data format or representation. A DFDL Schema is a valid XML Schema. However, the converse is not true since the DFDL Information Model does not include many concepts that appear in XML Schema. DFDL Subset of XML Schema The DFDL subset of XSD is a general model for hierarchically-nested data. It lacks the XSD features used to describe the peculiarities of XML as a syntactic textual representation of data. The following lists detail the similarities and differences between general XSD and this subset. DFDL Schemas consist of: standard XSD namespace management standard XSD import and include management for multiple file schemas local element declarations with optional dimensionality via maxOccurs and minOccurs. global element declarations complexType definitions DFDL appinfo annotations describing the data format These simple types: string, float, double, decimal, integer, long, int, short, byte, unsignedLong, unsignedInt, unsignedShort, unsignedByte, boolean, date, time, dateTime, duration, hexBinary 'sequence' groups 'choice' groups simple type derivations Reusable Groups: named model groups Element references with optional dimensionality via maxOccurs and minOccurs. Group references without dimensionality xs:any element wildcards (Note that the id attribute optional in XSD is required in DFDL) xs:nillable="true" only on elements of simple type. The following constructs from XML Schema are not used as part of the DFDL Information Model of DFDL v1.0 schemas; however, they are all reserved for future use since the data model may be extended to use them in future versions of DFDL. By reserved we mean that conforming DFDL v1.0 implementations MAY NOT assign semantics to them. (TBD: need means for an implementation to indicate it is using non-standard extensions?) Attribute declarations (local or global) Attribute references Attribute groups complexType derivations Union and list simple types These atomic simple types: normalizedString, token, Name, NCName, QName, language, positiveInteger, nonPositiveInteger, negativeInteger, nonNegativeInteger, gYear, gYearMonth, gMonth, gMonthDay, gDay, ID, IDREF, IDREFS, ENTITIES, NMTOKEN, NMTOKENS, NOTATION, anyURI maxOccurs and minOccurs on non-elements (that is, model groups) Identity Constraints Substitution Groups 'all' groups Redefine - This version of DFDL does not support xsd:redefine. DFDL schemas may not contain xsd:redefine directly or indirectly in schemas they import or include. nillability on elements of complex type. Syntax Basics Using DFDL, a data format is described by placing special annotations at various positions within an XML schema. This XML schema conveys the basic structure of the data format, while the annotations fill in the detail. Annotations are used to describe aspects such as the file encoding and byte ordering, as well as declaring variables for reference elsewhere, and specifying properties that govern the capabilities of the DFDL processor. A DFDL processor requires these annotations, along with the structural information of the enclosing XML schema, to make sense of the logical data model. It is generally required throughout a DFDL Schema that all DFDL annotations are syntactically well formed. It is a schema definition error if they are not. Elsewhere in this specification it is assumed that any annotations are well formed. Namespaces To distinguish DFDL annotations from other annotations the xs:appinfo source URI  HYPERLINK "http://dataformat.org/" http://dataformat.org/ is used. The element and attribute names in the DFDL syntax are in a namespace defined by the URI  HYPERLINK "http://dataformat.org/dfdl-1.0" http://dataformat.org/dfdl-1.0. All symbols in this namespace are reserved. DFDL implementations may not provide extensions to the DFDL standard using names in this namespace. The standard and recommended namespace prefix for DFDL is dfdl and this will be used throughout this standard to refer to the namespace  HYPERLINK "http://dataformat.org/dfdl-1.0" http://dataformat.org/dfdl-1.0. The content of the DFDL annotations, that is, the attributes and sub-elements of the DFDL annotation elements, are specified by an XML schema which is described in this document, and available for validation from  HYPERLINK "http://dataformat.org/dfdl-1.0/dfdl.xsd" http://dataformat.org/dfdl-1.0/dfdl.xsd TBD: someday it will be available there. TBD: best to make it available for download from a web site, but not actually put it on the web at that location or everyone's processors will be actually probing that web address to try to get it live. A DFDL Schema contains XML Schema annotation elements which define and assign names to parts of the format specification. These names are defined in the target namespace of the schema where they reside. (They may NOT be qualified to put them in a different namespace than the target namespace.) A DFDL schema can include or import another schema, and namespaces work in the usual manner for XML schemas. The full schema is the schema including all additional schemas referenced through import and include. The DFDL Annotation Elements DFDL annotations may be positioned wherever annotations are allowed within an XML Schema document. These positions are known as annotation points. When an annotation is positioned at an annotation point, it binds some additional information to the schema element that encloses it. For instance, an annotation could be used to bind a UTF-8 encoding to a userName element. The description of a data format is achieved by correctly binding annotations to the structural elements of the XML schema. DFDL specifies a collection of annotations for different purposes. These are described in  REF _Ref157419914 \h Table 1. Table  SEQ Table \* ARABIC 1 - DFDL Annotation Elements Annotation ElementDescriptionassertDefines an assertion to use for predicate testing to resolve uncertainties such as choice branches.defineFormatDefines a reusable data format by collecting together other annotations and associating them with a name that can be referenced from elsewhere.defineVariableDefines a variable that can be referenced elsewhere. This can be used to communicate a parameter from an earlier part of a schema to a later part.definePropertyDefines a new property that can be referenced in expressions.escapeSchemeDefines the scheme by which quotation marks and escape characters can be specified. This is for use with delimited text formats.formatDefines the data format properties that apply to part of the logical data models. This includes aspects such as the encodings, field separator, and many more.hiddenDefines a hidden element that appears in the schema for use by the DFDL processor, but is not part of the logical data model described by the schema.numberSchemeDefines the format (scheme?) used for expressing numbers in the logical data model. This includes aspects such as radix, field separators, digit grouping separators, leading or trailing signs, etc.propertyUsed in the syntax of dfdl:format annotations. See section  REF _Ref161823626 \r \h 7.1.3.setVariableSets the value of a variable that has been defined earlier in the schema. Additional Specialized Annotation Elements Given the large number of properties, it is useful to have some specialized annotation elements that are variants of dfdl:format but which do not accept all possible representation properties. Instead these accept only the subset of the representation elements that are suitable for the matching annotated XSD construct. DFDL provides these additional specialized annotation elements: dfdl:sequence dfdl:choice dfdl:element dfdl:any These are equivalent to writing a dfdl:format annotation containing the same representation property bindings. See Section  REF _Ref161820525 \r \h 20 for a list of the properties accepted by these annotation elements. String Literals in DFDL A literal string in a DFDL Schema is written in the character set encoding specified by the XML directive that begins all XML documents: This line must be at the top of the DFDL schema. In this example, the DFDL schema is written in UTF-8, so any literal strings contained in it, and particularly string literals found in its representation property bindings in the format annotations, are expressed in UTF-8. However, these strings are being used to describe features of text data that are commonly in other character sets. E.g., we may have EBCDIC data which is comma separated. A comma in EBCDIC does not have the same character code as a Unicode comma. However, when we indicate that an item is "," (comma) separated and we specify this using a string literal along with specifying the 'encoding' property to be 'ebcdic-cp-us' then this means that the data is separated by EBCDIC commas regardless of what character set encoding is used to write the DFDL Schema. .... .... .... ..... When a DFDL processor uses the separator expressed in this manner, the string literal "," is translated into the character set encoding of the data it is separating as specified by the encoding representation property. Hence, in this case we would be searching the data for a character with codepoint 0x6B (the EBCDIC comma), not a utf-8 or Unicode (0x2C) comma which is what exists in the DFDL schema file. Hex Escape for String Literals It is sometimes more convenient to avoid character set translation and just provide the string literal required in hex form so that one can avoid having to figure out what the corresponding character is in the DFDL schema's own encoding to the character code point of interest in the encoding of the data being processed. This is particularly important for the non-printing characters where the mapping to/from the character set of the DFDL schema may be non-obvious. There is also the potential of the DFDL schema document being in a character set such as US-Ascii that simply cant represent a character which is in the data. Using hex to describe the actual code point of the character in the data allows DFDL to conveniently get around these limitations. To support hex embedding, all string literals in DFDL schemas will support this escape sequence: %HH ("H" denotes a hex digit). Inserts a single byte directly into the string literal bypassing any character set translation. Both hex digits must be present. %% - Inserts a single literal "%" into the string literal. This "%" is subject to character set translation as is any other character. Using these escape sequences one can create string literals which are a mix of text and hex-specified data. Syntax and Basic Usage of DFDL Annotation Elements This section describes the syntax of each of the DFDL annotation elements along with discussion of their basic meanings. dfdl:format: Putting Formats to Use A data format can be 'used' or put into effect for a part of the schema by use of the dfdl:format annotation element. The dfdl:format annotation element is not allowed at the top level of a schema, that is as an annotation on the xs:schema element. However, it can appear as an annotation on any declaration or definition of the schema (element, type, or group) local or global. Here is an example: ... ...everything here will have the specified representation properties ... ... Attributes of dfdl:format The dfdl:format annotation element has these special attributes: 'applies' with values 'hereOnly' or 'toScope' - used for scope control. See section  REF _Ref161823893 \r \h 11. 'ref' used to reference named formats. See Section  REF _Ref140934918 \r \h 7.2. All other attributes on dfdl:format annotation elements are representation property bindings. The concept of scoping described in this document in section  REF _Ref140935092 \r \h 11 applies only to representation property bindings and to representation properties inherited via the 'ref' attribute (see Section  REF _Ref161824338 \r \h 7.2.1). Representation Property Binding Syntax: Attribute Form Within the dfdl:format annotation elements are bindings for representation properties of the form: Property="Value" For example: repType="text" separator="," The Property is the name of the representation property. The Value is an XML string literal corresponding to a value of the appropriate type. Representation Property Binding Syntax: Element Form The representation properties can sometimes have complex syntax, so an element form for representation property bindings is provided as element content within the dfdl:format element. This is provided to ease syntactic expression difficulties: Element form looks like this: utf-8 \n ... All representation properties can have their bindings expressed in attribute form or element form. Element form is mostly used for properties that themselves contain the quotation mark characters and escape characters so that they can be expressed without concerns about confusion with the XSD syntax use of these same characters. It is a schema definition error if the same property is expressed both as an attribute and using a dfdl:property sub-element of a format annotation. There are also some representation 'properties' which always need element-based syntax. For example, see Section  REF _Ref140936368 \r \h 16.2.6  REF _Ref140936382 \h Escape Scheme properties. The dfdl:format 'applies' and 'ref' attributes, must be expressed as attributes since they are not representation properties. Short Form Syntax for Format Annotations To save textual clutter, a short-form syntax for format annotations is also allowed. Non-native attributes are examined by the DFDL processor. Those which correspond to the QNames of built-in (tbd: or user-declared) DFDL properties are assumed to be equivalent to specific DFDL long-form annotations. For example the two forms below are equivalent. The first is a short-form of the second: ... ... Another example:. Note that short form syntax can be used not only for representation property bindings, but also for the applies and ref special attributes. Empty Bindings Setting a representation property's value to the empty string doesn't remove the setting, but sets it to the empty string value. If a property is found in the context and the empty string is the value, that halts the search for the value and the returned value of the binding is the empty string value. This is only legal for some string-valued properties. For example, in delimited text representations, it is sensible for the separator to be defined to be the empty string. This turns off use of separator delimiters. For other string-valued properties, it is a schema definition error to assign them the empty string value. For example the character set encoding property cannot be set to the empty string. dfdl:defineFormat - Reusable Data Format Definitions One or more dfdl:defineFormat annotation elements can appear within the annotation children of the xsd:schema element. The dfdl:defineFormat elements may only appear as annotation children of the xs:schema element. The order of their appearance does not matter, nor does their position relative to other non-annotation children of the xsd:schema element. Each dfdl:defineFormat has a required name attribute and an optional baseFormat attribute. The construct creates a named data format definition. The value of the name attribute is of XML type NCName. The format name will become a member of the schemas target namespace. These names must be unique within the namespace. Top level defined formats are added to the DFDL processor context using their namespace-qualified names (QNames) as the identifiers. If multiple format definitions have the same 'name' attribute, in the same namespace, then it is a schema definition error. Each dfdl:defineFormat annotation element contains other format annotation elements as detailed below. Here is an example of a format definition: ... Besides the dfdl:format annotation element, a dfdl:defineFormat annotation can also contain any of the other DFDL annotation elements for purposes of giving a reusable name to a collected consistent set of definitions. A dfdl:defineFormat serves only to supply a named definition for a format for reuse from other places. It does not cause any use of the representation properties it contains to describe any actual data. The contents of the defineFormat element use restricted forms of the dfdl:format annotation elements which provide representation properties. The restrictions prohibit use of the 'ref' attribute and the 'applies' attribute. Inheritance for dfdl:defineFormat A dfdl:defineFormat declaration can inherit from another named format definition by use of the 'baseFormat' attribute. This allows a single-inheritance hierarchy which reuses definitions. When one definition extends another in this way, any property definitions contained in its direct elements override those in any inherited definition. Conceptually, the baseFormat inheritance chain can be flattened and removed by copying all inherited property bindings and then superseding those for which there is a local binding. Throughout this document we will assume baseFormat inheritance is fully flattened. That is, all baseFormat inheritance is first removed by flattening before any other examination of properties occurs. Using/Referencing a Named Format Definition A named, reusable, format definition is used by referring to its name from a dfdl:format annotation using the 'ref' attribute. For example: The behavior of this format definition is as if all representation properties defined by the named format definition were instead written directly on this dfdl:format annotation; however, these are superceded by any representation properties that are defined here such as the encoding property in the example above. The scope control applies attribute controls the scoping of the combined set of property definitions. The dfdl:assert Annotation Element DFDL assertions can be placed on elements and groups within a DFDL model. These assertions contain a test condition that is an expression that evaluates to true or false. The assertion is said to be successful if the test evaluates to true and unsuccessful (or fails) if the test evaluates to false. The assertions are executed during a parse and are separate from logical validation. The syntax of a DFDL assertion is a dfdl:assert element with a number of properties. The syntax is similar to that used by Schematron [TBD: citation needed] assertions. The value of the dfdl:assert element is text to be used as an error message. The DFDL specification does not specify how a DFDL parser uses this error message text. The dfdl:assert annotation element can be used to assert truths about a DFDL model when parsing the data. These checks are separate from validation checking and are performed even when validation is off. This distinction is needed to ensure that switching validation off does not affect parsing. Examples of dfdl:assert elements are below : Error message Error message The test attribute contains a Boolean-valued expression. See section (TBD: xref expression language) for a description of its syntax. The discriminator attribute is a Boolean. The default value is "false". When discriminator is "true" the assertion is called a discriminating assertion or discriminator for short. When discriminator is "false" the assertion is called an ordinary assertion. The timing attribute is either "before" or "after", with a default value of "before". The timing must be before (the default) when discriminator is "true". When the discriminator attribute is "true", then there can be no error message content. When the discriminator is "false", then an assertion failure causes a processing error. The semantics of assertions involved with the control of Discriminators control parsing for choice constructs. See the section (TBD: xref choice semantics) for more details. The dfdl:escapeScheme Annotation Element TBD. Note that the name attribute is a NCName (uses target namespace of the schema). The ref attribute is a QName. The dfdl:hidden Annotation Element We can remove an element from the logical data model of the data by simply placing an annotation around it: We can refer to the element from inside a DFDL annotation using the same XPath expression that we would have if it were not hidden. Hidden elements can (typically will) contain the regular DFDL annotations. They are processed using the same behavior as non-hidden elements. Hidden elements can only appear in the document in places where the element would be legal if it appeared outside the annotation. (This ensures that all XPath references to hidden elements are well defined.) Hidden elements may appear within the structure of hidden elements. The dfdl:numberScheme Annotation Element TBD. can these be named and reused? If so the usual NCName and target namespace for name and QName for ref apply. The dfdl:defineVariable Annotation Element Variables provide a means for communication within a DFDL schema. A variable is defined in one place of the schema, then set somewhere within the scope of that definition, and referenced elsewhere in the scope. A new variable is introduced using dfdl:defineVariable: { if dfdl:property("alighmentUnits") = "bits" then 1 else 8 } The name of a newly defined variable is placed into the target namespace of the schema. The defaultValue is optional. It can be specified as an attribute or as the element value as shown in the examples above. If not provided then the variable has no default value. Note the name attribute is a NCName. Variables can be defined at any annotation point of the schema except top level. They define the property or variable name over the scope implied by the position of the variable definition. The definition defines the scope of both the name and the value of the variable. If the variable has a default value, or has been assigned (see setVariable below), then that default value or assigned value can be referenced from anywhere within the scope of the definition. See the section on scoping below. Variable definitions may be included inside dfdl:defineFormat annotations. In this case the definitions are put into use by the 'ref' attribute of the dfdl:format (or equivalent) annotation. Normally variable definitions are introduced at a scope covering a sequence group. This is due to the single-assignment rule for variables which is described further below. The dfdl:setVariable Annotation Element Variables get their values either by default, or by assignment using the dfdl:setVariable annotation. For example: { $(.) } The name attribute is a QName. That is, it may be qualified with a namespace prefix. In the above, the element named "ds" contains the string to be used as the ibmEDI:EDIFACT_DS delimiter at other places in the data, so the above defines the value of the ibmEDI:EDIFACT_DS variable to take on the value of this element. Note that the syntax supports both a value attribute or the value being specified by the element value. Note that setVariable value expressions are evaluated after the logical value of the construct where they are found has been created. Hence, depending on the relative path value "." in an expression in a setVariable is meaningful. The name of a variable is defined in the target namespace of the schema containing the definition. The declaration of a variable must be in scope at the point of the assignment, and at the point of reference. Short Form Syntax for Variable Assignment There is a short form syntax for variable assignments which uses non-native attributes. Notice that two annotation non-native attributes are required. One to give the name of the variable to be set, the other to give the value. This syntax can set only one variable per XSD construct. To set more than one annotation from the same construct one must use the long form annotations. The dfdl:defineProperty annotation element A new property is introduced using dfdl:defineProperty: The name of a newly defined variable is placed into the target namespace of the schema. Note the name attribute is a NCName. Once a property is defined, it can be bound in dfdl:format annotations. Properties must be defined at the top level of a schema. That is their names are in global scope. Namespace management can be used to avoid conflicts. Expression language The DFDL expression language is XPath 2.0. The full XPath 2.0 language has more expressive power than we need in DFDL. Specifically, since DFDL uses only a subset of XML Schema and has a simpler information model, only some XPath expressions will be meaningful in DFDL Schemas. Expression Language Data Model XPath can handle seven different types of nodes, however, in DFDL our XPath expressions only handle one type of node: the Element node. This obviates the need for Path Steps based on the type of node. The expression /a/child::text() is not meaningful in a DFDL schema. The only node test supported is the node() test, which matches any node type in XPath. The processing-instruction(), comment(), and text() node tests are not valid in DFDL. Location Paths Location Paths are the most frequently used XPath construct. Location Paths are used to select a set of nodes from the DFDL document. Location Paths consist of one or more Path Steps separated by the / character. They may be absolute or relative. TBD: In DFDL the node sets returned by an XPath expression must be either empty, or must return exactly 1 node. (?? Are there cases where we need multiple return nodes. ?? Efficiency considerations are what drive the issue) . Predicates Path Steps are allowed to have Predicates. DFDL also supports the predicates syntax on Path Steps, but these are used (TBD: only?) to index arrays. A parser error will be reported if a Path Step with a Predicate does not evaluate to an array element. This means that numeric access to the children of sequences is not allowed in DFDL Schemas. True and False An expression is true if the expression evaluates to a non-Null value that is not FALSE. The expression is false if it evaluates to an empty node list or to FALSE. Property-Valued Expressions A special XPath function dfdl:property() can be called from XPath to obtain the value of a DFDL property binding. A special XPath function dfdl:isPropertyDefined() can be called from XPath to determine if a property has a binding or not. It is a schema definition error for an expression to use a property name in either of the above functions where the property name does not correspond to an existing property. This implies that the property name must be literal, not computed. TBD: If a property has an expression containing this call, and this property binding is higher up in the scope, when is the expression evaluated? Once at time of definition when the binding is established or each time the value of the property is requested? What is the current position in the schema of the parser at the time of this expressions evaluation, i.e., how would relative paths be interpreted for these expressions? This is particularly important for two reasons: suppose a property contains the separator by way of a path into the data. Then everyplace the separator is used we don't want the processor to have to re-evaluate whether the expression, and clearly the path has to be meaningful based on the location where the binding occurred in the schema. Alternatively, suppose we define one property in terms of another. (need example there was a case where this was important.) then when the property is used you need to re-examine to see if the binding of the other property has changed or been provided when it was not previously. We could require re-evaluation at every use, but allow implementations to optimize by detecting when the value cannot change. Variable-Valued Expressions A special XPath function dfdl:variable() can be called from XPath to obtain the value of a DFDL variable. See Section TBD: xref variables for more details on variables. It is a runtime error to reference a variable that has not been assigned, and which does not have a default value. It is a schema definition error to reference a variable from outside the scope of its definition. Regular Expression Matching A special XPath function dfdl:regexp() can be called from XPath to return a value which is the content which matches a regular expression. TBD: arguments? Obviously one is a string which is the regexp. Is there a second path argument as well? TBD: semantics here of where we start searching, and in what stream/source, and how that location in the source is determined. So that we can talk about not a value matching a regexp, but a source matching it. Presumably you give a path to an element, but instead of referencing that element's value you are referencing that element's representation bits. Dynamic Representation Properties It is possible for a representation property to be determined at runtime from the data. For example, in some data formats, the delimiter to be used to separate elements is stored as a value of an element of a header record. This allows the delimiter to vary from one data set to another so as not to interfere with characters used in the data. Reference from DFDL annotations into the data is done through the XPath expression language. Expressions in this language appear as the values of representation property bindings using a syntax which encapsulates the expressions in curly brace characters { and }. Single braces are interpreted as surrounding an expression which will be evaluated to obtain the property value. Single braces should be matched. Double braces are used to insert literal braces and do not have to be matched. The expression language is used for specifying paths to other element values and parts of the data as well as to compute values. Some representation properties, such as inputValueCalc are defined to always have an expression as their value. In this case the single-braces are optional. TBD: is this a good idea or not. They can certainly be optional for expressions that are literal constants, e.g., allowing you to write "5" instead of "{5}", but should we allow omission of the curly braces in general for expression-valued properties? Scoping Rules This section describes the rules that govern the scope over which DFDL annotations apply. The aim is to summarize these rules concisely, while more detailed examples are provided in the supplementary document, [Examples of the DFDL Scoping Rules]. The scope over which a DFDL annotation applies is defined using the applies attribute of a DFDL annotation element. The example below shows the scope being defined for a dfdl:format annotation: The applies attribute can take one of two values: hereOnly - the annotation applies to the annotated construct but not to any contained or referenced constructs. toScope - the annotation applies to the annotated construct and to any contained or referenced constructs. Annotation Positioning As described in Section  REF _Ref161828896 \r \h 6, DFDL annotations are positioned at annotation points within a DFDL schema. The table below shows the validity of each annotation point for annotations that apply hereOnly and toScope. Annotation PointApplieshereOnlytoScopeSchema declaration( Invalid( Invalid Only top level defining forms (e.g., dfdl:defineFormat) can appear at top level of the schema.Element declaration( Valid( ValidElement reference( Valid( ValidComplex type definition( Invalid( ValidSimple type definition( Valid( ValidSequence declaration( Valid( ValidChoice declaration( Valid( ValidGroup reference( Valid( ValidSince an annotation that applies toScope is inherited by any contained or referenced constructs, the same meaning can often be expressed using various annotation points. The example below shows three equivalent annotation points for a toScope annotation. In each case, the annotation applies to both contained constructs: title and pages. Annotation Overloading Annotation overloading takes place when multiple DFDL annotations properties are positioned at the same annotation point. When this occurs, annotations that apply hereOnly take precedence over those that apply toScope. When multiple DFDL annotation properties occur at the same annotation point, those that apply toScope and those that apply hereOnly are combined separately to form two groups. There must not be duplicate properties within either of these groups, and there can be only one use of the ref attribute within each group. Duplicate properties and multiple ref attributes must result in a DFDL schema definition error. The example below demonstrates annotation overloading. The format separator annotation property is overloaded on the annotation point for the outer sequence. In this case, the ":" separator value which applies toScope will take precedence and apply to the outer sequence, while the "," separator will be inherited by the inner sequence. Scoping of Type References DFDL scoping rules are consistent with the principal of referential transparency, whereby a type reference can be replaced with an in-line copy of the referenced type without altering the meaning. Hence, if an annotation that applies hereOnly is positioned on an element that references a complex type, the annotation does not apply to the referenced type; and conversely, an annotation that applies toScope would also apply to the referenced complex type. The table below summarizes the rules for the application of annotations to referenced types: Referenced TypeAppliestoScopehereOnlySimple Type( Does apply( Does applyComplex Type( Does apply( Does not apply Scoping of Element and Group References The exception to the general case concerns annotations positioned on element references and group references. When this occurs, the annotations on the reference will take precedence over any top-level annotations on the referenced element or group. Consider the mechanism of substituting an element reference declaration with the referenced elements. If annotations are present on both the element reference declaration and the referenced element, they will need to be combined in some way. The rules of DFDL dictate that those on the element reference take precedence over those on the referenced element. In the example below, the annotation on the element reference specifying a format encoding of ascii takes precedence over the utf-8 format encoding of the referenced element. This mechanism provides a way to establish default properties for an element declaration but provide optional overrides to them at the point of use. Scoping of Type Derivations When visiting a derived type (only simple type derivations are allowed in DFDL v1.0) the parser will visit any annotations in the root of the type definition first. Consider Example 1 below. The comments describe the order in which the annotations are visited. In evaluating testElement1 the property alignment will have the value 16 because this is the last thing to be added to the local context before the type is evaluated. In evaluating testElement2 the property alignment will have the value 64.   Scope Resolution Rules for Format Properties As a DFDL processor walks the DFDL schema, it maintains the current information about what representation properties are in effect and what values they have by way of the context. The global context contains named sets of property bindings created by the dfdl:defineFormat annotations. A local context contains individual property bindings created by dfdl:format. In processing DFDL we will often need more than one local context with slightly different content in them due to the scoping behavior of the language. The top level element of the schema and its format annotation are either explicit in the schema, or implicit as described below in section  REF _Ref161836873 \r \h 14. At this point we have a schema where there is conceptually a distinguished top-level element declaration, and we have a global context, and a dfdl:format annotation which is actually or conceptually on the top level element. The DFDL processor begins at the top level element and descends over its structure. At annotation locations, there can be one or multiple DFDL annotations, some with applies="hereOnly", and others with applies="toScope". Hence, each time the DFDL processor encounters a DFDL annotation, it creates two new local contexts associated with the annotated construct. A local context is created first for all the applies="toScope" annotations. This is called the default local context. Another local context is created for all the applies="hereOnly" annotations. This is called the specific local context, and it is 'inside' the default local context, that is, it refers to the default local context as a predecessor. If there is only a single annotation at this annotation location, then only one or the other of the default and specific local contexts will contain property bindings depending on the 'applies' attribute setting. The other local context conceptually exists, but contains no property bindings. When the annotated schema item is an element declaration with simple type, or a model-group (sequence, all, choice), then the specific local context is used first to obtain representation property values. The new default local contexts are pushed onto a stack in the usual manner as the schema is traversed, each new default local context's property bindings supersede those of the preceding default local contexts. A property value is determined by looking for it in the default and specific contexts as just described. If a binding for it is found, then that value is used. If not then we move down the stack of default local contexts to the predecessor and look for the binding there, repeating until a value is found. Note that the global context does not contain individual property bindings, (rather, only named sets of bindings referenced by the 'ref' attributes of dfdl:format annotation elements) so it is not searched. If no value is found for a property it is a Schema Definition Error. When the annotated schema item is an element declaration with complex type, then the specific local context (if it exists) is used for the occurrence and other immediate properties of the item. Only the stack of default local contexts is used for the contents inside the complex type. When the annotated schema item is an element or group reference, then the annotations at the reference and those of the declaration are combined as in section (TBD: Xref element references in scoping section), and then the element reference is treated as if it were an equivalent element declaration. Consider this example. We'll refer to the lines by number below. 1 2 3 3.5 4 4.5 5 6 6.5 7 8 8.5 9 9.5 10 10.5 11 Some data matching the above description might be: 3$!4$!line6data*;line7data**!9$ In the above, let's examine what property bindings are in the specific local context and default local context as we process each element. line numberdefault local contextspecific local contextdiscussiondata from above example data 1((separator = ";" terminator="$"))nothingapplies="toScope" means we push a new default local context2((separator = ";" terminator="$")) separator="!" terminator=""applies="hereOnly" so we create a specific local context. When processing the sequence itself, we will use this specific local context.3((separator = ";" terminator="$"))nothingelement "a" is terminated by "$" because we find terminator in the context.3$3.5((separator = ";" terminator="$"))separator="!" terminator=""we're now between elements of the sequence. This sequence has a specific local context. In that there is a separator, so we use it. In other words, we expect to see "!"!4((separator = ";" terminator="$"))nothingelement "b" is terminated by "$" like element "a" was.4$4.5((separator = ";" terminator="$"))separator="!" terminator=""Like line 3.5, we expect to see "!"!5new default local context extended with new binding ((terminator="*") (separator = ";" terminator="$"))nothingnotice there is no specific local context. So this sequence's separator will come from the default local context. and the default terminator for elements will now be "*"6same ((terminator="*") (separator = ";" terminator="$"))nothingafter element "x" we expect its terminator which is "*". This is found in the default local context as the specific local context is empty as we process the element. line6data*6.5same ((terminator="*") (separator = ";" terminator="$"))nothingAfter the element we expect this sub-sequence's separator which is ";" coming from the default local context.;7same ((terminator="*") (separator = ";" terminator="$"))nothingsimilarly for element "y" we expect its terminator from the default local context, and then the sequence separator from the sequence's specific local context.line7data*8same ((terminator="*") (separator = ";" terminator="$"))nothingThe terminator "*" is in scope for this sequence, so we'll get an additional "*" for termination of the sequence. *8.5pop stack back to ((separator = ";" terminator="$"))separator="!" terminator=""after this sub-sequence we get the separator for the enclosing sequence, which is "!" since at line 2 which is the beginning of the sequence we had a specific local context.!9same ((separator = ";" terminator="$"))nothingelement "c" is followed by its terminator "$"9$9.5same ((separator = ";" terminator="$"))separator="!" terminator=""no separator since we're at the end of the sequence, 10same ((separator = ";" terminator="$"))separator="!" terminator=""terminators is empty string in the specific local context so we don't get another "$" here at the termination of the sequence. Contrast this with line 8.11nothingnothingback to whatever context this type was being used in.Semantics We describe the semantics of DFDL in terms of a logical description of how a DFDL parser might proceed to operate on data. Any implementation that provides operations with consistent behavior is valid. Where this specification uses language indicating the specific behavior of the parser, implementors should NOT interpret that as a requirement for any DFDL processor to specifically operate in that way. Rather, the behavior specified here defines the logical data produced from a representation and the represenetation produced from a logical value, but does not specify the mechanism that must be followed by implementations. For example, a parser might well use a lazy strategy, and evaluate only the parts of a large source needed by the application. A parser or unparser may also support random access to parts of the data for certain data formats, whereas this specification defines a full parsing of the data. Also, there are many ways that the processor might be implemented, using efficient data structures, caching, and so on. These details are left to implementations. A major area left to implementations is error behavior. That is, when an effective processing error occurs, implementations are free to implement a variety of diagnostic capabilities, and/or recovery strategies which could allow processing to proceed after some special handling of the error situation. DFDL Parser and Unparser A DFDL Parser is an application or code library which can take as input: A DFDL Schema A data source It is able to use the DFDL description to interpret the data sources and realize the DFDL Information Model. This logical data model could then be written out (for example it could be realized as an XML text string) or it could be accessed by an application through an API (for example, a DOM-like tree could be created in memory for access by applications). Symmetrically, there is a notion of a DFDL Unparser. The unparser works from an instance of the DFDL Information Model, a DFDL annotated schema and writes out to a target stream in the appropriate representation formats. Often both parser and unparser would be implemented in the same body of software and so we do not always distinguish them. Collectively they may be called the DFDL Processor. The parser and unparser may, of course, be different bodies of software. Unparsing Must be Unambiguous Usually, the behavior of the unparser is symmetric to the behavior of the parser; however, there are cases where the DFDL schema will accept several equivalent representations for the same logical data. In this case it would be ambiguous which of these equivalent representations should be produced by the unparser. The DFDL standard contains representation properties which are used to eliminate this ambiguity. It is a schema definition error if a DFDL schema is being used to unparse data and there is any ambiguity about the representation. Parser Specification Overview The DFDL logical parser is a recursive-descent parser (TBD: citation needed) with guided, but potentially unbounded look ahead that is used to resolve points of uncertainty. (see TBD: xref to section on choice/uncertainty, i.e., choice, and any wildcards) The unbounded look ahead means that there are situations where the parser must speculatively attempt to parse data where the occurrence of a parse error causes the parser to suppress the error, back out and make another attempt. Implementations of DFDL may provide control mechanisms for limiting the speculative search behavior of DFDL parsers. The nature of these mechanisms is beyond the scope of the DFDL specification which defines the behavior of conforming parsers only on correct data. That is, data that can be parsed without any effective parse errors. The logical parser recursively descends the DFDL schema beginning with the element declaration of the distinguished root node of the schema. Depending on the kind of schema construct encountered and the DFDL annotations on it, and the pre-existing content of the context, the parser performs specific parsing operations on the data stream. These parsing operations typically recognize and consume data from the stream and construct values in the logical model. For values of complex types, these logical model values may incorporate values created by recursive parsing. The parser will generally augment the context with information from the schemas DFDL annotations as it recursively descends. This is done in a manner consistent with the scoping of properties and variables described in Section (TBD: Xref Scoping)  REF _Ref161823893 \r \h 11. When the parser reaches a simple type it updates its context with respect to the local annotation and then attempts to populate the data model with a value of the appropriate type. DFDL Logical Parse Function The logical DFDL parser can be described in terms of a function of several arguments which produces several results. Description of the logical parser in this way, rather than as the more traditional state-machine, facilitates explaining the behavior of the parser when speculating to resolve uncertainty. We will refer to the logical parser function as P. The signature of P can be written as: pos1, val, mem1, rval1 = P(construct, src, pos, ctxt, mem, path, rval) The arguments to this function are: construct: a DFDL syntactic construct (from the DFDL schema). src: Input stream or source. This is a pre-existing vector of bits. pos: Position in the stream (non-negative integer). Units are in bits. ctxt: Context. Described below in detail. mem: Variable memory. This is allocated when dfdl:defineVariable is encountered, and modified by dfdl:setVariable annotations. Described below in detail. path: This is a XPath expression that gives the location within the root value approximation for which the logical value is being parsed. rval: Root Value approximation. Abbreviated rval. This is a logical value instance in our data model; however, we augment the data model with a special distinguished marker unknown meaning we do not yet know the value. We start parsing with an unknown root value approximation; we end a successful parse returning a complete value instance, i.e., the approximation is exact in that there are no unknown markers in it. During parsing some parts of the rval will have been filled in, while others will have the unknown placeholder value marking where logical values will appear once subsequent parsing corresponding to those parts is completed. Since the value is partly known and partly marked "unknown" we refer to it as an approximation of the root value. Any sub-tree within the root value approximation can be marked "unknown" even if some parts within it are known. This allows relative paths to work within subtrees that are themselves inside uncertain constructs such as choice groups. The root value approximation is used to explain the parser behavior when the DFDL expression language is encountered and XPath expressions must be evaluated which refer to other parts of the logical value being created by the parser using relative or absolute XPath expressions. Such expressions may address any element that is reachable via path steps that do not traverse downward past any node that is marked as "unknown". Path steps may move upward past "unknowns", just not downward. If a downward path step crosses an "unknown" value node, then it is a processing error. The results produced by the parser function are: pos1: New position in the input stream. mem1: New variable memory that reflects any changes in variable values. val: Logical value of the element. There is a distinguished value, the nil value, which is returned to indicate that an element which is nillable has the value nil. rval1: New root value approximation reflecting any changes in value. From this we see that what we have that is analogous to the state of the parser is the variable memory, position in the input stream and the root value approximation. The context and path are also state, but they are augmented during recursive descent by the parser and those augmentations are always needed only during this downward recursion. They are not needed subsequently once the parser returns upward; hence, they are not returned by the logical parser function. Context The context of the logical DFDL parser is a logical store of values with these kinds of content: global format definitions these are the named data formats created by the dfdl:defineFormat annotation. When parsing begins, all the global format definitions are present in this part of the context. local context. This contains representation property bindings and variable bindings Representation property bindings are added to the local context as dfdl:format annotations are encountered in a manner consistent with the scoping rules given in Section  REF _Ref161823893 \r \h 11. Variable bindings are added to the context as dfdl:defineVariable annotations are encountered. These map a variable name to a numbered location in the variable memory. As the parser visits an annotation in a part of the DFDL schema, the annotations can extend the local context. The local contexts are treated like a stack that follows the DFDL schema tree. When the parser enters a node, N, of the XML Schema tree a local context, c(N), is created for that branch. That local context builds on the local context from Ns parent. Any children of N will construct local contexts built on c(N). When all the children of N have been parsed and the parser leaves node N, then c(N) is destroyed. Given this stack-like behavior of a context, note that it is possible to examine the local context for the most recent representation property binding for a given property name, where by "most recent" we mean closest to the top of the stack. This is the usual model where more recent representation property bindings take precedence over those deeper in the stack. However, it is also possible to inquire for the list of all property bindings held in the context for a given property name or even for a set of property names. For example, we might want an ordered list of all the representation property values for the terminator and separator properties. Variable Memory The variable memory exists to support description of the dfdl:defineVariable and dfdl:setVariable annotations. A variable is a name that is associated by the local context's variable bindings with a storage tuple in the variable memory. Specifically, the variable memory contains: a counter used to generate locations for new tuples. Initial value is 1. an ordered list of locations. Each location contains a tuple of values: has-been-set flag. This Boolean is originally false. dfdl:setVariable changes this flag to true. has-been-referenced flag. This Boolean is originally false. Evaluation of XPath expression which use the variable value changes the value to true. has-value flag. This Boolean is originally true if the dfdl:defineVariable annotation has a default value specified. Otherwise it is false, but is set to true if a dfdl:setVariable annotation is processed. typeID. This string is a type identifier taken from the type specified in the dfdl:defineVariable annotation. value. This is a typed value, or the distinguished value "unknown". The type of the value must correspond to the typeID. The value is optionally specified in dfdl:defineVariable annotations in which case we refer to it as the default value for the variable. Each time a dfdl:defineVariable annotation is encountered, the parser captures the current value of the counter from the variable memory. It then creates a new variable memory where the location counter's value is one greater, and where the list of locations has been augmented with a new tuple at the location given by the prior value of the location counter. The tuple is initialized based on the specifics of the dfdl:defineVariable annotation. In addition, a new local context is created containing a new variable binding which associates the variable's name with the location counter value, thereby associating that variable name with this new tuple in the new variable memory. Note that the above algorithm insures that each time a dfdl:defineVariable is encountered, a fresh location is initialized for it, and once the local context containing that variable binding goes out of scope, the prior tuple for the variable can no longer be reached. The flags in the variable memory tuples are interpreted and modified as follows: beforeafterhas-been-sethas-been-referencedhas-valuehas-been-sethas-been-referencedhas-valuedefineVariable (without default value)tuple doesn't existfalsefalsefalsedefineVariable (with default value)tuple doesn't existfalsefalsetruesetVariablefalsefalsefalsetruefalsetruefalsefalsetruetruefalsetrue (also value changed to new value)falsetruefalseimpossible state. The flags cannot get into this configuration.falsetruetrueprocessing error set after reference not allowed.truefalsefalseimpossible state. The flags cannot get into this configuration.truefalse trueprocessing error double set not allowedtrue truefalseimpossible state. The flags cannot get into this configuration.truetruetrueprocessing error double set not allowedreference variable (from XPath expression)falsefalsefalseprocessing error undefined variablefalsefalsetruefalsetrue (value is returned)truefalsetruefalseimpossible state. The flags cannot get into this configuration.falsetruetruefalsetrue (value is returned)truetruefalsefalseimpossible state. The flags cannot get into this configuration.truefalse truetruetrue (value is returned)truetrue truefalseimpossible state. The flags cannot get into this configuration.truetruetruetruetrue (value is returned)true The above table describes a set of rules which might be abbreviated as: write once, read many no write after the value has been read It is a schema definition error if setVariable or a variable reference occurs and there is no variable binding in the local context. It is a schema definition error if setVariable provides a value of incorrect type which does not correspond to the type specified by the defineVariable. It is a schema definition error if a variable reference in an XPath expression is able to return a value of incorrect type for the evaluation of that expression. That is, DFDL including the expressions contained in it, is a statically type-checkable language. Position and Length In order to parse data or to write it out, we must be able to determine the position of the data within the data stream, and we must be able to determine its length so that we can extract the representation and convert it into a value or write out the proper representation. When we discuss the position and length of the representation of an element we will do so using specific terminology. Value and Element Start Position, Length, and End Position Every element declaration of a DFDL schema describing a data value having contiguous representation in the data stream has a representation which can be located within the input or output stream using these quantities: element start position content start position - always equal to or greater than the element start position. content length content end position minus content start position. content end position - always equal to or greater than the content start position. element end position always equal to or greater than the content end position element length element end position minus element start position The element start position of an element's representation is equal to the end position of the preceding element's representation except when explicit offsets (offset and offsetFrom properties see Section TBD: Xref to offset/offsetFrom) are used. The element length of a scalar (non-variable-length dimensioned, non-optional) element whose value comes from the representation data must be at least 1 (bit). Arrays with minOccurs="0" and optional elements can have element lengths of zero (bits). It is a processing error if the element length of such a scalar element (not optional, not variable-length dimensioned) is determined to be zero bits. Dynamic Extent The dynamic extent of an element declaration is the set of bits in the source (or target for output) found between the element start position and the element end position. Parsing Functions We now give the semantics of DFDL parsing in terms of a set of definitions for our logical parse function, P, introduced above. The signature of P for review is: pos1, val, mem1, rval1 = P(construct, src, pos, ctxt, mem, path, rval) General Parse Processing - P When processing any annotated construct, P first performs these general sub calculations: Calculates ctxt1, and mem1: Extends ctxt with new variable bindings based on any dfdl:defineVariable annotations. mem1 is the new variable memory with a new location tuple corresponding to this variable definition. The mem1 will contain a value for a variable if the definition has a default-value expression. Calculates Sctxt: Extends ctxt1 with new applies='toScope' representation property bindings as described in Section  REF _Ref162000445 \r \h  \* MERGEFORMAT 11.4.  If the construct is a simple type definition then it is a schema definition error if there are any applies="toScope" representation properties. Calculates Lctxt: Extends ctxt1 with new applies='hereOnly' representation property bindings as described in Section  REF _Ref162000445 \r \h  \* MERGEFORMAT 11.4. . If the construct is a complex type definition then it is a schema definition error if there are any applies='hereOnly' representation properties. Evaluates any dfdl:assert annotations having timing attribute value of "before". These are evaluated using the Lctxt, and the mem1 variable memory, as the test expression in the assertion can refer to variables or the context. See the section on assertion evaluation (TBD: xref assertion evaluation). Given the Sctxt and Lctxt, a construct specific parser is then selected. This is one of the functions E, S, T, G, or C that are described below. All these functions have this same signature as shown for E here: pos1, val, mem2, rval1 = E(construct, src, pos, Lctxt, Sctxt, mem1, path, rval) The signature is similar to that of the logical parser P, except that an additional context argument has been added to allow the construct-specific parsers to realize the DFDL scoping rules. The selection of a construct specific parse function is as follows: Function E is used when the construct is an element declaration. Function S is used when the construct is a simple type definition. Function T is used when the construct is a complex type definition. Function G is used when the construct is a sequence group. Function C is used when the construct is a choice group. Function R is used when the construct is an 'any' element wildcard, a group reference or an element reference, (R is for syntax Rewrite) The processing then continues with these calculations: Calculates pos1, val1, mem2, rval1 using the construct specific parser. Evaluates any dfdl:assert annotations having timing attribute value of "after". These are evaluated using the Lctxt, and the mem2 variable memory, as the test expression in the assertion can refer to variables or the context. See the section on assertion evaluation (TBD: xref assertion evaluation). Calculates mem3 by evaluating any dfdl:set-variable annotations. The parsing of the construct completes returning the values pos1, val, mem3, rval1 from the above listed calculations. If a processing error occurs at any time then the parse function P returns pos, err, mem, rval, where err is the distinguished value that indicates a processing error.  Assertion Evaluation Assertion annotation elements contain test expressions. These are evaluated at specific times depending on the behavior of the logical parser described above. Ordinary assertions explicitly cause processing errors if the test evaluates to false, or if a processing error occurs during the evaluation of the test expression. Discriminating assertions cause processing errors if a processing error occurs during the evaluation of the test expression. Otherwise a discriminating assertion does not cause an error. Rather it is used to control resolution of choice constructs and 'any' element wildcards. See the sections on choice and wildcards for details. Element Declaration - E When processing an element declaration we search for a parse strategy as described in Section TBD: xref parse strategy. The parse strategy for an element declaration contains these sub-functions: PRE: element pre-processing rule invoked at the beginning of the processing POST: post-processing. FL: calculates the fixed length or returns 'variable'. When processing an element declaration the parse function E performs these actions. Calculates rval1 by updating rval with the element instance having the name of this declaration, but with an 'unknown' placeholder for the value. Calculates path1 by extending path with the name of this element declaration. Calculates pos1, mem1 = PRE(src, pos, Lctxt2, mem) (Handles initiators, alignment, and anything else that affects the position of the representation which is independent of the contents) After the preprocessing, a content sub-function is called. This content function is always one of A, O, or P. The selection is as follows: If the element declaration indicates that the element is an array (maxOccurs > 1, minOccurs <= maxOccurs) then function A is selected. If the element declaration indicates the the element is optional (maxOccurs = 1, minOccurs = 0) then function O is selected. Otherwise the sub-processing function is P: The sub-processing function is invoked as follows: pos2, val, mem2, rval2 = A(decl, src, pos1, Lctxt, Sctxt, mem1, path1, rva1l) or pos2, val, mem2, rval2 = O(decl, src, pos1, Lctxt, Sctxt, mem1, path1, rval1) or if the type of the element is a simple type (note we pass Lctxt here) pos2, val, mem2, rval2 = P(typeDef, src, pos1, Lctxt, mem1, path1, rva1l) or if the type of the element is a complex type (note we pass Sctxt here) pos2, val, mem2, rval2 = P(typeDef, src, pos1, Sctxt, mem1, path1, rval1) where decl is the element declaration itself and typeDef is the type definition for that element declaration's type or the name of a primitive type if the type is a simple primitive type. Processing then continues with these calculations: Calculates rval3 by updating rval2 with the value, val, returned from the element sub-processing function and removing the 'unknown' marker for this value. Calculates pos3, mem3 = POST(src, pos2, Lctxt, mem2) (Handles terminators, trailing padding, and anything else that affects the end position of the representation which is independent of the contents.) The parsing of the element declaration completes returning the values pos3, val, mem3, rval3 from the above listed calculations. If a processing error occurs at any time then the parse function P returns pos, err, mem, rval, where err is the distinguished value that indicates a processing error.  Sequence Groups - G There are two kinds of sequence groups: ordered and unordered. An unordered sequence group is one where the Lctxt contains property dfdl:unordered equal to "true". These are handled as described in section TBD: xref unordered sequence group. Ordered Sequence Groups When processing an ordered sequence group we search for a parse strategy as described in Section TBD: xref parse strategy. The parse strategy for an ordered sequence group contains these sub-functions: PRE: sequence pre-processing rule invoked at the beginning of the sequence processing SEP: sequence between-child-elements processing rule invoked between elements of the sequence POST: sequence post-processing rule invoked after the last child element. FIRST: sequence first child rule parses the first child element. Generally, this involves recursive invocation of the parse function P. MIDDLE: sequence middle child rule recursively parses middle child elements. LAST: sequence last child rule recursively parses last child elements. FL: calculates fixed length or returns 'variable' if not fixed length. The discussion below assumes exactly 3 children in the sequence. In this case the 6 sub-functions above will be invoked in the sequence PRE, FIRST, SEP, MIDDLE, SEP, LAST, POST. The parse function behavior generalizes in the natural way to more than 3 children so those details are not described. The 6 sub-functions are applied depending on the specific number of children for a specific sequence. The strategy always contains all 6 sub-functions, but a given sequence using that strategy will use the sub-functions it actually needs depending on the number of children present. Processing then performs the following: Calculates pos1, mem1 = PRE(src, pos, Lctxt2, mem) (Handles initiators, alignment, and anything else that affects the position of the representation which is independent of the contents.) Calculates rvalB = rval with the unknown for the current element value replaced by the logical value approximation (unknown, unknown, unknown). That is, since this sequence contains 3 children, a logical sequence value with three unknown children is created and used as the placeholder for the value in the root value approximation. The "B" suffix stands for "Before". This unknown placeholder for this element value is located within rval at the given path. Calculates pos2, val1, mem2, rval1 = FIRST(decl1, src, pos1, Sctxt2, mem1, path, rvalB) where decl1 is the element declaration of the first child element. Calculates rval1F = rval1 with the placeholder for the first unknown at the given path location replaced by val1. Calculates pos2F, mem2F = SEP(src, pos2, Lctxt2, mem2). Note how this uses Lctxt2, not Sctxt2. Hence, it has visibility to the applies="hereOnly" annotations. Calculates pos3, val2, mem3, rval2 = MIDDLE(decl2, src, pos2F, Sctxt2, mem2F, path, rval1F) where decl2 is the element declaration of the second child element. Calculates rval2M = rval2 with the placeholder for the second unknown at the given path location replaced by val2. Calculates pos3M, mem3M = SEP(src, pos3, Lctxt2, mem3) Calculates pos4, val3, mem4, rval3 = LAST(decl3, src, pos3M, Sctxt2, mem3M, path, rval2M) where decl3 is the element declaration of the third child element. Calculates rval3L = rval3 with the placeholder for the third unknown at the given path location replaced by val3. Calculates pos4L, mem4L = POST(src, pos4, Lctxt2, mem4) (Handles terminators, trailing padding, and anything else that affects the end position of the representation which is independent of the contents.) The result value, val, is created by constructing the value tuple (val1, val2, val3) which is the same as the tuple found in rval3L at the location given by path. The result returned is then: pos4L, val, mem4L, rval3L. In summary, the sub-rules of the sequence group strategy for the element are evaluated in such a way that each one depends on the output results (specifically the new pos and mem) from the prior sub-functions. If a processing error occurs at any time then the parse function P returns pos, err, mem, rval, where err is the distinguished value that indicates a processing error.  Unordered Sequence Groups In DFDL, ordered and unordered are characteristics of the representation only. Logically, sequence groups are always in schema order. The semantics of unordered groups (sequence with dfdl:unordered="true" property) are expressed by way of a source-to-source transformation of the declaration, and by a data transformation on the resulting value. The source to source transformation turns the declaration of an unordered group into an array element which contains a choice. Each element of the unordered group becomes an alternative element within the choice. The unordered group's separator and terminator become the occursSeparator and occursTerminator of the array. The dfdl:unordered property is dropped, but other DFDL annotation properties are preserved. The maxOccurs and minOccurs on any element of the unordered sequence are dropped when the element is placed into the choice. For example: TBD: example showing unordered sequence turning into array of choice. Show one of the sub-elements of the unordered sequence being an array, one optional, one required. Schema definition errors are then detected as for choice group types. Processing then constructs this array by parsing the data. The post processing then transforms this array of choice type back into the original sequence of non-choice elements. The unordered DFDL property is no longer effective. that is, logically, the value is a sequence. Ordered and unordered are characteristics of the representation only. The transformation here is the obvious one where all array elements having the first choice alternative as their value are accumulated into the first child element of the logical sequence. If there is either no such value or more than one such value, then the first child element must be an array or optional declaration (appropriate minOccurs and maxOccurs) so that it can accommodate the number of values found. The dimensionality of the first element must accommodate the number of values actually found. It is a processing error if it cannot. This algorithm repeats for the array elements having the 2nd choice alternative as their value, and so on until all the choice alternative values have been moved into their corresponding elements/arrays in the logical sequence group. An unordered sequence is of fixed length if the same sequence is fixed length when the unordered property is removed. On output, the behavior is exactly as if the dfdl:unordered property was absent. That is, the elements are output in schema declaration order. Optional - O When processing an optional element declaration we search for a parse strategy as described in Section TBD: xref parse strategy. The parse strategy for an optional element declaration contains these sub-functions: PRE: pre-processing EXISTS: determines if the optional element is present or absent. CONTENT: calculates the value of the element if there is one. POST: post-processing. FL: calculates fixed length or returns 'variable' to indicate variable length. (Optional data can be fixed length if it contains a fixed size marker value or pattern indicating missing content. Similarly nillable data can be fixed size.) Processing then performs the following: Calculates pos1, mem1 = PRE(src, pos, Lctxt2, mem) (Handles alignment, and anything else that affects the position of the representation which is independent of the contents of the element and whether it is present or absent.) Calculates res = EXISTS(decl1, src, pos1, Sctxt, mem1, path, rval) where decl1 is the element declaration of the optional element with the maxOccurs and minOccurs removed. Then we calculate: pos2, val, mem2, rval1 = CONTENT(res, decl1, src, pos1, Sctxt, mem1, path, rval) Note that this CONTENT function is passed the result, res, from the EXISTS function call. We call CONTENT regardless of whether res is true or false. Calculate pos3, mem3 = POST(src, pos2, Lctxt2, mem2) (handles post-content skips and anything else that extends the length of the representation which is independent of the contents of the element and whether it is optionally present or absent. We return pos3, val, mem3, rval1 as the results of parsing the Optional element. The general behavior of the EXISTS parse function is to suppress processing errors and return true or false depending on whether the optional element is detected to be present or absent. The CONTENT function's role is to create the value from either the representation (if EXISTS returned true), or from other information such as default value declarations in the DFDL schema. Array - A When processing an array we search for a parse strategy as described in Section TBD: xref parse strategy. The parse strategy for an array contains these sub-functions: PRE: pre-processing rule invoked at the beginning of the array processing SEP: between-child-elements processing rule invoked between elements of the array POST: post-processing rule invoked after the last element. EXISTS: determines if the next element is present or absent. FIRST: first child rule recursively parses the first array element. MIDDLE: middle child rule recursively parses middle array elements. LAST: last child rule recursively parses the last array element. NONE: no children rule determines value in the case where there is no element. (e.g., takes default value specified in the schema into consideration) FL: calculates the fixed length of the array, or returns 'variable' if not fixed length. The discussion below assumes exactly 3 elements in the array. It generalizes to more or fewer elements in the natural way so those details are not described here. In this specific case of 3 elements the sub-functions above will be invoked in the sequence PRE, EXISTS, FIRST, SEP, EXISTS, MIDDLE, SEP, EXISTS, MIDDLE, SEP, EXISTS(returns false), LAST, POST. (Note that we have to try to parse the last element as MIDDLE, and then fail to find a further existing element, and then reparse it as a LAST.) The sub-functions are applied depending on the specific number of elements for a specific array instance. The strategy always contains all the sub-functions, but a given array using that strategy will use the sub-functions it actually needs depending on the number of elements present Processing then performs the following: Calculates pos1, mem1 = PRE(src, pos, Lctxt2, mem) (Handles initiators, alignment, and anything else that affects the position of the representation which is independent of the contents of the array or number of elements.) Calculates rvalB = rval with the unknown for the current element value replaced by a logical value approximation for an array. The "B" suffix stands for "Before". Note that the unknown for this element value is located within rval at the given path. Calculate res = EXISTS(decl1, src, pos1, Sctxt2, mem1, path, rvalB) where decl1 is the element declaration with maxOccurs and minOccurs removed. If res is false then the array has no elements. Calculate pos2, val, mem2, rvalA = NONE(decl1, src, pos1, Lctxt2, mem1, path, rvalB) pos3, mem3 = POST(src, pos2, Lctxt2, mem2) rval1F = rvalA with the placeholder for array at the given path location replaced val. Return pos3, val, mem3, rvalA. If res is true then the array has at least one element. Calculate pos2, val1, mem2, rval1 = FIRST(decl1, src, pos1, Sctxt2, mem1, path, rvalB) where decl1 is the element declaration as in step 3. Calculates rval1F = rval1 with the placeholder for the first unknown at the given path location replaced by val1. Calculate res = EXISTS(decl1, src, pos2, Sctxt2, mem2, path, rval1F) where decl1 is the element declaration as in step 3. If res is false then the array has only 1 element which is therefore its last element. Calculate pos2, val, mem2, rvalA = LAST(1, decl1, src, pos1, Lctxt2, mem1, path, rvalB) pos3, mem3 = POST(src, pos2, Lctxt2, mem2) rval1F = rvalA with the placeholder for the first array element at the given path location replaced by val. Notice how the LAST function takes an index which gives the index in the array (one based) of the element. Return pos3, val, mem3, rvalA. If res is true then the array has another element (could be a middle or last). Calculate pos2F, mem2F = SEP(src, pos2, Lctxt2, mem2). Note how this uses Lctxt2, not Sctxt2. Hence, it has visibility to the applies="hereOnly" annotations. Calculates pos3, val2, mem3, rval2 = MIDDLE(N, decl2, src, pos2F, Sctxt2, mem2F, path, rval1F) where decl2 is the element declaration as in step 3, and N is the current array index (2 for the 2nd element.) TBD This is tedious to get right but the principle is simple. We move along doing speculative processing to see if there is another element. If there is one then we parse it as a middle, do a SEP and try again. When we hit that no more exist we have to backup and do a LAST parse instead of the MIDDLE we already did. We finish it off with POST. Along the way we have to keep updating the rval (root value approximation) to have the elements as we create them. Presumably expressions in the expression language need to have access to this index N that is being incremented. This is needed to do self-relative null flag bits in a separate bit vector for example. TBD - Another detail is the need to handle defaulting of multiple array values if there are default values or null values. Turns out this comes out in the wash. The EXISTS test can just return true up until minOccurs times in those cases regardless of what is in the data. The parsing can then compute a MIDDLE value and consume a separator, Note that the pos won't necessarily be changing as we compute the values for these additional MIDDLE and LAST elements, since they may simply be defaulting without any notion of indicators in the data. So this framework is general enough to allow our parse strategies to implement policies about defaulting up to minOccurs for example. Parse Strategy Selection Algorithm for Elements, Arrays, Optionals, and Groups A parse strategy is selected for an E, A, O, or G function by searching for one in the parse strategy list. This is an ordered list of tuples containing: A kind indicator: E element declaration G complex sequence group type (ordered only. See Section TBD: Xref Unordered group rule, for unordered groups) A Array (maxOccurs > 1 and minOccurs <= maxOccurs) O Optional (minOccurs = 0, maxOccurs = 1) A guard: this is a Boolean valued expression referring to only the representation property bindings of the Lctxt. The parse strategy definition (tuple of processing functions. The size of this tuple varies for each of E, G, A, and O) Each function searches the list for only the parse strategies having the matching kind indicator (C for function C, A for function A, etc.) Then the guard is evaluated with representation property values given by the Lctxt. If the guard evaluates to true then the parse strategy in the tuple is selected and used. If no parse strategy can be found in the list where the guard is true then it is a schema definition error. The guard expressions cannot involve any use of data. That is, they must be able to be evaluated statically using only information in the DFDL Schema. (This insures that implementations of DFDL can compile or generate code, that is, DFDL is not required to be interpreted by its specification.) It is an error in the DFDL processor implementation if determining a parse strategy involves the value of any properties that are not data independent. Choice - C Choices are either resolvable or unresolvable when parsing. We will also use this terminology: BranchA branch is one of the available alternatives within a choice. A branch can be an element of simple type or complex type.Root of the BranchEach branch conceptually has a single element object at its root. This element is known as the Root of the Branch.Nearest point of Uncertainty If the root of the branch is complex it is possible for there to be another inner choice within the branch. During the parse of a branch of the inner choice the inner choice is said to be the nearest point of uncertainty. When processing a choice group these general sub calculations are performed: Validates any contained path expressions. If a path expression contained inside a choice alternative refers to any other alternative of the choice, then it is a schema definition error. Note that this rule handles nested choices also. A path that navigates outward from an inner choice to another alternative of an outer choice is violating this rule with respect to the outer choice. Resolvable Choices A resolvable choice is one where the dfdl:choice UnresolvableWhenParsing property is false in the Lctxt. Resolvable choices correspond to concepts called variant records, multi-format records, discriminated unions, or tagged unions in various programming languages. In some contexts choices are referred to generally as 'unions'. However, this should not be confused with XML Schema unions which are not part of the DFDL information model. When processing a resolvable choice, a parse sub function called ATTEMPT is used. The argument signature of ATTEMPT is the same as P, but the return type is a simple boolean res = ATTEMPT(decl1, src, pos, Sctxt, mem, path, rval) Processing works as follows: Calculates res = ATTEMPT(decl1, src, pos, Sctxt, mem, path, rval) where decl1 is the element declaration of the first child element of the choice. If res equals true then we return: pos1, val,, mem1, rval1 = P(decl1, src, pos, Sctxt, mem, path, rval) If res equals false, then we repeat from step 1 for the next child element declaration. It is a parse error if we exhaust the child element declarations of the choice and ATTEMPT returns false for all of them. Notice that because we start from the original mem,, pos, path, rval each time in steps 1 and 2, it is not possible for variable settings to be communicated from the attempt to evaluate an alternative to any other parsing situation. The ATTEMPT effort is completely isolated. Whether it succeeds or fails, neither the position, nor anything in the variable memory or root value approximation is affected. The division of semantics into an ATTEMPT and a second recursive P parse allows what is known as speculative parsing. The ATTEMPT function separately recursively parses the data and this can require unbounded lookahead into the data. The ATTEMPT algorithm recursively invokes the logical parser P; however, the behavior of P is modified when invoked inside the ATTEMPT as follows: If a processing (parsing) error occurs during P then ATTEMPT returns false. This includes the case where an ordinary (non-discriminating) DFDL assertion fails. If a discriminating DFDL assertion is encountered and the assertion is successful. The ATTEMPT returns true. The entire branch is processed without error in which case the ATTEMPT returns true. Since choices may be embedded within other choices. These rules apply to the innermost ATTEMPT evaluation when inside the corresponding choice construct. If the ATTEMPT returns true, then the parsing is then (logically) re-done, but this time if anything goes wrong the processing error is propagated. I.e., the distinguished err value becomes the returned value. Unresolvable Choice The unresolvableWhenParsing boolean property indicates to the parser that a choice cannot be resolved using the model and data. This can occur when a DFDL Schema is created to represent COBOL structures that use REDEFINES clauses or equivalently C unions where there is no tag or other discriminating means described in the schema. In this case the choice cannot be resolved using speculative parsing. The unresolvableWhenParsing property only has meaning on parse and not during unparse. In this case, the length of all the branches of the choice must be fixed. The FL parse sub-function is called for every branch of the unresolvable choice. If all the returned values are not 'variable' then the maximum returned value is the length of the unresolvable choice. An unresolvable choice is parsed as if it were rewritten using the above described fixed length value, B, by source to source transformation into: . See the section on TBD: xref 'any' element wildcards, for discussion of the semantics of this construct. This rewrite implies that it is a schema definition error if an XPath expression outside the unresolvable choice construct refers to any element inside the unresolvable choice construct. This rewrite also makes it clear that any dfdl:assert annotation elements found inside the unresolvable choice are not evaluated, nor is any kind of validation performed on the content of the unresolvable choice even if a DFDL processor is performing validation on the other parts of the schema. Applications using DFDL processors may provide alternative means to resolve unresolved choices which defer their resolution and therefore defer the parsing of the contents of the unresolvable choice until additional information is available. Any such capability is beyond the scope of the DFDL v1.0 specification. Rewrite R Group references, element references, and 'any' element wildcards are parsed by rewriting them to semantically equivalent syntax. These constructs are what is sometimes called syntax sugar. They provide no semantics that cannot be expressed in another less-convenient syntax. The details are given in the sections below. Any Element Wildcard The attribute 'id' is required for DFDL. This 'id' attribute is used to create an element name within the group where the 'any' wildcard is found; hence, it is a schema definition error if the value of the 'id' conflicts with any other peer element name within that group. The "any" element wildcard has different semantics depending on the group context where it is found and the processContents attribute value in the declaration based on the table below: contextprocessContents valueOrdered Groupstrict (or not specified)See section (TBD: xref strict any element wildcard in ordered group)Ordered Group lax dfdl:initiatorSeparator property must be defined. See section TBD: xref lax any-element wildcard in ordered group.Ordered GroupskipThis is used to implement what is called opaque data. See section TBD: xref skip any-element wildcard in ordered group.Unordered Groupskip, lax (or not specified)dfdl:initiatorSeparator property must be defined. See section (TBD: xref any element wildcard in unordered group) Any other combinations of context and processContents are not allowed in DFDL 1.0 and are a schema definition error. Strict Any-Element Wildcard in Ordered Group Strict element wildcards occurring in ordered groups are processed by replacing their declarations with equivalent new declarations and then processing these new declarations. The replacement is as follows: A new element declaration is created. The name of the element is taken from the 'id' attribute value of the xs:any declaration. The type of the new element is a choice. The dimensionality of the element is maxOccurs="unbounded" The alternatives within the choice are each element references. There is one element reference for each global element declaration in the full schema being processed. Any format annotations on the original xs:any declaration are moved onto the new element declaration. Parsing then proceeds as for the new element declaration the type of which is a choice. Lax Element Wildcard in Ordered Group This kind of wildcard is used to absorb content which while syntactically compatible is not logically modeled as elements of the ordered group. These declarations are transformed source-to-source as follows: A new element declaration is created. The name of the element is taken from the 'id' attribute value of the xs:any declaration. The type of the new element is dfdl:anyElementWildcardType The dimensionality of the new element is maxOccurs="unbounded" The definition of dfdl:anyElementWildcardType is: This definition is provided by all DFDL implementations in the standard include/import. This ordered sequence models the syntax of an initiator-tagged element but where the initiator is not known to the schema. If there is no definition for the dfdl:initiatorSeparator property it is a schema definition error. The expression language used to obtain the value for the dfdl:separator property is described in section (TBD: xref to expression language). Skip Element Wildcard in Ordered Group This is used to implement opaque data. That is, data that is not described and to which the information model provides no access whatsoever. These any-wildcard declarations are transformed source-to-source as follows: A new hidden element declaration is created. The name of the element is taken from the 'id' attribute value of the xs:any declaration. The type of the new element is xs:hexBinary representation properties from the original declaration are transferred to the new declaration. Any Element Wildcard in Unordered Group In unordered groups, any element wildcards must have the dfdl:initiatorSeparator property specified. They are transformed source-to-source in the same manner as for lax element wildcards in ordered groups. (see TBD: xref lax element wildcard in ordered group). Element Reference An element reference is rewritten into an element declaration while combining any DFDL format annotation elements associated with it as given in Section  REF _Ref162001275 \r \h 9.5. (TBD: xref right?) Parsing then proceeds as for an element declaration. Group Reference A group reference is substituted inline for its declaration while combining any DFDL format annotation elements associated with it as given in Section  REF _Ref162001275 \r \h 9.5. (TBD: xref right?) Parsing then proceeds as for an inline group declaration. Complex Type Definition T Function T is very simple. T(typeDef, src, pos, Lctxt, Sctxt, mem, path, rval) = P(modelGroupDef, src, pos, Sctxt, mem, path, rval) where modelGroup is the model group definition (sequence or choice) inside the complex type definition. The FL (fixed length function) for Complex Types is similarly simple: FL(typeDef, src, pos, Lctxt, Sctxt, mem, path, rval) = FL(modelGroupDef, src, pos, Sctxt, mem, path, rval) Simple Types - S The parse function S is used to parse a simple type in scalar context. By scalar context we mean the simple type is from a scalar element declaration, or it is from an array or optional element declaration, but the A and O functions have already been invoked and we're now recursively parsing an individual element of the array or the optional element. A simple type is parsed by selecting a length strategy, and then determining a list of conversions. A length strategy contains a function which computes the length of the representation. This is used to then construct a sub-source containing only the required bits from the original source stream. The chain of conversions actually performs the computations which compute the logical value from this restricted sub-stream of the representation data. Length Strategies A length strategy is selected from a list of length strategies. Each length strategy contains a type or list of types a guard predicate a list of required representation properties LEN - the length calculation function FL calculates the fixed length, or returns 'variable' if the simple type is variable length. The type or list of types must match the base type of the simple type. (This allows for derived simple types). If this matches, then the guard predicate is evaluated using the Lctxt. If this evaluates to true then the length strategy is selected. The guard predicate can only refer to data independent properties in the context. It is an error in the DFDL processor implementation if any part of the guard refers to a property the value of which is not data independent. If any of the list of required representation properties is not defined in the Lctxt then it is a schema definition error. If a length strategy cannot be found it is a schema definition error. Parsing then proceeds by finding a chain of conversions which will convert the sub-source bits into the required simple type, and then executing them to produce the value. Conversions A chain of conversions is found by the parser to convert the representation into the simple type needed. For example, converting from bytes to floats is a conversion. The definition of a conversion provides the following information: A name (e.g. bytesToInt) An input type (e.g. byte) An output type (e.g. int) A guard expression the conversion may be chosen by the parser for use in the conversion chain being assembled if and only if this evaluates to true. The guard CAN ONLY refer to data independent properties in the context. This is to ensure that any search required to calculate which conversions apply at any point in the document can be done once in advance of any data being processed i.e. these choices can be handled statically time. It is an error in the DFDL processor implementation if the guard references any properties which are not data independent. A list of the named properties that the conversion will use from the context. The conversion works by consuming some number of elements of the input type to produce a value of the output type. For The most primitive conversions the input type is bits. There are standard conversions that for example convert 8 bits into a byte, or two bytes into a UTF-16 character. There are also conversions that compute integers using smaller bit-widths, so that a 5 bit wide field or a 14 bit wide field can be properly converted into binary integers. There is an ordered list of conversions descriptions. For example here are two hypothetical descriptions of conversions for use by the conversion search algorithm. name="bytesToInt" input=xs:byte output=xs:int guard=dfdl:property('repType')=binary uses="byteOrder" name="bytesToString" input=xs:byte output=xs:string guard=dfdl:property('repType')=binary" uses="encoding textCharacterSize lengthUnits textDBCSOnly byteOrder byteOrderMarkPolicy" Conversion Search Algorithm If no conversion can be found it is a schema definition error. (Note: This is not a processing error, since the DFDL processor is in principle able to prove that the error cannot occur just by examining the DFDL schema, without processing any data.) When searching for a conversion the parser will (logically) examine all the conversions in the order they appear in the conversions list. It will select the first conversion that can output its target type and for which the guard XPath is satisfied. If the conversion's input type is bits, it is applied and the search ends. If the chosen conversion does not have input type bits, then the input type it requires is made the new target type and the parser begins the search from the top. In this way the parser builds up a sequence of conversions from the required type down to bits. For example (String-to-Integer, byte to String, bits to byte) that match end to end on the types.  EMBED Word.Picture.8  The parser MAY NOT apply the same conversion twice in the same sequence of conversions (i.e. the search may not loop). TBD: limiting the length of the conversion chain: If the parser builds a sequence of conversions longer than the value of the dfdl:maximumConversionLength property then it is a schema definition error. Conversion specifications We describe the semantics of conversions by way of an inductive bootstrap. That is we specify conversions in DFDL. Each conversion is a DFDL schema with a single global type declaration of sequence group type. There are at least four elements in the sequence: guard, uses, output, input. Implementations are of course free to choose different techniques so long as the semantics is preserved. For example: The above specification uses an inputValueCalc property and its expression to indicate the means by which the output type element can be computed from the input type element. The guard is a predicate which indicates whether the conversion applies or not, and the 'uses' element is a list of properties which must be defined. Conversions define the precise meanings of the representation properties because they specify the exact calculation that is used to convert a lower-level representation to a higher-level one based on the property values. It is a schema definition error if a conversion is selected by means of the output type and guard, yet there is no definition for one of the uses list properties in the context. Value Calculation, Representation Calculation TBD: inputValueCalc and outputValueCalc properties and their use of expressions. TBD: update logical parse function P to take into consideration. Kernel DFDL The above described abstract parser depends on only a very small number of properties. This set of properties and the DFDL schema language containing only them is referred to as kernel DFDL. Kernel DFDL contains only: dfdl:inputValueCalc dfdl:outputValueCalc dfdl:unordered Boolean property to determine if sequences are ordered or not. dfdl:choiceUnresolvableWhenParsing Boolean determines whether choice is parsed out or kept as opaque data. dfdl:initiatorSeparator  String. Used in rewrite of 'any' wildcard. The rest of the functionality of DFDL is specified by means of specifying the parse strategies on the parse strategy list, the length strategies on the length strategy list, and the conversions on the conversions list. External Control of the DFDL Processor A DFDL Schema can contain more than one format definition. For example, both a binary and a text format definition can be provided so that the same logical data can be described both ways within the same DFDL schema. To allow one to associate a format definition with a top-level element declaration at run time DFDL allows the top-level element declarations to omit a dfdl:format annotation. DFDL processors can provide means to specify: the data to be processed the DFDL schema to be used the top-level global element declaration to be used (specifying both name of element and namespace of that name) When that top-level element (in 3 above) does not have a dfdl:format annotation, the format name (and namespace) of a format definition to be used. The behavior of the DFDL processor must then be as if the top-level element declaration were written having a dfdl:format annotation on it containing: where the 'formatName' is the specified format from point 4 above. Notice also that like any XML Schema a DFDL schema can have multiple top-level element declarations, so point 3 above is necessary to indicate which of these top-level element declarations is to be the starting point for processing data. The information in point 3 above may be omitted if the DFDL schema contains only one top-level element declaration. The mechanism by which a DFDL processor is controlled to specify points 1 through 4 above is not specified by this standard. For example, command line DFDL processors may use command line options, but DFDL processors embedded in other kinds of software systems may need other mechanisms. Completeness and Default-values for Representation Properties It is a schema definition error when a DFDL schema does not contain a definition for a representation property that is needed to interpret the data. For example, a DFDL schema containing any textual data must provide a definition of the character set 'encoding' property for that textual data, and if it is not part of the format properties context for that data, then the DFDL schema is not well defined. Furthermore, no default values are provided for representation properties as built-in definitions by any DFDL processor. This requires DFDL schemas to be explicit about the representation properties of the data they describe, and avoids any possibility of DFDL schemas that are meaningful for some DFDL processors but not others. For convenience, a standard set of named DFDL format definitions are provided with all DFDL processors. These built-in format definitions must be imported by DFDL schema authors. The namespace URIs which identify these standard format definitions contain version identification so that future versions of this standard can provide updates to these definitions which define more properties. These built-in format definitions are complete in that they provide a consistent definition for all representation properties. Their intended use is as a base for extension. By extending from one of these provided definitions a DFDL schema author can be assured that there are no properties for which there is no definition provided. The built-in format definitions are specified in Section  REF _Ref140941751 \r \h 19  REF _Ref140941755 \h Built-in Specifications. Core Properties Detail This section lists and specifies the core set of DFDL v1.0 properties that may be used in DFDL annotations in DFDL Schema to describe non-XML data formats. The core set of properties is supplemented by additional sets of properties described in separate specification documents. For example, there is a supplement "Advanced Decimal Format Properties" which describes properties for expressing zoned, packed, and BCD formats. The properties are divided into two broad categories: Properties that describe physical representation of data. Properties that are independent of physical representation. Note that property default values are not specified, because in DFDL there is no concept of DFDL-defined defaults. Instead the user must supply a value for all properties that will be used by the DFDL system, typically by use of a dfdl:defineFormat annotation. For this to be usable in practice, the DFDL standard provides several DFDL Schemas that define such dfdl:defineFormat annotations, suitable for business, scientific and casual use. (see Section TBD xref  REF _Ref140941751 \h Built-in Specifications ) Where properties are specific to a physical representation, the property name may choose to reflect this. Where properties are related to a specific logical type group (defined below), the property name may choose to reflect this. TBD: Need some words to cover use of XPATH expressions as property values, including the case where the result must evaluate to a Boolean. Properties that describe physical representation The repType property identifies the physical representation of the element. The DFDL logical types are grouped to illustrate which physical representations apply to each logical type. The allowable physical representations for each logical type grouping are also shown, where the logical type groupings are defined as: Number: xs:double, xs:float, xs:decimal (and restrictions: xs:int, etc) String: xs:string Calendar: xs:dateTime, xs:date, xs:time, xs:duration Binary: xs:hexBinary, xs:base64Binary Boolean: xs:Boolean Opaque: xs:anySimpleType Property NameDescriptionrepTypeString Valid values are dependent on logical type, and can be extended by supplemental specifications..  Number: text, binaryInteger, binaryFloat String: text, xml Calendar: text, binaryInteger Binary: text, binaryStream Boolean: text, binaryInteger Opaque: text, binaryStream Annotation: dfdl:element (all simple types) Properties common to many physical representations Property NameDescriptionbyteOrderEnum Valid values bigEndian, littleEndian. Note that there is, intentionally, no such thing as 'native' endian. This also applies to character data for fixed-width multi-byte character sets when the encoding is not specific. E.g., UTF-16 and UTF-32. Note that when the character set encoding is specific about the byte order (e..g, UTF-16BE), then the byteOrder property is ignored when processing text/strings having that encoding. Annotation: dfdl:element (all simple types) encodingEnum. Values are IANA charsets or CCSIDs Note that there is, deliberately, no concept of 'native' encoding. Conforming DFDL v1.0 processors must accept at least 'utf-8'', 'utf-16BE', 'utf-16LE', 'ascii', and 'iso-8859-1' as encoding names. Annotation: dfdl:element, (all simple types)byteOrderMarkPolicyEnum Valid values required', notAllowed', tolerated, generated' Policy for handling byte order mark when encoding is Unicode. 'required' means strings will be prefixed by a BOM on input, and on output. 'notAllowed' means strings will not be prefixed by a BOM on neither input nor output. 'tolerated' means a BOM is optional on input and is not created on output. 'generated' means a BOM is optional on input and is created on output. Annotation: dfdl:element (all simple types)lengthKindEnum Controls how the associated length, lengthUnits, justification and paddingCharacter properties are interpreted. Valid values are fixed, schemaFacet, xpath, regularExpression, prefixed, nullTerminated, delimited, endOfData. If schemaFacet then any xsd:length or xsd:maxLength facet is used. If nullTerminated then any terminator is ignored as this is just a convenience for terminator="%00". [Includes OMG/CAM properties] TBD: explain all other enums here. Annotation: dfdl:element (all simple types)lengthString. Only used when lengthKind is fixed, xpath or regularExpression. Specifies the length of this element using either a fixed number, an expression to refer to an element earlier in the data, or a regular expression. Annotation: dfdl:element (all simple types)lengthUnitsEnum Valid values bytes, characters, fullUnicodeCharacters, bits, digits Specifies the units to be used whenever an actual length is being used to extract or write data. Applicable when lengthKind is fixed, xpath, prefixed, prefixed2. fullUnicodeCharacters is needed with UTF-16 to indicate that surrogate pairs count as one fullUnicodeCharacter, that is one length unit, not two. (See Section  REF _Ref140945505 \r \h 27  REF _Ref140945508 \h  Appendix: About UTF-16 and Unicode Character Codes above 0xFFFF) Not all enum values are applicable to all physical types. [Subsumes OMG/CAM property attributeInBit] TBD: define all enum values, e.g., prefixed1? prefixed2? Annotation: dfdl:element (all simple types)storedLengthIncludesPrefixBoolean Whether the length given by an expression or a prefix includes the size of the data that specified the length. Annotation: dfdl:element (all simple types)lengthOfPrefixInteger Length of prefix in bytes. Used for prefixed lengths only. TBD: valid values are? 1, 2, 4, 8 [OMG/CAM property prefixLength] Annotation: dfdl:element (all simple types)offsetInteger Offset from the element identified by the offsetFrom property. [OMG/CAM property offset] Annotation: dfdl:element offsetFromExpression Specifies an expression which gives the path to the element from which the offset is measured. Only certain elements may be used to base offsets. Annotation: dfdl:element Properties specific to physical representation text Property NameDescriptiontextCharacterSizeInteger. Value must be 1 or 2. Sometimes the character size can not be deduced from the encoding alone. For example, the memory image from a C program where the characters are ascii encoding, but the C data type being used is wchar, which uses 2 bytes for each. [OMG/CAM property characterSize] Annotation: dfdl:element (all simple types) textDBCSOnlyBoolean. Sometimes a text item will always occupy double bytes even when the encoding implies mixed bytes. [OMG/CAM property DBCSOnly] Annotation: dfdl:element (all simple types) textPadCharacterString. The padding character used as the default for justification of text elements.. May be character or hex or Unicode. In variable width character sets, this character must be a minimum-width character. [OMG/CAM property paddingCharacter] Annotation: dfdl:element (simple type string)textTrimKindEnum Valid values none, padChar, leadingWhitespace, trailingWhitespace, bothWhitespace Indicates whether to trim data on input. Normally only white space may be trimmed in this manner, but if lengthKind is fixed then the padding character can be trimmed instead, as controlled by textStringJustification. Annotation: dfdl:element (simple type string) Properties Specific to text String Logical Types Only Property NameDescriptiontextStringJustificationEnum Valid values left, right, none Controls what happens on output when the actual length of a text string is different from the specified length. If none the string is expected to match the length. Otherwise: - If lengthKind is fixed: If shorter than the specified length it is padded with the pad character. If longer than the specified length it is truncated. - If lengthKind is lengthPrefixed: If the string is longer than any specified maximum length it is truncated. [OMG/CAM property justification] Annotation: dfdl:element (simple type string)Properties specific to text number logical types only Property NameDescriptiontextNumberJustificationEnum Valid values left, right, none Controls what happens on output when the actual length of a text number is different from the specified length. Behaviour as for textStringJustification. Annotation: dfdl:element (simple type number)textNumberSchemeQname Indicates that text numbers are described by a kind of a pattern string called a number scheme. These are named parts of a format definition. An anonymous number scheme can also be specified as a child element of the annotation element. See Section  REF _Ref140946684 \r \h 16.1.7  REF _Ref140946689 \h Number Scheme properties. Annotation: dfdl:element (simple type number) Properties specific to text boolean logical types only Property NameDescriptiontextBooleanTrueRepString Representation value to be used for true Annotation: dfdl:element (simple type boolean)textBooleanFalseRepString Representation value to be used for false Annotation: dfdl:element (simple type boolean) Properties specific to physical representation binaryInteger Binary integers are considered to be a binary representation. Property NameDescriptionintegerSignedBoolean. Indicates that the data is signed. Note: This is independent of the logical type itself which may or may not be sign-capable. Eg, an xsd:int can have as its physical representation an unsigned binary integer. Eg, an xsd:unsignedInt can have as its representation a signed binary integer (this is equivalent to asserting that there will not be any negative values). [OMG/CAM property signed] Annotation: dfdl:element (simple type number, boolean, calendar)integerSignRepEnum This property is used only if integerSigned is true. Valid values are twosComplement, onesComplement, signMagnitude, unsignedBinary, and unsignedDecimal [OMG/CAM Property signCoding] Annotation: dfdl:element (simple type number, boolean, calendar)integerBooleanTrueRepInteger Representation value to be used for true  Annotation: dfdl:element (simple type boolean)integerBooleanFalseRepInteger Representation value to be used for false Annotation: dfdl:element (simple type boolean) Properties specific to physical representation binaryFloat Floats are considered to be a binary representation. Property NameDescriptionfloatTypeEnum This specifies the encoding method for the float. Valid values are unspecified, ieeeExtendedIntel, ieeeExtendedAIX, ieeeExtendedOS390, ieeeExtendedAS400, ieeeNonExtended, ibm390Hex, ibm400Hex [OMG/CAM property floatType] Annotation: dfdl:element (simple type number) Properties specific to physical representation binaryStream Property NameDescriptionbinaryTypeEnum This specifies the encoding method for the binary. Valid values are unspecified, hexBinary, base64Binary, uuencoded Annotation: dfdl:element (simple type binary, opaque) Properties specific to physical representation xml XML is considered to be a special variety of text representation. TBD: Properties to be identified. Number Scheme properties A number scheme defines the properties that together describe how a number is to be interpreted. It contains a formatting pattern property plus properties that qualify the pattern. It can be used when a number has a repType of text. The scheme described below is derived from the ICU DecimalFormat class described here:  HYPERLINK "http://icu.sourceforge.net/apiref/icu4c/classDecimalFormat.html#_details" http://icu.sourceforge.net/apiref/icu4c/classDecimalFormat.html#_details We omit the padding, percentage and currency options. Padding is a function of length and percentage/currency symbols are typically modeled separately. Extensions are number base, allowing blank to be treated as zero, strict versus lenient checking, and allowing a virtual decimal point. If the pattern uses digits/fractions then these must match any XML Schema facets. If not it is a schema definition error. Property NameDescriptionnumberPatternString. Defines the ICU pattern that describes the format of the text number. The pattern defines where grouping separators, decimal separators, exponents, positive signs and negative signs appear. It permits definition by either digits/fractions or significant digits. Allows rounding. The pattern comes in two parts separated by a semi-colon. The first is mandatory and applies to positive numbers, the second is optional and applies to negative numbers. Examples. The first shows digits/fractions and positive/negative signs, the second shows exponent, the third shows significant digits. +###,##0.00;(###,##0.00) ##0.##E0 #,#@# The actual grouping separator, decimal separator and exponent characters are defined independently of the pattern. The actual positive sign and negative sign are defined within the pattern itself. Can be XPATH expression or literal as specified by decorated syntax. Annotation: dfdl:numberSchemenumberGroupingSeparatorString. Defines the actual character that will appear in the data as the grouping separator. Can be empty string indicating no grouping separator. Can be XPATH expression or literal as specified by decorated syntax. Annotation: dfdl:numberSchemenumberDecimalSeparatorString. Defines the actual character that will appear in the data as the decimal separator. Can be XPATH expression or literal as specified by decorated syntax. Annotation: dfdl:numberSchemenumberExponentCharacterString. Defines the actual character that will appear in the data as the exponent indicator. Can be XPATH expression or literal as specified by decorated syntax. Annotation: dfdl:numberSchemenumberStrictCheckingBoolean. Indicates how lenient to be when parsing against the pattern. If false then grouping separators can be omitted, decimal separator can be either . or , (as long as this is unambiguous), exponent can be mixed case, leading positive sign can be omitted, and blank is treated as zero. On output the pattern is always followed. Annotation: dfdl:numberSchemenumberInfinityRepCharacter The value used to represent infinity. Infinity is represented as a single character, typically \u221E, with the positive or negative prefixes and suffixes applied Annotation: dfdl:numberSchemenumberNaNRepCharacter The value used to represent NaN. NaN is represented as a single character, typically \uFFFD. This is the only value for which the prefixes and suffixes are not used Annotation: dfdl:numberSchemenumberBaseInteger Indicates the number base. Annotation: dfdl:numberSchemenumberImpliedPlacesInteger Allowed if pattern does not specify a decimal separator. Gives the number of digits from the right where a decimal point is assumed to be. Annotation: dfdl:numberSchemenumberRoundingModeEnum Valid values roundCeiling, roundFloor, roundDown, roundUp, roundHalfEven, roundFloor, roundHalfDown, roundHalfUp The rounding increment is specified as part of the pattern. Annotation: dfdl:numberScheme Properties independent of physical representation The use of the following properties is independent of physical representation. General properties TBD: many of these are specialty properties for dealing with uncertainty. Move them to a special section and then eliminate redundant explanation in the detailed semantics section about these properties. Property NameDescriptioninputValueCalcXPATH expression An expression that performs some operation to derive the value of the current element. An empty string is a valid expression for a string-typed element. An element that specifies an inputValueCalc expression has no representation in the underlying data. It simply manipulates other elements values to derive its own value. Annotation: dfdl:element (all simple types)outputValueCalcXPATH expression An expression that performs the inverse of an elements inputValueCalc expression. An empty string is a valid expression for a string-typed element. All elements that derive their value via an inputValueCalc expression will have no representation in the output. These elements need not specify an outputValueCalc. In many cases, however, the elements from which the value of the current element is derived are hidden. In these cases, the output representation will have to be calculated from the value of this or other elements using an outputValueCalc expression. Annotation: dfdl:element (all simple types) Properties for text markup The following properties apply to all elements and groups that use text markup to initiate, terminate and/or separate elements. Text markup applies equally well to binary data, however it is called 'text' markup because it is much more comonly used for textual data formats.. Property NameDescriptionescapeSchemeIndicates that this item is quoted/escaped by a named, previously defined escape scheme. An anonymous escape scheme can be specified as a child element of the annotation element. See Section  REF _Ref140936368 \r \h 16.2.6  REF _Ref140936382 \h Escape Scheme properties. Annotation: dfdl:element, dfdl:sequence, dfdl:choiceinitiatorString. Specifies a text string that marks the beginning of an element or group of elements. Can be XPATH expression or literal as specified by decorated syntax. If literal, decorated syntax to allow hex versus text. If set to empty string then no initiator is expected. Annotation: dfdl:element, dfdl:sequence, dfdl:choiceinitiatorIgnoreCaseBoolean Whether mixed case data is accepted when matching initiator on input. On output always use the initiator as specified. Annotation: dfdl:element, dfdl:sequence, dfdl:choiceinitiatorSeparatorString. This string is found after the initiator, but before the value. It's purpose is to allow a wildcard to match data that has the syntax of initiated format. Empty string is acceptable and means there is no initiatorSeparator. Annotation: dfdl:anyterminatorString. Specifies a text string that marks the end of an element or group of elements. Can be XPATH expression or literal as specified by decorated syntax. If literal, decorated syntax to allow hex versus text. If set to empty string then no terminator is expected. Annotation: dfdl:element, dfdl:sequence, dfdl:choiceterminatorIgnoreCaseBoolean Whether mixed case data is accepted when matching terminator on input. On output always use the terminator as specified. Annotation: dfdl:element, dfdl:sequence, dfdl:choiceseparatorString. Specifies a text string that appears between two elements in a group. Can be XPATH expression or literal as specified by decorated syntax. If literal, decorated syntax to allow hex versus text. If set to empty string then no separator is expected. Annotation: dfdl:sequenceseparatorPolicyForMissingElementsEnum Valid values keep, suppress, suppressAtEnd Specifies whether to expect a separator when an element is missing. suppress would typically be used where elements have initiators. keep or suppressAtEnd would typically be used where elements do not have initiators. Annotation: dfdl:sequence Properties for aligned data The following properties are used to define alignment rules. Property NameDescriptionalignmentPositive integer. Gives the alignment required for the beginning of the item. Values are usually 1, 2, 4, 8, 16 to match memory word alignment boundaries, 8096 to match page alignment boundaries. However, any positive integer power of 2 is allowed. Annotation: dfdl:elementfillByteByte. Used on output to fill space between two aligned elements. This includes filling empty bits when fewer than a whole byte worth of bits is needed. In this case how the partial fillByte is aligned in the missing bits is unspecified. Annotation: dfdl:element leadingSkipCountPositive integer Number of bytes to skip before alignment applied. Annotation: dfdl:elementtrailingSkipCountPositive integer Number of bytes to skip after the element, but before considering the alignment of the next element. Annotation: dfdl:element Properties for repeating data These properties are additionally used when elements in the data are repeating, that is, the data is in the form of an array. TBD: This set of properties will need revising to handle multi-dimensional arrays and sparse arrays. Property NameDescriptionoccursKindEnum Valid values fixed, xpath, delimited Specifies how the actual number of occurrences is to be established. fixed means use the value of schema property maxOccurs, xpath means use the value of a named element earlier in the data, delimited' means that separators, initiators, and/or terminators dictate the number. Annotation: dfdl:elementoccursPathExpression A path expression referencing another element that provides the number of occurrences. Annotation: dfdl:element,occursPathUnitsEnum Valid values bytes, bits, items Specifies the units to be used when interpreting the number of occurrences given by occursPath. Typically this would be items but sometimes the space is allocated as a block in which case the number of items is the number that fit in the block. In this case the occursPath gives the size of the block, and the number of items in it depends on the size of the items. For fixed size items it is the size of the block divided by the size of the items. For variable-size items there is no formula for directly computing how many items there are. Annotation: dfdl:elementoccursSeparatorString. Specifies a text string that appears between two items in the array. Can be XPATH expression or literal as specified by decorated syntax. If set to empty string then no occurs separator is expected. Annotation: dfdl:element The above properties handle input and output for a logical one dimensional array of any type. A DFDL Array is logically just an XML element with maxOccurs equal to the number of elements in the array. This element could be read from data in several forms. For example, the data might be a simple comma-delimited list in ASCII on one line, such as: 8.5,9.6,10.7,11.8,1.9,2.0,3.1,4.2,34.1,56.2,68.3,80.4,45.7,49.2,72.7 To read this array from comma delimited text, DFDL annotations would be added, as in:  Properties for null and default value handling These properties are used to control when any XML Schema default attribute is used, and, if the XML Schema nillable attribute is set, when and how values are interpreted as having the logical meaning null. Property NameDescriptiondefaultWhenMissingEnum Valid values never, always, onInput, onOutput Controls when missing elements are defaulted on input and output. An element may only be defaulted on input if it is optional, and on output if it is mandatory. The value 'onInput' means that elements missing from the input stream are substituted with their default value if specified. However if a element is missing on output the default value will not be substituted for the element in the output stream since it must be optional. The value 'onOutput' means that a representation will be written using the default value, but no defaulting will take place on input since the item must be mandatory. Annotation: dfdl:element (all simple types)initiatedElementMissingWhenEnum Valid values absent, empty, absentOrEmpty Specifies when an element with an initiator is treated as missing, and therefore when default value processing can be applied. If absent then element is missing if the initiator is missing. If empty then element is missing if initiator is present but value is not. If absentOrEmpty then element is missing if either of the above apply. Annotation: dfdl:element (all simple types)initiatedElementNullWhenAn enumeration On input specifies when an initiated element with nullKind not set to missing, is treated as null initiatorAbsent Just the null value is present, no initiator or terminator (if defined) is present. initiatorPresent The initiator, null value and terminator (if defined) are present. (This is the normal case) initiatorAbsentOrPresent If either of the above conditions apply. On output specifies what is to be output when an initiated element is null. initiatorAbsent Just output the null value itself with no initiator or terminator (if defined). initiatorPresent Output the initiator, null value and terminator (if defined). initiatorAbsentOrPresent Output the initiator, null value and terminator (if defined).nullKindEnum Valid values literalValue, logicalValue, literalCharacter, missing, 'xpath' Specifies the nature of null processing. Only significant on nillable elements. If literalCharacter then nullValues must be any single character. On input the element value is null if all characters in the data match the nullValues character. On output if the element value is null the nullValues character is output to the required length. Only applicable to fixed length elements. Only applicable for fixed-width character sets. If literalValue then nullValues must be any string value that can fit in the element. On input the element value is null if the data matches nullValues literally without any conversion. On output if the element value is null nullValues is output. If logicalValue then nullValues must be any value that matches the simple type. On input the element value is null if the data, converted to its logical type, matches nullValues. On output if the element value is null, nullValues is converted to its physical representation and output. If missing nullValues is not used. On input the element value is null if it is not present in the data. On output if the element value is null, no data is output. For elements with an initiator the initiatedElementMissingWhen property is used to determine when the element is missing. If 'xpath' then the nullIndicatorPath is used to find a flag/indicator which is tested to determine whether the element is null. Annotation: dfdl:element (all simple types)nullValuesString or list of strings The null values of the element. This is a list since several values may indicate null. For literalValue , logicalValue, and 'xpath' several null values may be specified in this property. On output the first value in the list is used. Annotation: dfdl:element (all simple types)nullIndicatorPathExpression Used when nullKind='xpath'. A path expression referencing another element that provides the logical value to compare with nullValues On input, the element value is null if the provided value matches in nullValues. When null, If the element is fixed size then it will be skipped on input, filled with (TBD: fillbyte?) on output.. When null If the element is variable size with minimum size > 0, then a minimum size item will be skipped over, or on output filled (TBD with fillbyte?). When null If the element is variable size with minimum size 0, then a size zero object is expected on input, and a size 0 object will be generated on output. If non-null then the element is parsed or output normally. Annotation: dfdl:element (all simple types)nullIndicatorIndexInteger The nullIndicatorIndex property is optionally used in conjunction with the nullIndicatorPath property to reference an array element that determines whether this element is null. This is done by taking the element referenced by the nullIndicatorPath as the base and using the value of the nullIndicator as a (one based) index from the base. The units of the index will be that of the element referenced by the nullIndicatorPath property. The nullIndicatorIndex property is only applicable when the nullKind property is 'xpath'. The output behavior is symmetric: the indicator location is calculated and its value set if the element is null or not null accordingly. This property requires that nullIndicatorPath is defined. It is a schema definition error if this is defined and nullIndicatorPath is not defined. Annotation: dfdl:element (all simple types)useNullValueForDefaultBoolean If true then the first value in nullValues is used when an element is missing on output rather than the default value. Annotation: dfdl:element (all simple types) Escape Scheme properties An escape scheme defines the properties that together describe the text escaping rules in force when text markup is present in the data. There are two variants on such schemes, the use of escape character(s) to switch off interpretation of a subsequent character, or the use of opening and closing quote character(s) to switch off interpretation of a contiguous group of characters. The variants can be used together, for example, MS Excel CSV use double quotes to surround data that includes a comma, and uses another double quote to escape a double quote in the data. TBD: Nested quotes support needs to be added sufficient to handle single quotes nesting double quotes or double quotes nesting single quotes (as in XML - a popular scheme these days even for non-XML data formats). Property NameDescriptionopenQuoteString Specifies the characters that open the quoting. If empty, quoting is not used. If not empty, closeQuote must also be not empty. Can be a path expression or literal as specified by decorated syntax. Annotation: dfdl:escapeSchemecloseQuoteString Specifies the characters that close the quoting. If not empty, openQuote must also be not empty. Can be a path expression or literal as specified by decorated syntax. Annotation: dfdl:escapeSchemeescapeString Specifies the characters that escape the subsequent character. If empty, escape is not used. If quoting is in use, escape is only active within quotes. Can be a path expression or literal as specified by decorated syntax. Annotation: dfdl:escapeSchemegenerateQuotesEnum Valid values always, whenNeeded When to quote on output. If whenNeeded the characters that cause quotes to be generated are any in-scope separator or terminator. Annotation: dfdl:escapeSchemegenerateEscapeBoolean Whether to escape on output. If quoting is in use, only the first character of openQuote and closeQuote are escaped. If quoting is not in use, the first character of any in-scope separator, occursSeparator or terminator character is escaped. Annotation: dfdl:escapeScheme Parse Strategies, Length Strategies, and Conversions This section describes the way that parse strategies, length strategies, and conversions are able to address the complex issues in DFDL semantics. This section illustrates with a few examples how some of the more complex issues associated with optionals, null, and default values can be handled by means of the above defined strategies and conversions. Common Functions Many of the parse/length strategies and conversions will need some frequently used common functions. Function characterWidth() The width of a character is the size of its representation in bytes. The calculation of the width of a character uses these properties: encoding textCharacterSize textDBCSonly lengthUnits (used only when encoding="UTF-16" (or the UTF-16LE or UTF-16BE variant). Character encodings are themselves either intrinsically fixed or variable width, but this is modified by additional properties. This table gives the means to calculate the width of a character in an encoding: character's encoding widthfixed, 1 byte (e.g., ASCII)fixed, 2 byte (e.g., UTF-16)variable 2 byte (lengthUnits = fullUnicodeCharacters, encoding=UTF16)fixed, 4 byte (e.g., UTF-32)variable (e.g., UTF-8 or Shift_JIS)textCharacterSizetextDBCSOnly12FALSETRUE122variable Min=2, Max=44variable. Min = 1, Max = encoding dependent2 We define the term fixed width encoding to mean an encoding and associated other representation properties where the value in the bottom row of the above table is a fixed integer. The term variable width encoding is the opposite. In a variable width encoding, the characters have a minimum and a maximum size. The maximum depends on the encoding, but is typically either 3 (Shift-JIS), or 4 (UTF-8, UTF-16 with fullUnicodeCharacters).  The function characterWidth(ctxt, mem) returns one value which is the integer width of the characters (in 8-bit bytes) if they are of fixed width, or the distinguished value 'variable' if the characters are variable width. Any parse strategy which calls the above function is assumed to require the properties used in the above table, plus dfdl:encoding. Function LEX Lexical Analyzer Many strategies are based on strings that are terminated by delimiters. A common function LEX() is used to express the common behavior. pos1, strVal = LEX(src, pos, ctxt, mem, localTerminator) This function scans the source stream to determine a string value and a position. It takes into account escape schemes when searching for delimiters to end the string. The localTerminator argument indicates a local terminator for the string. If found, the string is returned, and the pos1 that is returned includes the additional length of this localTerminator. The string value returned does not include the characters of the local terminator. If the string is terminated by a delimiter found in the ctxt, then the string is returned and the pos1 that is returned does not include the length of any delimiter. Rather, pos1, is the first position after the last character of the string payload. LEX always returns a pos1 and a strVal because end-of-data is always an accepted delimiter, so if no delimiters nor terminators are found, LEX will return the entire rest of data. LEX raises a processing error if conversion of data into as string based on the character set encoding causes an error due to illegal bit patterns that are not legal for the encoding.  The LEX function uses all the same properties used by characterWidth() plus dfdl:byteOrder in some situations is required. It optionally uses escape schemes if found in the context. Function REGEXP Regular expression extractor Some strategies use regular expressions to delimit data. A common function REGEXP() is used to express the common behavior: pos1, strVal = REGEXP(regexp, src, pos, ctxt, mem) The function scans the source stream to determine a string value that is the longest match to the regular expression given as the regexp argument. Escape schemes are not considered by REGEXP. pos1 = pos and strVal is err (the distinguished error object) if the regular expression has no match. REGEXP raises a processing error if conversion of data into as string based on the character set encoding causes an error due to illegal bit patterns that are not legal for the encoding.  The REGEXP function uses all the same properties used by characterWidth(). Length Strategy Examples Some of the length strategies and conversions built in to DFDL are very simple. We will use the shorthand pname="value" for dfdl:property('pname')="value" to make the text more compact. name="binaryByte" type="byte" guard="{ repType="binary" } required="lengthUnits lengthKind" LEN='if (dfdl:isPropertyDefined("length")) then (if (lengthUnits="bits" and lengthKind="fixed") then dfdl:property('length') else 8) else 8' FL="LEN" test="FL <= 8" name="binaryShort" type="short" guard="{ repType="binary" } required="byteOrder lengthUnits lengthKind" LEN='if (dfdl:isPropertyDefined("length")) then (if (lengthUnits="bits" and lengthKind="fixed") then dfdl:property('length') else 16) else 16' FL="LEN" test="FL <= 16" There are similar definitions to the above for binaryInt, binaryLong, binaryFloat, binaryDouble. name="binaryFixedString" type="string" guard="{ repType="binary" and lengthKind="fixed" and characterWidth()!='variable' and lengthUnits='characters' and (byteOrderMarkPolicy='required' or byteOrderMarkPolicy='notAllowed') } required="length" LEN='{ length * characterWidth() + (if (byteOrderMarkPolicy="required") then characterWidth() else 0) }' FL="LEN" test="" name="binaryPrefixedString" type="string" guard="{ repType="binary" and lengthKind="prefixed" and characterWidth()!='variable' and lengthUnits='characters' and (byteOrderMarkPolicy='required' or byteOrderMarkPolicy='notAllowed') } required="storedLengthIncludesPrefix lengthOfPrefix byteOrder" LEN='{ * characterWidth() + (if (byteOrderMarkPolicy="required") then characterWidth() else 0) }' FL="variable" test="" Create this new DFDL schema fragment: pos1, val, ... = P(newFragment, src, pos, ctxt, mem, path, rval) return pos1 (for LEN) return both for parser. test="( lengthUnits="characters" and (storedLengthIncludesPrefix="true") and (lengthOfPrefix >= characterWidth())) or (lengthUnits="bytes") " TBD: MikeB: ok, I've had enough programming in MS Word. The right way to do this is to write code in Java or other language. Ideas: use annotation preprocessor so that these classes can print themselves out in suitable form for inclusion into the spec directly. APT preprocessor would allow us to capture the text of key methods perhaps. Conversion Examples TBD Element Parse Strategy Examples An element parse strategy contains two parse functions, PRE and POST, and the fixed length calculator FL. We describe a parse strategy by reference to a grammar. For Element Parse Strategies the grammar is: E = AP LSB INIT EV TERM TSB The symbols in this grammar represent contiguous sets of bits. They are defined more specifically as follows: BSTR: A character string (though ultimately of bits at the bottom level) Specified as a string in the schema which can be literal or calculated via an expression. BITS: Binary Bits - given without respect to character set encoding. Not specified as a string in the schema.. AP = BITS: Alignment Padding LSB = BITS: leading skip bytes INIT = BSTR | BSTR INITSEP INITSEP = BSTR: Initiator Separator - value given by the initiatorSeparator property EV = BITS: Element's Value the value depends on type and properties for controlling the representation of that type. Recursively, many other elements can be found inside EV if EV happens to be an array or sequence group. TERM = BSTR: Terminator TSB = BITS: trailing skip bytes The PRE and POST functions in an element parse scheme address the meanings of: PRE: AP, LSB, INIT POST: TERM TSB Corresponding to each of the symbols in this grammar are parse functions. For example, corresponding to the AP (alignment padding) symbol and the LSB (leading skip bytes) are the parse functions: pos1 = AP(pos, ctxt) pos2= LSB(pos1, ctxt) A specific parse strategy will provide a definition of the PRE and POST functions, which have these signatures: pos1, mem1 = PRE(decl, src, pos, ctxt, mem, path, rval) pos1, mem1 = POST(decl, src, pos, ctxt, mem, path, rval) The definitions of PRE and POST for a specific parse strategy will be defined in terms of the parse functions for the symbolic elements of the grammar, e.g., the AP and LSB functions. Basic Binary Element Strategy This parse strategy handles the alignment and skip bytes padding around binary elements. Initiators and terminators are not supported in this strategy. guard: repType="binary" used: alignment, alignmentUnits, leadingSkipBytes ignored: initiator, terminator (TBD: suggest DFDL processors may want to warn if present?) The parse function PRE(pos, ctxt, mem) is defined as: pos1 = AP(pos, ctxt) pos2 = LSB(pos1, ctxt) INIT is size zero, INITSEP is size zero return pos2, mem where AP and LSB are parse functions defined as below in Section TBD: xref Alignment and Section TBD: xref skip bytes. The parse function POST(pos, ctxt, mem) is defined as: pos1 = TSB(pos, ctxt) TERM is size zero. return pos1, mem where TSB is as defined in Section TBD: xref skip bytes. Alignment Alignment requirements determine where an element's representation starts in the input/output stream. There are two properties which control the data alignment: alignment - an integer 1 or greater and which is a power of 2 alignmentUnits - bits or bytes An element's representation is aligned to N units if the address of the first unit of the representation is divisble by N. Address 0 is considered to satisfy all alignment requirements. For example, if alignment=4, and alignmentUnits='bytes', then the element's representation must begin at 0 or a multiple of a 4 byte address. I.e., 0, 4, 8, 12, 16 and so on. Optional elements cannot have alignment properties different from the elements that follow them. It is a schema definition error if an optional element has an alignment property different from that of the element following it.  Formally, we define a parse function AP to specify exactly how alignment padding works. The signature of AP is: pos1 = AP(pos, ctxt) The definition of AP(pos, ctxt) is as follows: Create a new schema construct which we'll call alignPad:  { (if dfdl:property('alignmentUnits') = 'bytes' then 8 else 1) } { dfdl:variable('alignmentUnitsBits') * dfdl:property('alignment') } { dfdl:property('alignmentBits') - ( $pos mod dfdl:variable('alignmentBits')) } This schema computes the number of bits of alignment padding and expresses a schema element having that number of bits. The expression $pos returns the position, pos, as passed to the AP function. The expression $uniqueNewName is replaced by a generated identifier that has not been previously used. We then parse recursively this newly created schema fragment to parse the alignment padding. pos2, val, mem, rval = P(alignPad, src, pos, ctxt, emptyPath, emptyRVal) Note that we supply dummy values for the path and root value approximation as neither is needed for this simple use. Of the values returned we discard all but the new pos2 position. We return pos2 as the value of the AP function. Skip Bytes There are two properties which are used in the parse functions for skipping bytes, LSB, and TSB. leadingSkipBytes trailingSkipBytes The signatures of LSB and TSB are: pos1 = LSB(pos, ctxt) pos1 = TSB(pos, ctxt) The definition of LSB is: return ( if (dfdl:isPropertyDefined('leadingSkipBytes') then pos + 8 * dfdl:property('leadingSkipBytes') else pos) The definition of TSB is: return return ( if (dfdl:isPropertyDefined('trailingSkipBytes') then pos + 8 * dfdl:property('trailingSkipBytes') else pos) Optional Element Parse Strategies Optional by Initiator Tag guard: "isDefined('initiator') and $initiator != "" and isOptional() TBD: ignore PRE and POST for the time being. The behavior of the EXISTS parse function is defined in terms of a source-to-source rewrite of the optional element's declaration, decl1. Create a new element declaration decl2. The decl2 is then parsed as follows: pos1, val,, mem1, rval1 = P(decl2, src, pos, Sctxt, mem, path, rval) If a discriminating assertion is evaluated and succeeds then we return true from EXISTS. If a processing error occurs or a discriminating assertion fails then we return false from EXISTS. The behavior of the CONTENT parse function similarly uses a source rewrite. Recall the signature of the CONTENT parse function is: pos2, val, mem2, rval1 = CONTENT(res, decl1, src, pos1, Sctxt, mem1, path, rval) The processing first looks at the res value, which is true or false as returned by the EXISTS call. If it is true, then the initiator was found so to some degree the optional element is present. We first construct this element, called initElement: We parse this element: pos1, val, mem1, rval1 = P(initElement, src, pos, Sctxt, mem, path, rval) What the above element does is absorb the initiator. We already know it is present. Next we construct an element to obtain the content, contentElem. This is created by taking the original optional element declaration, removing the maxOccurs and minOccurs so that it is no longer optional, removing any property binding for dfdl:initiator from it (by removing them syntactically, and by placing empty bindings for them: //TBD: could be an immediate type also not just a named type. Then we parse as: pos2, val, mem2, rval1 = E(initElement, src, pos1, Lctxt, Sctxt, mem1, path, rval) The above element extracts the contents, but as a string only. If a parse error occurs we return err. Otherwise we examine val. If it is an empty string, then we have the situation where the initiator was found, but the contents of the element are empty. At this point we have whether the element is absent or empty or present. We can also examine the declaration to determine whether the element is nillable, and whether it has a default value or not. We have all the information we need to interpret the data with respect to these DFDL schema properties: initiatedElementMissingWhen defaultWhenMissing initiatedElementNullWhen nullKind nullValues nullIndicatorPath nullIndicatorIndex There are a large number of combinations here. The flow charts in the next section determine how the decision is made about whether to return a nil value, a default value, or a regular value obtained by parsing the representation. Input Default, Null, Missing, Optional Flow Charts These flow charts apply for both optional and non-optional data, and the case of initiated or non-initiated data.  SHAPE \* MERGEFORMAT   SHAPE \* MERGEFORMAT   SHAPE \* MERGEFORMAT  Clarifying Examples This section provides some clarifying examples. Clarifying Examples - Opaque and HexBinary TBD: where should this material go? We need a crisp definition of what hexBinary means in DFDL, and this provides that clarification. Perhaps this goes back in the data model section? TBD: convert these examples to use XPath expressions as the way to address the values. Will need a dfdl:byteAt() function to address into the binary corresponding to a hexBinary. String Type This string contains Japanese characters. "2003t^08g27e" In UTF-8 encoding, the hexadecimal data bytes are these: 32 30 30 33 e5 b9 b4 30 38 e6 9c 88 32 37 e6 97 a5 Let us assume we have this collection of bytes in a file. The length is 11 characters, 17 bytes. In DFDL, we can describe this as: Now consider this XPath expression involving element d: substring(d, 1, 10) // substring starting at position 1 for 10 chars It's pretty clear that this should return a 10 character string containing "2003t^08g27", which is missing the final character of the string. XPath expressions on strings support only access to the data as strings and characters. In addition: string-to-codepoints(substring(d, 5, 1)) would return the character codepoint value 0x5e74 , which is the Unicode codepoint for the 5th (base 1 indexing in XPath) character which is the "t^" or 'year' character. HexBinary Type Suppose we wanted to model this same data logically as a hexBinary 'blob'. Now, consider this XPath: substring(d, 1, 10) // substring starting at position 1 for 10 chars. This should return "32303033e5 ", that is, the first ten hex digit characters. This is consistent with the type being hexBinary, and not string. Byte Array type Suppose we wanted to model this same data logically as an array of bytes. Now, consider this XPath: d[5] This would return the byte integer value 0xE5, or 229, which is the contents of the 5th (base 1 indexed) byte viewing the data not as character string data, but as a binary array of bytes. Opaque 'any' wildcard type Suppose we wanted to model this same data as an opaque wildcard: This is translated into a hidden element; hence, does not become visible in the data model or implied schema of the data but otherwise behaves exactly like the hexBinary case described above. Built-in Specifications TBD: this section gives the names, import URLs for, rep-property definition sets, property definitions, etc. for the built-in named format definitions. I won't go so far as to say conversion definitions and registrations are made explicit here since many of these will want to be built-ins for implementations. Note that the URLs for importing these must contain the version number of the standard so that future revisions of the standard can define new built-in format definitions without breaking older schemas. Properties Supported by Specialized Annotation Elements The table below indicates the subset of representation properties allowed on each of the specialized annotation elements. Schema ConstructMatching Annotation ElementAllowed propertiesxs:sequenceencoding, separatorEncoding, separator separatorKind (others TBD)xs:choiceTBDxs:element declaration or reference without occurrences or with minOccurs=0, maxOccurs=1 (aka optional)initiator, terminator (TBD: everything meaningful for elements, and optional elements)xs:element declaration or reference with 2 or more possible occurrencesoccursSeparator initiator, Terminator (TBD: everything meaningful for elements, including occurance properties)xs:any(TBD: suitable for any wildcards)all other locations That is, there is no helper annotation elementAll properties Security Considerations When writing data. All locations must be properly initialized before writing so as to prevent accidental (or purposeful) transmission of data in the unused parts of data formats. Even when a DFDL description does not specify that data should be written to a particular part of the output representation, a defined pattern should always be written. All DFDL processors must check when writing data, that the representation properties that control filling and padding are defined by the DFDL schema. It is an error if they are not defined, and the DFDL processor must fail if they are not defined so that it is certain no region of the output data has unspecified contents. If regions within a DFDL-described data object are encrypted, then when decrypting them proper means must be used to assure secure passage of passwords to the decrypting software. Such means are beyond the scope of the DFDL language specification. In addition, if encryption passwords/keys are stored in DFDL schema-described data, then proper means must be used to assure that the decrypted form of these passwords is not revealed. Such means are beyond the scope of the DFDL language specification. Contributors Michael J. Beckerle, IBM Software Group, Westborough, MA, USA Martin Westhead, Avaya, Milpitas, CA, USA James Myers, NCSA, Urbana-Champaign, IL, USA Suman Kalia, IBM Software Group, Markham, Ontario, Canada Steven M. Hanson, IBM Software Group, Hursley, UK Tom Sugden, EPCC Tara Talbot, PNNL, Richland, WA, USA Robert McGrath, NCSA, Urbana-Champaign, IL, USA Geoff Judd, IBM Software Group, Hursley, UK Dewey M. Sasser, IBM Software Group, Westborough, MA, USA David A. Loose, IBM Software Group, Westborough, MA, USA Eric S. Smith, IBM Software Group, Westborough, MA, USA Kristoffer H. Rose, IBM Research, Hawthorne, NY, USA Intellectual Property Statement The OGF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the OGF Secretariat. The OGF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this recommendation. Please address the information to the OGF Executive Director. Disclaimer This document and the information contained herein is provided on an As Is basis and the OGF disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties of merchantability or fitness for a particular purpose. Full Copyright Notice Copyright (C) Open Grid Forum 2005, 2006,2007. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees. References TBD: OGF requires that only permanent documents should be cited as references. Other materials, such as Web pages or working groups, should be cited inline (i.e., see the Global Grid Forum, http://www.ogf.org). References should conform to a standard such as used by IEEE/ACM, MLA, Chicago or similar. Include an author, year, title, publisher, place of publication. For online materials, also add a URL XML 1.0  HYPERLINK "http://www.w3.org/TR/REC-xml" http://www.w3.org/TR/REC-xml XML 1.1  HYPERLINK "http://www.w3.org/TR/xml11/" http://www.w3.org/TR/xml11/ Unicode (now at version 4.0)  HYPERLINK "http://www.unicode.org/" http://www.unicode.org/ IANA character set encoding names: ( HYPERLINK "http://www.iana.org/assignments/character-sets" http://www.iana.org/assignments/character-sets) XML Schema:  HYPERLINK "http://www.w3.org/XML/Schema" http://www.w3.org/XML/Schema [RFC 2119] IETF (Internet Engineering Task Force).  HYPERLINK "http://www.ietf.org/rfc/rfc2119.txt" \t "_top" RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. 1997. TBD: OMG/CAM/TD Model reference XSIL homepage,  HYPERLINK "http://www.cacr.caltech.edu/SDA/xsil/" http://www.cacr.caltech.edu/SDA/xsil/ Binary Format Description (BFD) Language, http://collaboratory.emsl.pnl.gov/sam/bfd/ Appendix: About UTF-16 and Unicode Character Codes above 0xFFFF When we define UTF-16 to be a fixed-width double-byte wide character set we say that each UTF-16 codepoint is represented by 2 bytes. Notice the careful use of the term 'codepoint' here. Unicode characters can have character codes as large as 0x10FFFF which requires 3 bytes to store (21 bits actually); however in UTF-16 characters with more than 2 bytes of code are encoded as two codepoints, called a surrogate pair; hence, UTF-16 is fixed-width, 2 bytes per codepoint. It is not 2 bytes per Unicode character. UTF-16 is really a variable-width encoding, but the characters that require the surrogate-pair treatment are so infrequently used that UTF-16 is most often treated like a 16-bit fixed-width character set. It is the acknowledgement of the existence of surrogate pairs that leads to the codepoint vs. character code distinction. UTF-32 is a fixed width encoding with a full 4-bytes per character code. It represents all of Unicode with the same width per character. Hence, when we refer to lengths in character strings we will often refer to length in characters, but we qualify that it means 2-byte codepoints when the character set encoding is UTF-16. Hence, when the property lengthUnitKind is 'characters' and the charset is 'UTF-16', then the units are actually 16-bit codepoints, not Unicode characters. Use instead the lengthUnitKind='fullUnicodeCharacters' to get the number of true characters, not the number of 16-bit codepoints. TBD: Extra Material and Misc Parse Topics TBD: The topics here need to be organized into the specific parse strategy, length strategy, and conversions material. Textual Data where lengthUnits='characters' Textual data is defined to mean either data of type string (independent of repType), or data where the repType property is 'text' or 'xml'. When the type of the data item is a simple type, but is not of type string, but the repType is 'text' or 'xml', then we refer to the bits of the representation of the data item when viewed as textual characters as the underlying string representation. When the type of the data item is string, then we can think of the contents of the string and the underlying string representation as the same and we do not distinguish the two. When we refer to the length of a string, we can by context be referring to either an element of type string, or a non-string element's underlying string representation. The payload of a string is the characters making up the value of the string. This excludes any other information needed to determine the length such as delimiters. The payload also does not include in it any byte-order mark. (Byte order marks are not characters.) The length of a string in bytes includes the length of byte order marks, if present, and the length of the payload's characters. However, it excludes the length of any prefix fields where length counts are stored. The table below indicates how to determine the length in bytes for a string: lengthKindencodinglengthUnitsother propertyother property valueDirectionInputOutputMinimumMaximumMinimumMaximumfixed, xpath, prefixed (value is N)fixed, 1 byte (e.g., ASCII)characters, or fullUnicodeCharacterstextCharacterSize11 * N22 * Nfixed 2-byte (e.g., UTF-16)charactersbyteOrderMarkPolicyrequired(2 * N) + 2notAllowed2 * Ntolerated2 * N(2 * N ) + 22 * Ngenerated2 * N(2 * N) + 2(2 * N) + 2fullUnicodeCharactersbyteOrderMarkPolicyrequired(2 * N) + 2(4 * N) + 2(2 * N) + 2(4 * N) + 2notAllowed2 * N4 * N2 * N4 * Ntolerated2 * N(4 * N ) + 22 * N4 * Ngenerated2 * N(4 * N ) + 2(2 * N) + 2(4 * N) + 2fixed 4-byte (e.g., UTF-32)characters or fullUnicodeCharactersbyteOrderMarkPolicyrequired(4 * N) + 4notAllowed4 * Ntolerated4 * N(4 * N) + 44 * Ngenerated4 * N(4 * N) + 4(4 * N) + 4variable (e.g., UTF-8 or Shift_JIS)characters or fullUnicodeCharacterstextDBCSOnlyTRUE2 * NFALSENN * max Character WidthNN * max Character Widthregexpvariabledelimited, null-Terminated, endOfDatavariable The above table can be summarized into 7 length protocols (based on color/shading above): S1 - formula - the length in bytes can be computed from the number of characters by a fixed formula. S2 - check BOM, then use formula S3 - scan, converting characters while counting bytes. S4 - adjust for BOM, then scan, converting characters while counting bytes S5 - check BOM, then scan converting characters while counting bytes S6 - scan, converting characters, while counting bytes and while searching for regular expression match S7 - scan, converting characters, while counting bytes and while searching for delimiters. This length strategy is also known as delmited scan. String Length Given in Bytes When the lengthUnits property is 'bytes', then the specified length of the representation in bytes is obvious, but the number of characters in the string or underlying string, and the values of those characters must be determined differently. In this case when the above table specifies a formula, there is a formula, given the number of bytes, for determining the number of characters. When the table above indicates a variable-width encoding, then the number of characters can only be determined by parsing the actual data into characters, and counting them. Moreover, this must be done only up until the number of bytes indicated as the length. The above discussion can be summarized into these length protocols: S8 - formula - the number of characters can be computed from the number of bytes by a fixed formula. S9 - check BOM, then formula S10 - scan, converting and counting characters while limiting to the number of bytes. S11 - adjust for BOM, then scan converting and counting characters while limiting to the number of bytes. S12 - check BOM, then scan converting and counting characters while limiting to the number of bytes. When the length in bytes is not a multiple of the fixed character width, then the extra bytes at the end are ignored on input and filled with the byte given by the fillByte property on output. When the length in bytes includes one or more bytes making up a final fragment of a character in a variable-width character set. Then these additional bytes are ignored on input, and are filled with the character given by the padChar property on output. It is a schema definition error if the lengthUnits='bits' for a string, or for any element type when repType="text". Binary type length protocol When repType="binary", and the simple type is not string, then the size of the representation is fixed size depending on the type and other information in the DFDL schema. This length protocol is called SBF for Simple type Binary, Fixed length. S7 Delimited Scan Length Protocol and Escape Schemes The context contains escape schemes which can be associated with a specific construct's delimiters, or can be inherited generally from higher in the context. When we search the context to determine the set of delimiters we must scan for when parsing, we also retrieve the associated escape schemes if any. Lexical analysis (a.k.a., the 'lexer') uses the complete set of delimiters with associated escape schemes to find data and the delimiters which separate it into lexical data between the delimiters. When scanning the data looking for delimiters, a specific algorithm is used. Each delimiter is associated with an escape scheme which determines when the scan is looking for that particular delimiter and when it is not. The set of delimiters is divided into the local delimiter, and any delimiters from enclosing constructs. These include delimiters specified via these properties: separator occursSeparator (including postfix separators (TBD: currently only on arrays)) terminator The behavior of the scanner when it encounters the element's own terminator (not quoted or escaped), is to return the string data, and the position, pos, in the source stream is after the terminator. The behavior of the scanner when it encounters one of these delimiters that is defined on an enclosing construct is to return the string data, and position the source stream before this delimiter. That is, the scanner does not consume that delimiter when computing the new pos result. The invariant that this maintains is that a parser for any construct (simple or complex) consumes its own delimiters and only its own delimiters.  Fixed Size  An element is of fixed size if any of the following hold: reptype="binary" and type is a simple type other than string or hexBinary. lengthKind="fixed" and the above table contains a length formula which is uniform (i.e., does not differ in the maximum and minimum columns) the type is a sequence and all the contained elements are of fixed size if delimiters are specified, the character encoding is fixed width. dynamic delimiters come from fixed width elements the element is an array, occursKind='fixed', and the contained items are of fixed size if delimiters are specified, the character encoding is fixed width. dynamic delimiters come from fixed width elements the element is a choice and all the alternatives inside the choice are fixed size. When an element is fixed size, we are able to compute the length of the dynamic extent of the element from information found only in the DFDL schema. Parsing an Optional Element of a Group If an initiator is not found, or an enclosing delimiter is found, then the element is not present. In this case we either produce a value (based on default value, or if nullable, when nullWhenMissing property is present), or we return from the parse with no value. (That is, we return a distinguished special value indicating no value for the element. If the element is not present, then the pos does not advance. Parsing Groups and Arrays Using the Length Protocol The difference between the bounded-length case and the recursive parsing case is important for groups since the last element of a group can be delimited by end-of-data when there is a bounded length. When parsing must occur recursively then there is no understood end-of-data hence, the final delimiting must be explicit. (The exception here is when the entire input source is finite. In this situation there is an ultimate end-of-data at the final end of the source. ) Regular Expression Length and End-of-Data Delimiter When the length method of an element is regularExpression, then a scan is performed to find the match of the regular expression. The usual longest-possible match rule applies. Once this matching data has been determined, then the dynamic extent corresponding to the match is made into a sub-source containing exactly those bits, and then the parsing of the element is done with respect to this sub-source. This enables the contents of such an element to contain delimited arrays or groups which have optional terminators. That is, they are terminated by end-of-data. End-of-Data Termination When there is no terminator, or it is optional, then delimited data can also be terminated by end-of-data. If parsing finishes and there is data left-over before end-of-data on the source, it is not an error. This excess wasted data is generally due to alignment (binary) or padding (text) considerations. This excess data is ignored when parsing. Note that when unparsing, the contents of any excess representation bits must be specified by the fillByte and/or padCharacter properties. Scanability For regular expression length methods, the DFDL schema must describe data which exhibits a property known as scanability. In this situation, if an element has complex type, then all sub-elements contained in the dynamic extent of that complex type must be properly specified so that the regular expression scanning of their enclosing elements will parse properly. Scanability places a restriction on all contained structures inside the contiguous representation or dynamic extent of an element of complex type. Specifically: encoding doesn't vary - this includes not only the encoding property itself, but also the other properties which modify the encoding (byteOrder for UTF-16 and UTF-32, textDBCSOnly, textCharacterSize) When representation properties for an element declaration specify a regular expression length method, the DFDL processor must check for the scanability property restrictions in the entire dynamic scope of the element's declaration. It is a schema-definition error if the scanability property doesn't hold. Note: In attribute grammar terms, Scanability is a synthetic attribute. Nests of Specified Length within Delimited Constructs When something has specified length (fixed, or calculated/stored length), we need to count as we parse and in the case where there are also delimiters specified we must also search for the delimiters. The count and the position of the delimiters must be consistent or it is a processing error. When an element has only a specified length and there are no delimiters specified, but the element is enclosed within delimited constructs, then delimiter scanning is suspended for the duration of the processing of the specified-length element. This allows formats to be parsed which are not scanable. However, this also implies that formats which require scanability cannot nest elements with specified length (and no delimiters). This is a limitation on DFDL schema composition. Elements having formats incompatible with scanability cannot be nested inside constructs where scanability is required. Scanability is required unless the entire dynamic extent of an element can be determined without reference to any delimiter of the enclosing group or array. It is a schema definition error otherwise. Scanability is required for the entire dynamic extent of any construct where the length is determined by a regular expression match. A choice is considered scannablescanable when all the alternatives/branches are scanable. An unordered sequence group is scanable when all the elements within in are scannablescanable. An 'any' element wildcard with processContents="strict" is scanable when all global element declarations in the full schema are scanable. Groups and Arrays: Delimited Length and Terminators There are two properties associated with terminators: terminator finalTerminatorCanBeMissing - Boolean When an element has a terminator specified, then the terminator defines a pattern that must be found to delimit the length of the element's representation. On output, the terminator defines a pattern which is written out after the element's value's representation data. When the finalTerminatorCanBeMissing property is true, then when an element is the last element in a group or array, then on input, it is not a parse error if the final terminator is not found but end-of-data or an enclosing delimiter is encountered instead. For example, if the data is in a file, and the format specifies lines terminated by the newline character (typically LF or CRLF), then if the last line is missing its newline, then this would normally be an error, but if finalTerminatorCanBeMissing is true, then this is not a parse error. On output the final terminator is always written out. When an element is optional, then if the element is missing from the data then the terminator will also be missing. Arrays with lengthUnits="items" If an element is an array, and the length is specified in 'items' as the units and the items are themselves fixed size then parsing similarly works by creating a sub-source and parsing based on it. Thereby the array is allowed to be terminated by end-of-data also. The number of items in the array can be determined by dividing the fixed length of the items by the available specified length. TBD: Misc Default Value, Null Values, and Optional Data TBD: This section needs to turn into parse strategies and conversions and length strategies and also probably into more clarifying examples. The aim of this section is discussion of how default and null values are modelled by DFDL. Definitions There are several words used in describing Null and Default Handling that have specific meanings in this context. The following table clarifies the meanings attached to some words. Table  SEQ Table \* ARABIC 2 Defintions of words used in this document WordMeaningAbsentOn input this means an element that is not present in any form within the input stream. That is no initiator, value or terminator. However there may be some delimiters that indicate that the element is not present. For instance 2 consecutive separators may indicate that an element for which no initiator is defined is not present. On output an element that is not passed to the un-parser to be written out. How the parser represents an absent element in the output stream is dependent on the properties described in this document. MissingOn input a missing element is the same as an absent element for elements that have no initiator defined. However for an element with an initiator defined an empty or absent element may be handled as missing by the parser dependent on properties described in the document. On output a missing element is one that is absent. That is an element that is not passed to un-parser to be written out. EmptyOn input an element whose initiator is present in the input stream but whose value is not present. On output an element that is passed to the un-parser with an empty value. For instance an empty string (note that this different from a null value see below). NullOn input a special logical value given to an element to explicitly indicate that its value is null. The null value is not in the value space of the element, but is an extra distinguished value. How this is indicated within the input stream is dependent on the properties described in this document. On output an element that is null. How the parser represents a null element in the output stream is dependent on the properties described in this document. On input a guiding principal of default handling is that it should not make an invalid document valid. This is similar to the XML Schema attribute rule that a default value is not allowed if the attribute is required. Thus only optional elements will be defaulted on input because defaulting a mandatory element will make an invalid document valid. This also means that if there are less than minOccurs occurrences no additional values will be defaulted. The only exception is the case of tagged elements that have an initiator in the data but no value (See  REF _Ref118187625 \h Default Values on input without null values being considered). On output only missing mandatory elements will be defaulted unless the occursKind property indicates that a specific number of occurrences must appear in the output (See  REF _Ref118187867 \h Default Values on output without null values being considered). Examples Most of the examples used in the document are based on the following logical model. The following 3 DFDL schemas model tagged, delimited and fixed length representations of the above logical model Tagged Delimited Fixed Length Example input streams for each of the DFDL Schemas is tagged A:aaa,B:bbb,C:ccc delimited aaa,bbb,ccc fixed aaabbbccc The representations produced from an input document and the representations used to produce an output document are shown as a tree for convenience. However the actual representation produced by a parser is outside the scope of the specification. The tree produced from the above input streams is:  SHAPE \* MERGEFORMAT  Defaults values on input and output Doing the inverse of input on output is not normally what a user would intend when specifying default values on output. Instead there will be given a property defaultWhenMissing with 4 possible enumerations that will control defaulting on input and output: never Do not default values on input or output. always - Use the default Value on input for missing elements and if an element is missing on output when it is serialised create the element in the output document with the value set to the default value. onInput - Use the default Value on input for missing elements but do not default values on output. onOutput Do not default values on input but if an element is missing on output when it is serialised create the element in the output document with the value set to the default value. For example if element B has a default value of zzz and has the defaultWhenMissing property set to always for selector delimited. On parse the input stream: aaa,,ccc will produce tree  SHAPE \* MERGEFORMAT  On serialisation the tree:  SHAPE \* MERGEFORMAT  will produce output stream aaa,zzz,ccc Default Values on input without null values being considered An element in DFDL falls into one of 4 categories as far as delimiting is concerned: Those that have an initiator and the data is not fixed length Those that have an initiator and the data is fixed length Those that have no initiator and are delimited by a separator Those with no initiator or separator and the element has a fixed length In category (a) it is possible to have an initiator with no value. When only an initiator is present in the input stream and the XML Schema element method of defaulting values is followed the default value would be substituted for the element. If the initiator was also not present no default value would be used in this scenario if following the XML Schema element method. However the default value would be used if following the XML Schema attribute method and the element or attribute was optional. I think both options should be open to the user to be flexible. Thus I think a property on tagged delimited position with 3 enumerations would be required: absent - Use default value if initiator and value missing and the element is optional empty - Use default value if initiator present but no value absentOrEmpty - Both of the above This is the initiatedElementMissingWhen property in table 4. For example if element B has the initiatedElementMissingWhen property set to empty and default value zzz for selector tagged. On parsing the input stream: A:aaa,B:,C:ccc would produce tree:  SHAPE \* MERGEFORMAT  However if element B has the initiatedElementMissingWhen property is set to absent and default value zzz for selector tagged. On parsing the input stream: A:aaa,C:ccc would produce tree:  SHAPE \* MERGEFORMAT  For enumeration 2 where maxOccurs is greater than 1 it is less clear as to how many elements should be defaulted. If there are less than minOccurs elements defaulting any additional elements would violate the not making an invalid document valid rule. If there are minOccurs or greater elements how many additional elements should be defaulted? This is dependent on the occursKind property. If the occursKind property is set to fixed and maxOccurs is not unbounded up to maxOccurs values will be defaulted. If maxOccurs is unbounded no extra values will be defaulted. If the occursKind property is set to xpath the value of the xpath expression will determine how many additional elements will be defaulted. If the occursKind property is set to stopValue or markup no additional values will be defaulted because there is nothing in the data to indicate that there should be any additional repeats defaulted and the user has explicitly chosen not to use the maxOccurs to determine the number of repeats. Another solution is to only default a value for each additional separator specified. This will only work where there is a separator between each repeat not when the data is fixed length and there is no separator. For example suppose that an element A is modified for selector tagged such that it has minOccurs 3 and maxOccurs unbounded. The repeating separator between each repeating element is # and has default value zzz. The updated DFDL Schema for element A would be: The following cases show how many values would be defaulted: A:aaa,B:bbb,C:ccc No values will be defaulted because there are no additional separators. A:aaa#,B:bbb,C:ccc 1 value will be defaulted because there is 1 additional separator. A:aaa##,B:bbb,C:ccc 2 values will be defaulted because there are 2 additional separators. The third case would produce tree:  SHAPE \* MERGEFORMAT  For category (b) if there is no initiator present then it is known that the element is not present. The issues discussed in category (a) with regards to minOccurs and maxOccurs also apply in this scenario. If an initiator is present it must also be assumed that the value is also present in the input stream. In category (c) the only option is to substitute a default value if the element is missing as there is no initiator. The same issues discussed in category (a) with regards to minOccurs and maxOccurs also apply in this scenario. In category (d) it is not possible to determine whether an element is missing so it is not possible to substitute a default value. The only exception to this is if occursKind has been set to fixed or xpath and the end of the bitstream or identifiable point has been reached. Null Handling on input without default values being considered If an element is allowed to be null there are 4 possible methods of encoding a null value on input (These properties will also be used on output). If the nullIndicatorPath property is set and the nullKind is set to logicalValue these encoding methods will be applied to the calculated value (See REF _Ref157416759 \r \h 0). For a value that is handled as null in the input data a value is provided (whatever the representation) that explicitly indicates that its value is null. This will be a special value not in the normal range of allowed values for the element. Until a decision is made on complex elements these properties only apply to simple elements or complex elements with simple content. When missing is specified the same issues with minOccurs and maxOccurs discussed for default values also apply here. For example if element B has nullKind set to literalValue and a single nullValues value of xxx for selector delimited. On parsing the input stream: aaa,xxx,ccc will produce tree  SHAPE \* MERGEFORMAT  and serialisation of the above the tree will produce the same output stream. For elements that have an initiator an element may be indicated as being null in the input stream by the initiator followed by the null value or by the null value alone. The property initiatedElementNull will indicate to the parser how to determine whether an element is null. The property takes the following enumerations: whenInitiatorAbsent - Just the null value is present, no initiator or terminator (if defined) is present. whenInitiatorPresent - The initiator, null value and terminator (if defined) are present. (This is the normal case) whenInitiatorAbsentOrPresent - Both of the above The whenInitiatorAbsent enumeration is only valid when the content model of the model group in which the element is contained is ordered. That is because the model order is required to match the value with an element in the model when there is no initiator. The initiatedElementNull property is also not applicable when the nullIndicatorPath property has been set and when nullKind has been set to missing. For example if element B has nullKind set to literalValue, a single nullValues value of xxx and initiatedElementNull set to whenInitiatorPresent for selector tagged. On parsing the input stream: A:aaa,B:xxx,C:ccc will produce tree  SHAPE \* MERGEFORMAT  and serialisation of the above the tree will produce the same output stream. For example if element B has nullKind set to literalValue, a single nullValues value of xxx and initiatedElementNull set to whenInitiatorAbsent for selector tagged. On parsing the input stream: A:aaa,xxx,C:ccc will produce tree  SHAPE \* MERGEFORMAT  and serialisation of the above the tree will produce the same output stream.  Using both Default Values and Null Handling on input As null processing can be considered as operating at the physical level and default values at the logical level it would make sense for the Null handling to take precedence over the default value handling. Therefore there is no conflict between using Default Values and Null Handling. In particular if the nullKind property is set to missing and there is a default for an element it will be handled as a null value if it is not present in the input stream. Another consequence of this order of precedence is that a defaulted value will never be considered as a null value because the default handling is preformed after the null handling. Default Values on output without null values being considered As discussed in the section comparing default values for input and output the way that default values would be used on output is to populate an output document with the elements that are missing on output. Thus allowing a user to populate a sparse representation rather than a complete representation of what is to be output. On output default values will be populated for all 3 categories of delimiting; it is OK to output default vales for fixed length. For repeating elements the number of values to be defaulted is also dependent on the occursKind property. If occursKind is set to fixed up to maxOccurs values will be defaulted. If occursKind is set to xpath the number of values defaulted will be determined by the xpath expression. For an occursKind of stopValue and markup up to minOccurs values will be defaulted. Thus if an element is optional it will not be defaulted.  A special case is where a user wants to populate elements with a null literal character on output. This is to cope with the COBOL case where a user may wish to populate the elements with LOW-VALUES or HIGH-VALUES. This is the output case of the literalCharacter nullKind case described for input. However on output I consider this more a default value case rather than a null value case, although we may be generating out-of-bound data for the element in the output document. For a null value case there would be an element in the representation with a value set to null rather than a missing element. A solution to this is to create a boolean property called useNullValueForDefault which specifies whether the value in the nullValues property is to be used on output if an element is missing on output. It will be invalid to set the useNullValueForDefault property to true if the nullKind property has not been set or the element is not nillable. If the element has an initiator defined the initiatedElementMissingWhen or initiatedElementNull properties will be used to control what is output in the output stream dependent on the whether nullKind is set to missing or not. Null Handling on output without default values being considered If the value of an element in the representation is set to null the value on output will be determined by the nullKind property. However if the value is null and the nullIndicatorPath property is set no value will be written on output because the calculation indicates whether it is null or not.  For initiated elements with nullKind set to missing the initiatedElementMIssingWhen property controls what is output: absent Output no value or initiator empty Output the initiator but no value absentOrEmpty Output the initiator but no value For initiated elements with nullKind not set to missing the initiatedElementNull property controls what is output: whenInitiatorAbsent - Just output the null value itself with no initiator or terminator (if defined). whenInitiatorPresent - Output the initiator, null value and terminator (if defined). (This is the normal case) whenInitiatorAbsentOrPresent - Output the initiator, null value and terminator (if defined). The whenInitiatorAbsent enumeration is only valid when the content model of the model group in which the element is contained is ordered. That is because if the output stream is to be re-parsed the model order is required to match the value with an element in the model when there is no initiator. The initiatedElementNull property is also not applicable when the nullIndicatorPath property has been set and when nullKind has been set to missing. Flowcharts for Null and Default Behaviour Output Flowcharts  SHAPE \* MERGEFORMAT   SHAPE \* MERGEFORMAT   SHAPE \* MERGEFORMAT  Parse Strategies for Elements, Arrays, Optionals, and Groups An individual parse strategy is for a specific kind of construct. that is, element declaration, sequence group, array, or choice. Parse strategies naturally group into families of related parse strategies that use related representation properties and are mutually consistent in their interpretation. We will often refer to a family of related parse strategies collectively as a parse strategy as well as referring to a specific individual parse strategy for a specific construct by the same term. Sequence Group Parse Strategies TBD Grammar of DFDL-described data Data that is described by a DFDL schema has a representation which can be described by this grammar. Any element, E, has this grammar: ...TBD... All the parse strategies share this interpretation of several properties with respect to the above grammar: offset, offsetUnits, and offsetFrom these control the base element used to determine the starting position of this element, and the offset (in offsetUnits) from it. The resulting position is the unaligned starting position of the element. alignment and alignmentUnits These control the AP field. The width of the AP is given by the alignment and alignmentUnits properties along with the current unaligned starting position. On unparse, the AP is filled with data from the value of the fillByte property. leadingSkipBytes, trailingSkipBytes These control the LSB and TSB fields. initiator Controls INIT field. The initiator property specifies constant data which must be found/matched in the INIT field, or when initiatorSeparator is specified, initiator is ignored and INIT holds the non-constant data which is found before the INITSEP is found. Size of the INIT field is zero unless repType='text'. (which implies encoding must be specified also.) It is a Schema Definition Error if both initiator and initiatorSeparator are specified locally on the same construct of the DFDL schema. initiatorSeparator Controls INITSEP field. It is a schema definition error if both initiator and initiatorSeparator are specified locally on the same construct of the DFDL schema. Specifies constant data which must be found between a non-fixed initiator and the value representation. Requires repType='text' (which implies encoding must be specified also.) When both initiatorSeparator and initiator are specified, one of the two must be specified in an enclosing scope. In this situation, initiator is used; and initiatorSeparator is ignored. terminator, finalTerminatorCanBeMissing Controls TERM which specifies constant data which must be found after the value representation. Requires repType='text' (which implies encoding must be specified also.). When the element is the last element of a sequence group or last item of an array, then when finalTerminatorCanBeMissing is present then TERM can be size zero. Position by Offset The properties offset and offsetFrom are used to specify a different element than the previous element from which the element start position is determined. It is a schema definition error if the DFDL schema does not specify non-overlapping locations for the elements of the schema. (This implies fixed or fixed-maximum-size elements.) When dfdl:offset and dfdl:offsetFrom properties are used, the dfdl:offsetFrom property names another element in the schema which we'll call the base element. The element start position of the element having the offset is the element end position of the base element plus the offset. The units by which the offset is measured are given by dfdl:lengthUnits. Misc Grammar Bits An Element Value, EV, has the following grammar for its syntax: EV = SIMPLEORNULLV | GV | ARV | NULLPATTERN | MISSINGPATTERN SIMPLEORNULLV = SV | NULLV  Sequence Group Value, GV, where [] means optional and '*' means zero or more repetitions. GV = GINIT [SEPB F [SEPI [[M SEPI]* L]] SEPA] GTERM F = E First Group child M = E: Middle Group Child L = E: Last Group Child GINIT = BSTR: Group Initiator given by initiator property GTERM = BSTR: Group Terminator - given by terminator representation property and whether GTERM is required or optional is controlled by terminatorCanBeMissing property SEPB = BSTR: Separator Before - if separatorKind='prefix' then the value of the separator property, otherwise zero length. SEPI = BSTR: Separator Inside - the value of the separator property SEPA = BSTR: Separator After - if separatorKind='postfix' then the value of the separator property, otherwise zero length. Array Value ARV = [E [OSI E]] STOPV OSEPI = BSTR: Occurs Separator Inside - value of the occursSeparator property STOPV = BITS: Stop Value value to be found to indicate termination of the array. In any given data, depending on the representation, many of the above grammar terminals will be of size zero. For example, in binary data where lengths are either fixed or for variable-length items lengths are stored in the data, then one would expect that INIT, TERM, SEPI, SEPB, SEPA, GINIT, GTERM, OSEPI in the above productions would all be size zero. I.e., they do not contain any bits. However, since binary data often makes use of alignment and also sometimes skips unused bytes, one would expect that AP, LSB, and TSB might be non-zero in size. In contrast to this, for a delimited text data format, one would normally expect AP, LSB, and TSB to be of size zero. (Note: for multi-byte character encodings AP might not be empty in all cases.) Base Parse Strategy binary sequence group This strategy is for sequences of binary data. Type category = G. Guard: repType==binary, lengthKind==fixed, schemaFacet, xpath, or prefixed Sub-Rules: PRE: The PRE sub-rule is responsible for AP LSB GI and SB. GI, SB are zero size. The initiator property and separator property are ignored if present. (TBD: Some DFDL implementations may want to issue warning diagnostics whenever lengthKind is not 'delimited', but the delimiter properties like initiator, terminator, separator are defined.) AP is computed from the alignment and alignmentUnits properties in the ctxt and the pos. The mem parameter is used if expressions are evaluated since alignment property can be an Xpath that can refer to variables. If alignment or alignmentUnits are undefined it is a schema definition error. Any error in evaluation of an expression causes a parse error. LSB is computed from the leadingSkipBytes property in the ctxt. Zero size if property is undefined. The return pos1 is length of AP plus length of LSB plus the original pos. The return mem1 = mem. SEP: The SI is zero size. The return mem1 = mem The return pos1 = pos POST: The post-processing is responsible for SA, GT, and TSB SA, GT are zero size. (see note on PRE about warnings). TSB is computed from the trailingSkipBytes property in the ctxt. Zero size if trailingSkipBytes is undefined. The return pos1 is length of TSB plus the original pos. The return mem1 = mem. F: recursively calls the logical parser P on same arguments. Returns its results. M: recursively calls the logical parser P on same arguments. Returns its results. L: recursively calls the logical parser P on same arguments. Returns its results. Base Parse Strategy delimited text ordered-sequence group (G) This strategy is for ordered sequences of text data that is delimited. Type category = G. Guard: repType==text, lengthKind==delimited' Sub-Rules: PRE: The PRE sub-rule is responsible for AP LSB GI and SB. LSB is zero size. The leadingSkipBytes property is ignored if present. GI: If initiator is not defined then GI is zero size. If the initiator property is defined, its value is converted to bits by use of the encoding property. If the encoding property is not defined it is a schema definition error. If any expression evaluation error occurs it is a parse error. SB: if separatorKind is defined and equal to 'prefix', then SB's value is the value of the separator property converted to bits by use of the encoding property. Same error checking. AP is computed depending on a number of properties (See Section (TBD: xref to Character Width). AP can be of length up to 31 bits. When the character set encoding is fixed width, and the alignment property (and alignmentUnits property) specify 1 byte, 2 byte, or 4 byte alignment then AP can be non-zero size depending on the incoming pos. If the character set encoding is variable width then AP is of length up to 7 bits, as variable width characters can only be 1-byte aligned. The source stream is inspected for a GI match beginning at pos + AP. If the match is not found it is a parse error. The source stream is inspected for a SB match beginning at pos + AP + length(GI). If the match is not found it is a parse error. The return pos1 is length of AP plus the length of GI plus the length of SB. The return mem1 = mem. SEP: The SI value is the value of the separator property converted to bits by use of the encoding property. The source stream is inspected for a SI match beginning at pos. If the match is not found it is a parse error. The return mem1 = mem The return pos1 = pos POST: The post-processing is responsible for SA, GT, and TSB GT: If terminator is not defined then GT is zero size. If the terminator property is defined, its value is converted to bits by use of the encoding property. If the encoding property is not defined it is a schema definition error. If any expression evaluation error occurs it is a parse error. SA: : if separatorKind is defined and equal to 'postfix', then SA's value is the value of the separator property converted to bits by use of the encoding property. Same error checking. TSB is zero size. The trailingSkipBytes property is ignored. The source stream is inspected for a SA match beginning at pos. If the match is not found it is a parse error. The source stream is inspected for a GT match beginning at pos + length(SA). If the match is not found it is a parse error. The return pos1 is length of GT plus the length of SA. The return mem1 = mem. F: Processes the first child element of the sequence group. TBD: parse while scanning for delimiters. This sequence group contributes the SI separator to the list of delimiters which might be found to end the contained element. If we find the SI separator, we do not consume it. (That happens in the SEP sub-rule). If we delimit the end of the element using its own terminator, then we do consume that terminator. We could also determine the end of the element using another length scheme (stored length, or fixed length or regexp). However, note that scannabilityscanability must hold. Also note that our scanning for delimiters must take the escape schemes into account. Note that if we encounter, say, an unescaped separator, not of this group, but of an enclosing group or array, then it is a parse error. M: TBD L: TBD Array Parse Strategies TBD Length Methods for Arrays/Vectors The length of an array/vector can be determined by several methods. specified: This category includes fixed, stored, and computed length - the length is specified using the logical value of other data in the representation, or is found directly in the Schema as an integer. delimited - the length is determined by scanning the representation) for a non-data pattern. regexp - The length is determined by scanning the data and using all data that matches a pattern.  value delimited - the length is determined by examining the logical data for a logical value pattern that indicates the end of the logical data. In specified-length methods, we are able to determine an integer value which gives the number of units in the length of the array. The property lengthUnits tells us whether the integer gives the number of bits, bytes, characters, or elements. Note that the length of an array can be given in bits, bytes, or characters, in which case the number of elements must be determined by calculating the number of elements that fit in that much representation data. In delimited methods we must look at the data for indications of the end of the array. A simple semi-colon character terminating the array is an example. In value-delimited methods, we must first parse data from representation to logical value, and then examine the logical value for the appropriate markers. A negative number value to mark the end of an array of numbers is an example. In regexp we consume data matching a regular expression to determine the length. The usual longest-possible match rule applies. The length of an array optionally uses these additional properties: occursSeparator If an element describes an array, that is, it has multiple occurances, then there is no notion of the array itself independent of its contained elements. Hence, it cannot have its own initiator, terminator, or alignment. Properties Affecting Length of Simple Types Several DFDL representation properties are used to determine the length of an element of simple type: repType lengthKind length lengthUnits encoding textCharacterSize storedLengthIncludesPrefix lengthOfPrefix initiator (and TBD: initiator tag separator) terminator Depending on the values of these properties, one of a number of means of determining the length of an element's representation can be determined. Length Methods for Scalar Simple Types There are several fundamentally different methods by which the length of an element of simple type is determined: specified: This category includes fixed, stored, and computed length - the length is specified using the logical value of other data in the representation, or is found directly in the Schema as an integer. delimited - the length is determined by scanning the representation) for a non-data pattern. regexp - The length is determined by scanning the data and using all data that matches a pattern. In specified-length methods, we are able to determine an integer value which gives the number of units in the length of the element. The property lengthUnits tells us whether the integer gives the number of bits, bytes, or characters (note that lengthUnits='elements' is for arrays only). In delimited methods we must look at the data for indications of the end of the element. A simple comma separating the elements of a sequence is an example of a delimiter for a simple type element that is within that sequence. In regexp we consume data matching a regular expression to determine the length. The usual longest-possible match rule applies.  The concept of native-endian is avoided in DFDL since a DFDL schema containing such a property binding does not contain a complete description of data, but rather an incomplete one which is parameterized by characteristics of the machine and implementation where the DFDL processor is executed. In DFDL this same behavior is achieved through use of true parameterization, for example by use of Selectors to choose among two different format annotations.  CCSID stands for Coded Character Set ID, a 3 digit representation for a codepage specifier. TBD: cite relevant standard for CCSIDs here.  The concept of native character encoding is avoided in DFDL since a DFDL schema containing such a property binding does not contain a complete description of data, but rather an incomplete one which is parameterized by characteristics of the operating environment where the DFDL processor executes. In DFDL this same behavior is achieved through use of true parameterization, for example by use of Selectors to choose among annotations specifying different character set encoding property bindings.  Codepoint for UTF-16     GWD-I Category: Informational OGF Data Format Description Language Working Group  SAVEDATE \@ "yyyy-MM-dd" \* MERGEFORMAT 2007-05-03 dfdl-wg@ogf.org Page  PAGE 12 of  NUMPAGES 127127 GWD-I dfdl-wg@ogf.org Category: INFORMATIONAL OGF Data Format Description Language Working Group  SAVEDATE \@ "yyyy-MM-dd" \* MERGEFORMAT 2007-05-03 File:  FILENAME draft_20070503.doc Page  PAGE 1 of  NUMPAGES 127127 GWD-I File:  FILENAME draft_20070503.doc Page  PAGE 127 of  NUMPAGES 127127 TBD: can these be suppressed? The point of discriminators is to resolve ambiguity rather than leave it up to whether something causes error or not. This argues that an error during evaluation of a discriminator is never suppressed. However, if the entire discriminator is inside a context where uncertainty is being resolved by error, then .... maybe weve speculated down a path where all the assumptions, including those which allow the discriminator to evaluate without error arent valid. Required by speculative parsing in the choice case, and possibly optionals and variable length arrays. Could leave this out. Alphabetize. Consider removing terms we don't use. (Though we may still need them in sections still to be written.) What attributes should we show here: maxOccurs/minOccurs ? stringLength, stringMinLength, stringMaxLength ? totalDigits, fractionDigits? also nullable -> nillable dimensionality -> maxOccurs minOccurs TBD: integer and the other integer types are just range restrictions that can be done using ordinary facets and simple type derivation, so why not have them. On the other hand, we can leave these out because they add nothing from the format-description perspective, and in fact generate some complexity due to these logical types having or not sign when representations also can have or not have sign. We need to list exactly the facets that are supported/used, and in the section below, exactly the facets that are ignored. This used to say only processContents="strict", but I took this out because there are several interesting and useful semantics here. E.g., xs:any wildcards inside unordered groups are intended to support finding elements that have no corresponding element declaration but where an initiator is separated by the initiatorSeparator delimiter. TBD: Can we add recursive type definitions to the list of not in DFDL v1.0? It would really simplify things a lot. This URL must change. We no longer own dataformat.org, dfdl.com is available, but owned by someone who wants to sell it for $$$$. I suggest we use a subdomain inside the ogf namespace, i.e., dfdl.ogf.org. or  HYPERLINK "http://www.ogf.org/dfdl/" www.ogf.org/dfdl/ It would be great to have an dfdl-xml-schema-subset.xsd as well which we could create by taking the schema for xml schema, and subsetting it. This would let people get validation errors on their schemas if they haven't restricted them to the dfdl subset of xml schema. TBD: in DFDL v1.0 shall we decree that define property is reserved but it is used in this specification to clarify the semantics of the various built-in properties? What is the difference between scheme and format? We should be careful of consistency in element naming. Presumably there is a sequential ordering and declarations must come before assignments. What about hierarchical scope? PAGE \# "'Page: '#' '" repType is ugly. I prefer representation Supposedly there is a technical issue with establishing namespaces in annotations which needs to be addressed. I dont understand this issue. Seems ok to me. I just preserved this comment from a previous draft of this doc. We need a syntax for these that lets you put the test expression inside the element content, so you can use CDATA and avoid quoting hell. I suggest the error message becomes an attribute and the element value becomes the test expression, perhaps alternately with the attribute syntax. PAGE \# "'Page: '#' '" Distinguish assertion types by name, not by attributes. I suggest dfdl:assert-before, dfdl:assert-after, dfdl:discriminator. PAGE \# "'Page: '#' '" Make error message an attribute, and reserve element content for the test. Retain optional attribute test as an alternative for simple cases. PAGE \# "'Page: '#' '" Generalise this so that any XSD construct that may be annotated may be marked hidden. This feature is important: it helps to make the language composable. Important detail. Readers please consider this. This was added to support the notion of bootstrapping DFDL from a kernel-DFDL that contains very few properties. PAGE \# "'Page: '#' '" Yes, I believe so. With multivalued expressions we can describe arrays more easily. Consider slide 72 in Steves presentation to OGF20. PAGE \# "'Page: '#' '" I dont understand the need for this restriction. Elsewhere we allow more freedom. Strong typing says we can determine this statically to be a schema validation error. PAGE \# "'Page: '#' '" XPath2 already defines effective boolean value. I suggest we refer to that definition, or simply omit this paragraph. PAGE \# "'Page: '#' '" The most easily defended answer is as late as possible. The only alternative that makes sense is once, on first use, but thats probably too restrictive. Note: this eliminates the need for a special regularExpression capability in choice discrimination. You can just use this in a discriminating assertion. PAGE \# "'Page: '#' '" As a free-standing function there is no context, so another argument is needed. DFDL should provide XPath external functions that help with integration, but this one might be beyond our brief. Regex syntax is unspecified: presumably well pick XSD syntax. PAGE \# "'Page: '#' '" This sounds dangerous and difficult. Limit it to element content identified by location path? PAGE \# "'Page: '#' '" Yes, please. Ideally, specify that every value is an expression and dispense with the braces altogether. PAGE \# "'Page: '#' '" I find this cumbersome. I suggest this alternative: drop applies and dfdl:format, insist on dfdl:sequence and friends instead, and add local variants like dfdl:sequenceLocal. For attribute shorthand, add boolean attributes with the same name: sequenceLocal=true (optional, default false). Is this correct? I think so because the "scope" covers what could be a type derivation, but unclear really. A little elaboration on this would be good. TBD: reindent and apply color scheme. Syntax: these should be surrounded by ... PAGE \# "'Page: '#' '" http://en.wikipedia.org/wiki/Recursive_descent_parser definition needed in glossary. Darn it, why don't these update properly? This is supposed to be to the scoping section. Looks like we need to TBD all xrefs instead of actually putting them in since MS Word doesn't do the right thing as sections are inserted, reordered, etc. Change pos1 to pos_out, pos to pos_in Also change order of inputs and outputs to be consistent. TBD: I think we need an isNull return value also, or we need to clarify that when a value is null we can positively recognize that independent of any real value. PAGE \# "'Page: '#' '" This discussion might be better expressed in positive terms. Since everything is tentative initially, simply refer to the result and record the moment when the result is confirmed (on successful completion of a parse operation?). The term result applies to the local outcome of any parsing operation. To refer to the result of the top level parse operation, use the term root. Qualify result or root with unconfirmed only when necessary. (This also works with the term commit.) Was all this needed because of unordered groups? If so then it can go away now. Some of these should be schema definition errors. When we can show that the path reaches into a peer within a choice, for example, we can detect this statically so it should be a schema definition error. This root value approximation device only lets us detect processing time errors. Move to a separate section, probably associated with the expression language. This root-value approximation is needed to support expression evaluation, so that's the logical place for this to go. Sounds implementation oriented. Alternative name used in many semantics is "the store" as in storage.  Issue was raised: Why is it necessary to return memory as an output value and pass the memory separately from the context? Put another way, can we treat variables the same as other properties? Answer is that the semantics of property bindings and variables are fundamentally different due to the set construct for variables. The technique used here where you have a scoped "environment" or "context", and a separate "store" or memory" is the standard way used in denotatinoal semantics to cope with variable names and scopes independent from locations that store values which can be changed. This section in the wrong place. Should this be the "Representation extent"? Why "dynamic" Note: both Lctxt and Sctxt share the variable definition. Not sure this makes sense for Lctxt i.e., here-only stuff. But perhaps when there are derived simple types it's possible to have some setContexts and reference to the variable spread over parts of the schema? TBD: more precise xref to where it talks about the difference between applies=ToScope and applies=hereOnly. Should we cover this in syntax section? TBD: more precise xref to where it talks about the difference between applies=ToScope and applies=hereOnly. Should we cover this in the syntax section? Is this correct or should it be Sctxt, or should the assert carry its own hereOnly or toScope attribute? Is this correct or should it be Sctxt, or should the assert carry its own hereOnly or toScope attribute? Note that these are evaluated after the parse of something. This means you really are going to want to set them in one child of a group and use them in a later item of that group. You can't set them above and use them further down. Alternatively, like dfdl:assert they need a timing attribute. TBD: revisit. Does this work properly with the way speculation is expressed? Not sure any of the PRE, SEP, or POST rules need to be able to reference variables. It is expressions referencing variables which is why mem would be needed. Can expressions end up being evaluated here? Answer: Yes they can. One property can have an expression involving a variable as its definition. If we evaluate the expression late (late binding, which is sometimes needed to chain properties to eachother or to variables) then it will need to reach into mem here. There is an advanced concept not in v1.0 of DFDL where a simple type can have a complex definition. We used to call this repDef. It would require this Lctxt only behavior to be changed to allow for Sctxt as well. Doesn't work for recursive types. We'll recurse downward forever here. Need to detect the cycle and solve a fixed point. Mechanism TBD. Can't we just rule out recursive types in DFDL v1.0. Note: S. Hanson and others reviewed this and support that recursive types are not needed for v1.0. TBD: revisit. Does this work properly with the way speculation is expressed? Assumes elements, not group content. Need to handle nested group. Currently assumes FIRST, MIDDLE and LAST are elements. TBD: revisit. Does this work properly with the way speculation is expressed? Amazing how all the material on discriminating initiators and the complexities of initiator tagged formats goes away because we decreed unordered sequence groups to be source-to-source transformed away. That combined with the speculative execution for choice and array and optional and you end up without any specialized treadment of initiator-based discrimination. Concern that implementing our own interpretation of unordered as described may be seen by wider community as clashing with xsd:all (which has been relaxed in XSD 1.1), does not allow a user to preserve his bitstream order (which although random could still have a semantic), and does not allow us to output exactly what we parsed.  From review comments by steve, geoff, alan: Doesn't this array need to be inside an ordered sequence? i.e., To be capable of use on a complex type's sequence or on an embedded sequence, your source to source transform actually replaces an unordered sequence with an ordered sequence, which contains an array element of local complex type, whose content is a choice... General point: Output matching model order. Needs discussion. If we consider schema validation as separate from DFDL parse/unparse, then shouldn't the DFDL unparser output what it is presented with? TBD: not sure about this. For optionals do we allow resolution based on failures? This is perhaps unlike choice resolution by error/type. Question: Why is it necessary to pull EXISTS into the array parser? You don't do the same for the sequence parser. Answer: Sequences don't involve uncertainty points. Arrays do because of variable length. Question: . Is a NONE function also needed for sequence? If not can you say why. ????? Reminder: didn't say how path gets lengthened, or how the first unknown place holder for the element value is created. This goes back in the element decl processing rule. For output symmetry, consider "format strategy" as the general term, possibly consisting of a combined parse and unparse strategy.  special case just for optionals to simplify the parse strategies. TBD ? Lctxt2 ? Could also be a group, i.e., an embedded sequence or choice without an element tier. If we allow groups inside groups then this won't hold anymore. TBD: Lctxt2 ?  Note: IBM product parsers currently do support PRE/POST for choice groups, so to subsume that functionality we need to have PRE/POST here. This language about declarations must change if groups can contain groups, unless we call the inner group's syntax a declaration also. Could make this formal by adding an extra control argument to P indicating whether it is parsing speculatively or not, and a means of returning 3 special values: an error value, discriminator-true or discriminator-false value. These are distinguished from any real value or the null value. The result of every recursive P call would have to be scrutinized for error/discriminator results and if error return error. if discriminator then check the special control argument and if we're speculating, just return the discriminator true/false value. Not sure the above is worth it. We might need this to deal with the distinctions between errors ending speculation and discriminations ending speculation. This statement implies that assertions (non-discriminationg) are needed to parse even when validation is off. Perhaps should rename this property "pathExpression" to be clearer. Discussion here assumes that an any wildcard behaves as if it absorbs any number of elements (0 to unbounded); however, xs:any takes maxOccurs and minOccurs which default to 1, 1. I think we need to decide if we support repeating wildcards. If we don't then the source transform of xsd:any for strict is direct to xsd:choice and for lax is direct to the xsd:sequence (you don't need the dummy complex type. In both cases you don't need the extra element, nor therefore the "id" attribute. TBD: Discrimination mechanism? Do we only include an alternative for global element decls having a discriminating assert? Require some other annotation to indicate participation in any wildcards? TBD: nitpicky detail. What about any escape scheme? Will that be simply inherited from the scope? What if the initiatorSeparator wasn't in the scope, but in the hereOnly (which is likely) meaning the escape scheme might be here-only also?  Missing discussion: TBD: how context is created by combining annotations on a nest of simple type derivations. TBD: how termination works for delimited parsing. I.e, lexical analysis. Not in v1.0 This isn't under the user's control unless we're talking about user extensions giving them the ability to manipulate the conversions list. This feature isn't in V1.0 of DFDL. TBD: even these few properties could be reduced if we provided a way to specify a rewrite as a 'strategy'. Such rewrites would have to be able to transform the DFDL schema source, and then subsequently transform the data the way that the unordered sequence is required to. These transformations on data could be specified by way of say, XSLT or XQuery since those are standards. That's an awfully big hammer though, and ends up requiring an XSLT implementation inside a DFDL implementation if there were any extensibility created using this mechanism. If we reserve the specification of these rewrites and their semantics to the standards definition then it would be ok. TBD: make data model stuff early in the document consistent with this. Note: the Schema for DFDL annotation syntax will use an xs:token for this. All dfdl symbols are reserved. Others would be allowed as a way to allow new parse strategies to be defined and added to DFDL. Name issue: This "BinaryStream" is going to be confused with other use of the term 'stream' which I believe are more important. Suggest "bits" as the name of this concept. As in "The data is either text or bits" Perhaps repType=bytes or repType=nonText ?? Cite a standard for CCSID values in the footnote. We want this to be as small as possible a set. Can we get away with just UTF-8, Also TBD: what aliases of the IANA names are required? All of them? So, e.g., "Latin1" is accepted? TBD: Drop from V1.0 ? Ditto Advanced/Supplement or v2.0 ? expression or calculated again. Not consistent with lengthKind which has just 'prefixed" not "prefix1" and "prefix2". Changed from self to prefix for clarity. TBD: what are the restrictions here. TBD: drop this and 'offset' from V1.0 of DFDL? A predefined format set should define this as left and number justification to right. (What about the others? also left like string?) A pre-defined format set should have this as "right" For these boolean reps, we need to be able to use a list of values. (Similarly, null flags allow lists of values) however there is an issue of how you can put the empty string into a list since the empty string might be one of the reps that is accepted as false for example. We can use a list of quoted strings. E.g., " 'false' 'FALSE' 'False' '0' '' " (the last entry is empty string hard to tell in default font here.) Seems these shouldn't be here. Again the issue of how to provide lists of true values (or false values) for these booleans, and what to do about empty string as one of those values? What doe s this mean? Seems to imply a float-size property so that you know how big it is and can at least skip over it. I would prefer to simply drop this. We have ways of doing opaque types so that you can skip over things like this. Name issue, already raised. Perhaps 'bits' is the representation name? Not right. The hexBinary or base64binary are types that show up in the "logical" model. The representation is bytes/bits, and we just have to say how many there are somehow. If the bytes are actually hidden in a textual encoding like base64, then that's layering, and we would decode them to bytes in order to treat them as the source for say, binary integers. Don't understand this. What does "modeled separately" mean? Why not say can be empty string indicating no decimal separator.Then we can eliminate numberimpliedPlaces? Or was this done for implementation reasons? I.e., to avoid having to tweek the ICU libraries? PAGE \# "'Page: '#' '" formatCheckPolicy=strict or lenient, default lenient TBD: instead of making people count, why not use a marker in the pattern to indicate where the implied decimal point is? Like cobol's 999V99 where the V is the implied decimal point location. Add XREF to section on layering which discusses these properties. PAGE \# "'Page: '#' '" Consider composing delimited structures using XSD constructs. See also comment on Properties for repeating data below. Too much flexibility. Why not control this with the initiator settings? What are the alignment units? Bits or Bytes? I believe it should either only be bits, or we need an alignmentUnits tha t has enum bits/bytes. Note: this behaves just like a hidden element with alignment=1, alignmentUnits=bytes, and this length. Omit? Or allow only for binary rep type? PAGE \# "'Page: '#' '" Consider composing delimited structures using XSD constructs. For length specification, use itemCount, byteCount with argument type positive integer expression. If the number of items is determined by some enclosing structure, whether visible or not, that structure should be modelled. changed to 'delimited' to be consistent with other property usage. Missing occursSeparatorKind= infix or prefix, or postfix. use short-form annotations to make shorter Do we even have to discuss such cases. In this case the document being output is not valid. If the item is mandatory, then earlier parts of creation of the output must create the value. I believe we should not support this behavior in DFDL. GJ Added to provide similar behavior to the DataStage TX Type Syntax->Empty property. This allows an initiated element to have a value specified with no initiator on input that is be treated as indicating that the element is empty. This was initially added to DataStage TX to handle the case where an empty XML element could be specified as whereas the element was modeled with an initiator of and terminator . However users have used the property in non-XML scenarios. GJ Have to choose one or the other. How is list specified such that an empty string can be expressed as a null value for a nullable string field? Example is needed to illustrate usage here. This example is the one where there is a trailing bit vector of null flags. I have seen prior and after byte flags, and prior and after bit vectors. The example has to also show how the null indicator is set on output.. There seems to be some confusion around null indicators and whether or not the element itself will appear in the data. Generally, if the element is fixed size, having a null indicator doesn't change the amount of space taken up in the stream. Rather, both the flag and the element storage would be in the data. If the element Is variable size then things are trickier. Note: in DFDL v1.0 because of the way the root-value approximation works this path must be to an element that has already been parsed in schema order. I.e., you can't have a trailing bit vector of null flags at the end of each data record. Added all this logic. This case where we have variable size with minimum greather than zero is an annoying complexity. Can we consider saying DFDL v1.0 doesn't support minOccurs other than 0 or 1, and minOccurs = 1 only when maxOccurs also = 1 ?? This would eliminate many hard cases, not just here in the null-flags stuff, but in many other parts of the spec. This seems inconsistent with our principle that null is about the value and default value stuff happens after. This introduces asymmetry. I.e., if a document is read and certain values are missing then for this property to be meaningful the item must be nillable. In which case either the null indication is found or not. A default value would be used only if the value is absent/empty that is missing the null indicator. There is a UTF-8 variant where the max is 6 bytes. Unicode characters above 0xFFFF are encoded as two surrogate codepoints, and each surrogate codepoint is encoded as 3 bytes. This is non-standard for UTF-8, but is commonly used. We need an encoding name for this encoding. We could make all UTF-8 readers accept this, and not write it out, but that would break software that needs this 6 byte encoding.  Q: Why is this a special argument. Isn't what is needed in the context? A: this is called out explicitly because of the way that the local terminator is treated differently from all other enclosing terminators/deliminters. If we find our local terminator, we consume it. For anything enclosing, we don't consume it. TBD: means to tolerate/suppress this class of error. TBD: we need to specify how an escape scheme gets associated to a specific d TBD: means to tolerate/suppress this class of error. Q: isn't this a default value being built in? A: not really. We're just defining a byte to be of size 8 bits here if the user doesn't say they want some number of bits other than that. I.e., I can say I want an int populated from a 3 bit field by giving length=3, lengthUnits="bits", but if I just say I want an int populated then it should be 32 bits since that's the definition of the precision of int. In other words, the precisions of int, byte, short, etc. are not "default" values. They'll never change. They're specified by the XML Schema standard.  Additional comments: 18.2. binaryPrefixedString, binaryFixedString: DFDL allows lengthUnits to be 'bytes' for fixed length strings and prefixed strings. 18.2. binaryPrefixedString: LEN calculation omits some of the required properties 18.2. Not clear what the schema fragment is illustrating, nor the following P() function and two return statements. forgot to adjust for BOM if "required". Need mem if these can get their values from variables in the expressions for their values in ctxt. Change pos1 to pos_out, pos to pos_in Also change order of inputs and outputs to be consistent. Change pos1 to pos_out, pos to pos_in Also change order of inputs and outputs to be consistent. TBD: this doesn't belong here. And anyway is it even true? Seems to be true in that a differently aligned following item might appear like a valid optional item, thereby fooling the parse.  Review comment: We are not convinced that using the bootstrapping technique of defining DFDL behaviour in terms of itself always helps. AP is a good example of things appearing to get overly complicated. It might be preferable to use some other code or pseudo-code mechanism to specify these behaviours - like you have in 18.4.3. This is the big bootstrap trick here. We define the syntactic elements of the elements, groups, arrays and such inductively using DFDL itself to define their representational content. were providing access here the parameters of the parse function. Could use a different notation for that. TBD Lctxt? TBD Lctxt? PAGE \# "'Page: '#' '" HexBinary confuses me. Were counting nybbles, not characters, arent we? Perhaps dfdl:encoding is the problem. HexBinary is not a reptype, but an encoding (or rather: a decoding, since the text encodes the binary rather than the other way round.) There are two decodings: hexbinary and base64binary (for completeness, perhaps we should add decoding base2binary?) The reptype is 'binary', never text. dfdl:encoding=utf-8 is misleading. as I say, Im confused! TBD: update for new "OGF". Also the template may change, new IP statement language may have to be used, etc. etc. Need CCSID code pages reference. Everyplace we describe lengthUnitKind in this document and mention characters ideally we should footnote and say "lengthUnitKind='characters' means 16-bit for UTF-16 character set encodings. See the Appendix..." PAGE \# "'Page: '#' '" Property length is intimately associated with lengthUnits, so combine them in one property. The words length and size come with a lot of confusing baggage, so I suggest these names: bitCount, byteCount, characterCount, itemCount. Allow only one of these for each field. For binary only bitCount and byteCount, for arrays only itemCount and for text either byteCount (the encoded representation) or characterCount (the decoded representation). TBD: there's this storedLengthIncludesPrefix and prefixLength which vary this a bit more. This case can easily arise if fixed element width multi-byte character-set data is converted to say, UTF-8 and it actually contains mutli-byte characters. You end up with data that is fixed number of characters in fields, but the byte width of those characters varies. TBD: Does this discussion in this comment below go somewhere also as a clarification: For example, the parse function for a sequence group which has separators specified will recursively parse the elements it contains; however, if one of those elements' representations is terminated by finding the enclosing sequence group's separator, then that separator will not be consumed, and when the recursive parse unwinds back to the parse function of the enclosing sequence group, the separator will then be consumed by the sequence group's parse function which is prepared to recognize it and advance past it. This principle works regardless of how deeply nested the constructs are.  TBD: This section belongs elsewhere. Note: terminatorCanBeMissing is different from finalTerminatorCanBeMissing. One is for an element itself, or array itself. The other is for a group or array and refers to the terminator of the last element of the group or array. finalTerminatorCanBeMissing means all the terminators of all non-final elements are required, but the one for the last element is optional. The terminatorCanBeMissing property refers to an element's own terminator. Applying this across a scope would make all terminators even for non-final elements optional, which is almost never what you want. finalTerminatorCanBeMissing is, on the other hand, something that can be setup in a parent scope and can apply downward over a nest of delimited constructs. Is this rule required? For regexp I see it, but for delimited things we can just suspend scanning and pick up again on the other side. PAGE \# "'Page: '#' '" Im uncomfortable with this notion. If the last one's optional it want really a terminator, but a separator for the enclosing group. PAGE \# "'Page: '#' '" Its more complicated than this. Perhaps we need a builtin delimiter newline that matches any of the alternatives. PAGE \# "'Page: '#' '" Absent and Missing are generally synonyms, and it seems risky to assign them different meanings. Missing implies an error, so I prefer absent. I am concerned here. An empty string is either a null value a default value, or a legal value. This seems to add another special category that only applies for strings. This describes only in-band nulls. It doesn't describe the also-common flag or out-of-band nulls. Although an element may contain an out-of-bound value in the input stream as its null value it would still be a given the special NULL value as its logical value. This could be indicated by setting nullKind to literalCharacter or literalValue. Similarly a element indicated as being null by another element in the input stream would also be given the special NULL value. I think this entire examples section needs to be split into separate rationale and specification sections. TBD PAGE \# "'Page: '#' '" What does this mean? Surely separators are always infix. PAGE \# "'Page: '#' '" Is this necessary? Any value other than 'always' is inconsistent with earlier rules, and with the principle that we don't do transformations.  Not sure about this. We need to go through the whole min/maxOccurs thing very carefully, its a thorny area.  Yes, it could be considered that if an xpath is specified that exactly that number of repeats should appear in the input document. Is another enumeration of occursKind required?  Yes, I think an additional occursKind property enumeration is required. For instance an enumeration with name occursSeparator. Which means that the number of occurs separators determines the number of repeats. This will only work if the occurs separator doesnt conflict with the separator of the enclosing group or above in the model. Hmm. this example has positional elements and initiators and initiatedElementNull. My guess is that typical use of initiators like this is in unoredered representations and then this would be unclear as your "xxx" doesn't identify which element is present the way an initiator does. In other words, there's lots of potential for ambiguity here. I'm concerned that this initiatedElementNull thing that allows the initiator to be absent when the element is null is actually it's own kind of tag which can be used BOTH to identify which element is occurring, and to recognize that it is null. That's the case in the XML/TX explanation you gave above. you discuss this more later below, but I think the issue is already apparent here. I agree there is an ambiguity. However the non-XML example given by Stephanie Fetzer was of elements with non-discriminating initiators where the null elements were indicated by N/A for example #AAAA|N/A|#CCCC|#DDDD Will the stop value actually be represented. I can see it would make sense for a stopValueKind of logical but I am not sure whether this would make sense literal and empty. Does the stopValue count as a repeat? For instance if stopValueKind is set to logical it would make sense for this to be the case. However if it is set to empty it would not make sense because it is intended to handle the case where the end of the repeats are modeled by two consecutive occurs separators.  We need to go through the min/maxOccurs thing very carefully, its a thorny area. Should the calculation be checked to ensure that it indicates that the value is null. In particular if it refers to another element. If it doesnt match should an error be thrown. Alternatively should a reverse calculation be specified which can be used to set the value from the other element. I believe that proper functioning for output should set the nullIndiatorPath location automatically. However, as with stored length information the case of whether the user overwrites it with an invalid value is present. I think it is a good idea for a element that is an indicator or length for another element to simply not be writable directly. A calculation for output would have to be what fills it in. Perhaps we have a property to stipulate this, and you take your chances if you don't use it? This sounds like a reasonable way to go. However at the moment the reference is from the element whose nullness or length is indicated by this element. It is possible to have more than one element referring to the same length or indicator element. Should we also have a reverse reference from the indicating element to the element from which its value is calculated on output? Should references by restricted to 1 - 1 references? TBD: security how to state that any bits/bytes left over after all the fields are layed out must be filled with fillByte. This idea really complicates the semantics. Perhaps we can just dismiss this as a syntax sugar of some sort or just leave it out? (I have seen it used quite a bit though...) To make this a schema definition error I believe that offset must be a literal value, not a computed value. offsetFrom can't sensibly be an expression since it identifies another element in the schema. Grammars are not universal, they should be specified by parse strategies. One parse strategy, one grammar. TBD: this must be enhanced for nulls/defaults/optional/missing ???? E.g., the cobol example where the entire thing is filled with "high values" or "low values". I think we need NP = null pattern, NV = null value (the indicator value), empty (the value is missing which means we have to have a TERM. Note that our Parse Rules must return a null indicator for the value in addition to the other things they return. Need to make clear what optional means vs. size zero. Can it? perhaps it must be a literal integer? TBD: perhaps this is where we extend the path to have the sub-element name on the end of it? I prefer to do that in the general code of how sequence groups are handled, not in the specific strategy. TBD: this can't deal with case insensitivity or any other kind of initiator match other than exact bits match. Need to distinguish a type error (schema definition) from a run time error (parse error) TBD: this can't deal with case insensitivity or any other kind of initiator match other than exact bits match. Need to distinguish a type error (schema definition) from a run time error (parse error) Do we need regexp for Array lengths or just simple types? Anyone know of any example using regexp for length of an array? Really it's not much different than lengthUnits='characters' where instead of a stored length indicating N characters, we find the Nth character by scanning with a regexp. Stop No Yes Element missing? To Null Handling Assign Default or Fixed Value Yes No Default or Fixed value specified? Stop Yes Yes No No Element missing? UseNullValueForDefault? Default Handling No Yes Output initiator, value and terminator based on nullKind, nullValues and initiatedElementNull No Initiated Element? From Default Handling Output value based on nullKind and nullValues No Stop Process referenced element TBD Yes nullKind == logical && nullIteratorPath set? No Output initiator only Yes initiatedElementMissingWhen == absent? Stop nullKind == missing? No Yes Yes No Yes Element value == null? To Main Flow Initiated Element? Null Handling No Yes From Null Handling To Default Handling To Null Handling DefaultWhenMissing == output or always? Yes No Stop Nillable? Start Yes No Element missing? Assign Default or Fixed Value Yes No Default or Fixed value specified? Parse value normally Yes Yes Check element against initiatedElementMissingWhen No No Initiated Element? Element optional? Default Handling Assign Null Value Yes No Element optional? Element missing? To Main Flow No Yes Null? Check element using nullKind, nullValues and initiatedElementNullWhen No Yes Initiated Element? No No No Yes Referenced element value matches null value? Yes To Main Flow Check value of element referenced by nullindicatorPath and nullIndicatorIndex against nullValues property No Yes Assign Null Value Element value matches null value? nullKind == xpath? Check element value using nullKind and nullValues Yes Check element against initiatedElementMissingWhen No Yes No Yes nullKind == missing? To Main Flow Initiated Element? Null Handling No Yes From Null Handling To Default Handling To Null Handling defaultWhenMissing == onInput or always? Yes No Parse value normally. Nillable? Start Name=C Value=ccc Name=B Value=NULL Name=A Value=aaa Name=root Name=C Value=ccc Name=B Value=NULL Name=A Value=aaa Name=root Name=C Value=ccc Name=B Value=NULL Name=A Value=aaa Name=root Name=A Value=zzz Name=A Value=zzz Name=C Value=ccc Name=B Value=bbb Name=A Value=aaa Name=root Name=C Value=ccc Name=B Value=zzz Name=A Value=aaa Name=root Name=C Value=ccc Name=B Value=zzz Name=A Value=aaa Name=root Name=C Value=ccc Name=A Value=aaa Name=root Name=C Value=ccc Name=B Value=zzz Name=A Value=aaa Name=root Name=C Value=ccc Name=B Value=bbb Name=A Value=aaa Name=root  EMBED PowerPoint.Slide.8  /hijl/8is7;f#s#t##################rjUmHnHujUmHnHumHnHu&jD>*B*UmHnHphu mHnHu0JmHnHuj0JUmHnHuB*OJQJ^JaJph5B*OJQJ\^JaJphCJaJ56>*\]5>* jU5CJ jU)/Bhikl./89IK\|u$IfD & F$a$\*9=?O|}u$If[$$Ifl!!04 lal7m   " jpdd[[[djdd u$$Ifa$u$If$$Ifl\8 !8 04 lal " ? J K O ] y [[|$$Ifl\8 !8 04 lalu$If u$$Ifa$  F a 6 u$$Ifa$u$If Z[fgkyj dd[[[dj dd u$$Ifa$u$If$$Ifl\8 !8 04 lal y[T$$Ifl\8 !8 04 lalu$If u$$Ifa$ [fgky n[ $$Ifl\8 !8 04 lalu$If u$$Ifa$ Ydeiw[x[$$Ifl\8 !8 04 lalu$If u$$Ifa$ [[$$Ifl\8 !8 04 lal u$$Ifa$u$If  )lwx[[$$Ifl\8 !8 04 lal u$$Ifa$u$If x| !%3yz[$$Ifl\8 !8 04 lal u$$Ifa$u$If jdd[[[dj,dd u$$Ifa$u$If$$Ifl\8 !8 04 lal  $T_`dr[H[`$$Ifl\8 !8 04 lalu$If u$$Ifa$ r,789JT & F$$Ifl\8 !8 04 lalu$If u$$Ifa$J]q*F & F#EƀfoF & F#EƀfoF & F#Eƀf(67qiiiiiiiii7$8$H$F & F#EƀfoF & F#Eƀfo [G e]]]7$8$H$M & F;7$8$EƀfH$M & F;7$8$EƀfH$G eM & F?7$8$EƀfH$M & F?7$8$EƀfH$ eM & F?7$8$EƀfH$M & F?7$8$EƀfH$ !!""d#e#f#g#i#r#s##F$$$6%%^ !  & F7$8$H$M & F?7$8$EƀfH$####$$$$$$%$&$@$A$B$C$D$E$F$G$H$d$e$f$g$w$x$y$$$$$$$$$$$$$$$ڸڊڸ|h&j2>*B*UmHnHphujUmHnHu&j8>*B*UmHnHphujUmHnHujUmHnHumHnHu&j>>*B*UmHnHphu mHnHu0JmHnHuj0JUmHnHuCJOJPJQJmHnHtHu($$$$$$$$$$$$ % % % %%%%0%1%2%3%4%5%6%7%8%T%U%V%W%x%y%z%%%%%%%%%%ѹѹѹ}ѹoѹjUmHnHu&j&>*B*UmHnHphujUmHnHu&j,>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujUmHnHujUmHnHumHnHu+%%%%%%%%%%%%%%%%%%% & & &&&&%&&&'&A&B&C&E&F&G&H&I&J&f&g&h&i&񸬸񸬸|h&j >*B*UmHnHphujUmHnHu&j>*B*UmHnHphujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j >*B*UmHnHphu0JmHnHu mHnHu(%%H&&&M''(o((#)))@***_++,h,,;--...i//` ! _  ! ^ ! i&l&m&z&{&|&&&&&&&&&&&&&&&&&&&&&&&&&&&&''''''*'+','F'G'ӸߐӸ|nj UmHnHu&j >*B*UmHnHphuj UmHnHu&j >*B*UmHnHphu mHnHuj0JUmHnHuj UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHu+G'H'J'K'L'M'N'O'k'l'm'n'q'r''''''''''''''''''''''''''((((( (!(ƬƊ|jy UmHnHu&j >*B*UmHnHphuj UmHnHu&j >*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHu-!("(#($(%(L(M(N(h(i(j(l(m(n(o(p(q((((((((((((((((((((((((()׿ן׋׿}ןi&j>*B*UmHnHphujmUmHnHu&j>*B*UmHnHphu mHnHujsUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j >*B*UmHnHphu))))))) )!)")#)$)%)A)B)C)D)G)H)v)w)x))))))))))))))))))))))))ѹѹѹ}ѹoj[UmHnHu&j>*B*UmHnHphujaUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujgUmHnHujUmHnHumHnHu+)))))*********9*:*;*=*>*?*@*A*B*^*_*`*a*b*c***************۹ۋ۹}jOUmHnHu&j>*B*UmHnHphujUUmHnHujUmHnHumHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*****************+++++"+#+<+=+>+X+Y+Z+\+]+^+_+`+a+}+~++++++׿ן׋׿}ןi&j>*B*UmHnHphujCUmHnHu&j>*B*UmHnHphu mHnHujIUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j>*B*UmHnHphu)++++++++++++++++++++++++,,,,,,",#,$,%,(,),E,F,G,a,b,c,e,f,ѹѹѹ}ѹoj1UmHnHu&j>*B*UmHnHphuj7UmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj=UmHnHujUmHnHumHnHu+f,g,h,i,j,,,,,,,,,,,,,,,,,,,,,,,-----4-5-6-8-9-:-;-<-=-Y-Z-۹ۋ۹}j%UmHnHu&j>*B*UmHnHphuj+UmHnHujUmHnHumHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*Z-[-\-a-b----------------------.........9.:.;.<.?.@.c.׿ן׋׿}ןi&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphu mHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j>*B*UmHnHphu)c.d.e............................// / ///F/G/H/b/c/d/f/g/ѹѹѹ}ѹoj UmHnHu&j>*B*UmHnHphuj UmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujUmHnHujUmHnHumHnHu+g/h/i/j/k///////////////////0000 00607080R0S0T0V0W0X0Y0Z0[0w0x0۹ۋ۹}j!UmHnHu&j~!>*B*UmHnHphuj!UmHnHujUmHnHumHnHu&j >*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*/Y00-11 2w22Q33344555F666D77 8m88)999B::^ ! _  ! ` ! x0y0z000000000000000000000 1 1 1&1'1(1*1+1,1-1.1/1K1L1M1N1S1T1u1׿ן׋׿}ןi&jl$>*B*UmHnHphuj#UmHnHu&jr#>*B*UmHnHphu mHnHuj"UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&jx">*B*UmHnHphu)u1v1w1111111111111111111222 2 2 2 222+2,2-2.21222T2U2V2p2q2r2t2u2ѹѹѹ}ѹoj&UmHnHu&j`&>*B*UmHnHphuj%UmHnHu&jf%>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj$UmHnHujUmHnHumHnHu+u2v2w2x2y22222222222222222223333 3 3.3/303J3K3L3N3O3P3Q3R3S3o3p3۹ۋ۹}j(UmHnHu&jT(>*B*UmHnHphuj'UmHnHujUmHnHumHnHu&jZ'>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*p3q3r3u3v3333333333333333333444,4-4.4041424344454Q4R4S4T4W4X44׿ן׋׿}ןi&jB+>*B*UmHnHphuj*UmHnHu&jH*>*B*UmHnHphu mHnHuj)UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&jN)>*B*UmHnHphu)4444444444444444444445555555553545556595:5d5e5f55ѹѕѹsѹ&j6->*B*UmHnHphuj,UmHnHu0JmHnHsH u&j<,>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj+UmHnHujUmHnHumHnHu'555555555555555555555555555556666#6$6%6?6@6A6C6D6E6F6G6ѹѹޑѹ}ѹoj/UmHnHu&j*/>*B*UmHnHphuj.UmHnHu&j0.>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHuj-UmHnHu+G6H6d6e6f6g6j6k6y6z6{6666666666666666666666666666 7 77|h&j2>*B*UmHnHphuj1UmHnHu&j1>*B*UmHnHphuj0UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j$0>*B*UmHnHphu mHnHu0JmHnHu(7777!7"7#7=7>7?7A7B7C7D7E7F7b7c7d7e7h7i77777777777777777777778ӹەӇsە&j 4>*B*UmHnHphuj3UmHnHu0JmHnHsH u&j3>*B*UmHnHphu mHnHuj2UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+88888 8 8 8 8(8)8*8+8.8/8J8K8L8f8g8h8j8k8l8m8n8o88888888888888ѹѕއѹsѹej}6UmHnHu&j6>*B*UmHnHphuj5UmHnHu0JmHnHsH u&j5>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHuj4UmHnHu'888888888888999"9#9$9&9'9(9)9*9+9G9H9I9J9M9N9d9e9f999999999999δάΊά|jq8UmHnHu&j7>*B*UmHnHphujw7UmHnHumHnHu&j6>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujUmHnHu+99999999999999999:::: : :: :!:;:<:=:?:@:A:B:C:D:`:a:b:c:f:g::׿ן׋׿}ןi&j:>*B*UmHnHphuje:UmHnHu&j9>*B*UmHnHphu mHnHujk9UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j8>*B*UmHnHphu)::::::::::::::::::::: ; ;;;;;;;;1;2;3;4;7;8;S;T;U;o;p;q;s;t;ѹѹѹ}ѹojS=UmHnHu&j<>*B*UmHnHphujY<UmHnHu&j;>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj_;UmHnHujUmHnHumHnHu+:;v;;:<<=g==>w>>\??@t@@1AAATBBBCCBDa @! ` ! _ ! ^ X! _  ! t;u;v;w;x;;;;;;;;;;;;;;;;;;;< < < < <<<<<3<4<5<7<8<9<:<;<<<X<Y<۹ۋ۹}jG?UmHnHu&j>>*B*UmHnHphujM>UmHnHujUmHnHumHnHu&j=>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*Y<Z<[<_<`<x<y<z<<<<<<<<<<<<<<<<<<<<<<<<===== =!="=&='=D=׿ן׋׿}ןi&jA>*B*UmHnHphuj;AUmHnHu&j@>*B*UmHnHphu mHnHujA@UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j?>*B*UmHnHphu)D=E=F=`=a=b=d=e=f=g=h=i============================>>>>>ѹѹѹ}ѹoj)DUmHnHu&jC>*B*UmHnHphuj/CUmHnHu&jB>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj5BUmHnHujUmHnHumHnHu+>>>>>;><>=>>>D>E>T>U>V>p>q>r>t>u>v>w>x>y>>>>>>>>>>>>>>>>>>>>>۹ۋ۹}jFUmHnHu&jE>*B*UmHnHphuj#EUmHnHujUmHnHumHnHu&jD>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*>>>>>9?:?;?U?V?W?Y?Z?[?\?]?^?z?{?|?}??????????????????????׿ן׋׿}ןi&jH>*B*UmHnHphujHUmHnHu&jG>*B*UmHnHphu mHnHujGUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&jF>*B*UmHnHphu)???@ @ @ @ @@@@@-@.@/@0@4@5@Q@R@S@m@n@o@q@r@s@t@u@v@@@@@@@@@@@@@@@ѹѹѹ}ѹojJUmHnHu&jJ>*B*UmHnHphujJUmHnHu&jI>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj IUmHnHujUmHnHumHnHu+@@@@@@@@@@@AAA*A+A,A.A/A0A1A2A3AOAPAQARAVAWAkAlAmAAAAAAAAAAAA۹ۋ۹}jLUmHnHu&jvL>*B*UmHnHphujKUmHnHujUmHnHumHnHu&j|K>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*AAAAAAAAAAAAAAAAABBBBBB1B2B3BMBNBOBQBRBSBTBUBVBrBsBtBuByBzBB׿ן׋׿}ןi&jdO>*B*UmHnHphujNUmHnHu&jjN>*B*UmHnHphu mHnHujMUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&jpM>*B*UmHnHphu)BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBCCCC C!CoCpCqCCCCCCѹѹѹ}ѹojQUmHnHu&jXQ>*B*UmHnHphujPUmHnHu&j^P>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujOUmHnHujUmHnHumHnHu+CCCCCCCCCCCCCCCCCCCCCCCDDDD D DD D!D;D*B*UmHnHphujRUmHnHujUmHnHumHnHu&jRR>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*aDbDcDiDjD}D~DDDDDDDDDDDDDDDDDDDDDDDDDDDDDEEEսߛߛśsߛ_&j:V>*B*UmHnHphujUUmHnHu&j@U>*B*UmHnHphu mHnHu0JmHnHujTUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHsH uj0JUmHnHu&jFT>*B*UmHnHphu%BDDDSEE>FF%GGG@HHHNIIJJJQKK2LL(MM,N^ X! a ! ` x! a @! _ ! ` ! EEEE0E1E2ELEMENEPEQERESETEUEqErEsEtE|E}EEEEEEEEEEEEEEEEEEEFFF7Fӹӑ}&j.X>*B*UmHnHphujWUmHnHu&j4W>*B*UmHnHphu mHnHujVUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+7F8F9F;FF?F@F\F]F^F_FgFhFFFFFFFFFFFFFFFFFFFGGGGG G"G#G$G%G&Gѹѹޑѹ}ѹojZUmHnHu&j"Z>*B*UmHnHphujYUmHnHu&j(Y>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujXUmHnHu+&G'GCGDGEGFGLGMG^G_G`GzG{G|G~GGGGGGGGGGGGGGGGGGGGGGGGGGG|h&j]>*B*UmHnHphuj\UmHnHu&j\>*B*UmHnHphuj[UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j[>*B*UmHnHphu mHnHu0JmHnHu(GGHHHHH9H:H;H=H>H?H@HAHBH^H_H`HaHfHgHwHxHyHHHHHHHHHHHHHHHHHHHHӹӑ}&j_>*B*UmHnHphuj^UmHnHu&j ^>*B*UmHnHphu mHnHuj]UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+HHHHHHHHHIIIII I+I,I-IGIHIIIKILIMINIOIPIlImInIoIxIyIIIIIIIIIIIIѹѹޑѹ}ѹojuaUmHnHu&j`>*B*UmHnHphuj{`UmHnHu&j_>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHuj_UmHnHu+IIIIIIIIIIIJJJJJJJJ JJ?JAJBJoJpJqJJJJJJJJJJJJJ|h&jc>*B*UmHnHphujicUmHnHu&jb>*B*UmHnHphujobUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&ja>*B*UmHnHphu mHnHu0JmHnHu(JJJJJJJJJJJJJJJJKKKKKK.K/K0KJKKKLKNKOKPKQKRKSKoKpKqKrKtKuKKKKKӹӑ}&je>*B*UmHnHphuj]eUmHnHu&jd>*B*UmHnHphu mHnHujcdUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+KKKKKKKKKKKKKKKLLL+L,L-L/L0L1L2L3L4LPLQLRLSLWLXLLLLLLLLLLLLѹѹޑѹ}ѹojKhUmHnHu&jg>*B*UmHnHphujQgUmHnHu&jf>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujWfUmHnHu+LLLLLLLLMMM!M"M#M%M&M'M(M)M*MFMGMHMIMOMPMMMMMMMMMMMMMMMM|h&jj>*B*UmHnHphuj?jUmHnHu&ji>*B*UmHnHphujEiUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&jh>*B*UmHnHphu mHnHu0JmHnHu(MMMM N N N%N&N'N)N*N+N,N-N.NJNKNLNMNUNVNNNNNNNNNNNNNNNNNNNOOO.Oӹӑ}&jl>*B*UmHnHphuj3lUmHnHu&jk>*B*UmHnHphu mHnHuj9kUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+,NN5OOEPPLQQ)RRRQSS2TTUiUU7VVWmWW=XXXPY^ X! _ ! ` ! a @! .O/O0O2O3O4O5O6O7OSOTOUOVO\O]OOOOOOOOOOOOOOOOOOO"P#P$P>P?P@PBPCPDPEPFPѹѹޑѹ}ѹoj!oUmHnHu&jn>*B*UmHnHphuj'nUmHnHu&jm>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHuj-mUmHnHu+FPGPcPdPePfPlPmPPPPPPPPPPPPPPPPPPP)Q*Q+QEQFQGQIQJQKQLQMQNQjQkQlQ|h&jq>*B*UmHnHphujqUmHnHu&jp>*B*UmHnHphujpUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&jo>*B*UmHnHphu mHnHu0JmHnHu(lQmQsQtQQQQQQQQQQQQQQQQQQQRRR"R#R$R&R'R(R)R*R+RGRHRIRJRPRQRcRdReRRӹӑ}&js>*B*UmHnHphuj sUmHnHu&jr>*B*UmHnHphu mHnHujrUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+RRRRRRRRRRRRRRRRRRRRRRRRRRR S S S SSS.S/S0SJSKSLSNSOSPSQSRSѹѹޑѹ}ѹojuUmHnHu&jzu>*B*UmHnHphujtUmHnHu&jt>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujtUmHnHu+RSSSoSpSqSrSxSySSSSSSSSSSSSSSSSSSSTTT+T,T-T/T0T1T2T3T4TPTQTRT|h&jhx>*B*UmHnHphujwUmHnHu&jnw>*B*UmHnHphujvUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&jtv>*B*UmHnHphu mHnHu0JmHnHu(RTSTYTZTrTsTtTTTTTTTTTTTTTTTTTTT U U U UUUUUU.U/U0U1U5U6UFUGUHUbUӹӑ}&j\z>*B*UmHnHphujyUmHnHu&jby>*B*UmHnHphu mHnHujxUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+bUcUdUfUgUhUiUjUkUUUUUUUUUUUUUUUUUUUUUUUUUVVV0V1V2V4V5V6V7V8Vѹѹޑѹ}ѹoj|UmHnHu&jP|>*B*UmHnHphuj{UmHnHu&jV{>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujzUmHnHu+8V9VUVVVWVXV^V_VVVVVVVVVVVVVVVVVVVVVV W W WWWWWWW/W0W1W|h&j>>*B*UmHnHphuj~UmHnHu&jD~>*B*UmHnHphuj}UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&jJ}>*B*UmHnHphu mHnHu0JmHnHu(1W2W6W7WJWKWLWfWgWhWjWkWlWmWnWoWWWWWWWWWWWWWWWWWWWWWWWWWXXX6Xӹӑ}&j2>*B*UmHnHphujUmHnHu&j8>*B*UmHnHphu mHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+6X7X8X:X;XX?X[X\X]X^XdXeXnXoXpXXXXXXXXXXXXXXXXXXXXXXXXXXXѹѹޑѹ}ѹojUmHnHu&j&>*B*UmHnHphujUmHnHu&j,>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujUmHnHu+XXYYYY Y Y-Y.Y/YIYJYKYMYNYOYPYQYRYnYoYpYqYwYxYYYYYYYYYYYYYYYY|h&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j >*B*UmHnHphu mHnHu0JmHnHu(PYY1ZZZT[[\l\\H]]]_^^ _]__U``4aabpbb]cc?d_ ! ^ X! ` ! YYYYZZZ*Z+Z,Z.Z/Z0Z1Z2Z3ZOZPZQZRZTZUZhZiZjZZZZZZZZZZZZZZZZZZZZѷ󯩯ٯч󯩯sٯ&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHsH uj0JUmHnHu+ZZZZZZZZ[[[[[%[&[1[2[3[M[N[O[Q[R[S[T[U[V[r[s[t[u[{[|[[[[[[[[[[[[ѹѹޑѹ}ѹojyUmHnHu&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujUmHnHu+[[[[[[[[[[[\\\\\\\\ \%\&\'\(\.\/\I\J\K\e\f\g\i\j\k\l\m\n\\\\|h&j>*B*UmHnHphujmUmHnHu&j>*B*UmHnHphujsUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHu(\\\\\\\\\\\\\\\\\\\\\\%]&]']A]B]C]E]F]G]H]I]J]f]g]h]i]k]l]]]]]ӹӑ}&jގ>*B*UmHnHphujaUmHnHu&j>*B*UmHnHphu mHnHujgUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+]]]]]]]]]]]]]]]]]]]]]]]]]]]^^^^^^<^=^>^X^Y^Z^\^]^^^_^`^ѹѹޑѹ}ѹojOUmHnHu&jҐ>*B*UmHnHphujUUmHnHu&j؏>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHuj[UmHnHu+`^a^}^~^^^^^^^^^^^^^^^^^^^^^^^^^^___ _ _ _ _ __*_+_,_|h&j>*B*UmHnHphujCUmHnHu&jƒ>*B*UmHnHphujIUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j̑>*B*UmHnHphu mHnHu0JmHnHu(,_-_/_0_:_;_<_V_W_X_Z_[_\_]_^___{_|_}_~_______________``````1`2`3`M`ӹӑ}&j>*B*UmHnHphuj7UmHnHu&j>*B*UmHnHphu mHnHuj=UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+M`N`O`R`S`T`U`V`W`s`t`u`v`|`}```````````````````aaa,a-a.a1a2a3a4a5aѹѹޑѹ}ѹoj%UmHnHu&j>*B*UmHnHphuj+UmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHuj1UmHnHu+5a6aRaSaTaUaYaZauavawaaaaaaaaaaaaaaaaaaabbbbbbbbb7b8b9b|h&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHu(9b:b@bAbLbMbNbhbibjbmbnbobpbqbrbbbbbbbbbbbbbbbbbbbbbcccc9c:c;cUcӹӑ}&j>*B*UmHnHphuj UmHnHu&j>*B*UmHnHphu mHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+UcVcWcZc[c\c]c^c_c{c|c}c~cccccccccccccccccccddddd7d8d9dd?d@dѹѹޑѹ}ѹojUmHnHu&j~>*B*UmHnHphujUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujUmHnHu+@dAd]d^d_d`dfdgdrdsdtdddddddddddddddddddeeeeeeeee7e8e9e|h&jl>*B*UmHnHphujUmHnHu&jr>*B*UmHnHphujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHuj0JUmHnHu&jx>*B*UmHnHphu mHnHu0JmHnHu(?ddeefff)gghh"ii2jjkkkWllmmnpnnToo_ ! ^ X! a @! ` ! 9e:e@eAeteueveeeeeeeeeeeeeeeeeeeeeeffffff!f"f#f$f&f'f^f_f`fzfӹӑ}&j`>*B*UmHnHphujUmHnHu&jf>*B*UmHnHphu mHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu+zf{f|fffffffffffffffffffffffffffffffggg!g"g#g&gѹѹޑѹ}ssejѥUmHnHu0JmHnHsH u&jT>*B*UmHnHphujפUmHnHu&jZ>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujݣUmHnHu'&g'g(g)g*g+gGgHgIgJgNgOgrgsgtggggggggggggggggggghhhhhhhhh:h;hδάΊά|jŧUmHnHu&jH>*B*UmHnHphuj˦UmHnHumHnHu&jN>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujUmHnHu+;h*B*UmHnHphujUmHnHu&j<>*B*UmHnHphu mHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&jB>*B*UmHnHphu)iiiiiiiiiiiiiiiiiijjj*j+j,j/j0j1j2j3j4jPjQjRjSjWjXjjjjjѹѹѹ}ss0JmHnHsH u&j*>*B*UmHnHphujUmHnHu&j0>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujUmHnHujUmHnHumHnHu'jjjjjjjjjjjjjjjjjjjjjjkkkkk k!k"k#k%k&kbkckdk~kkkkѹѕއѹsѹejUmHnHu&j>*B*UmHnHphujUmHnHu0JmHnHsH u&j$>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHumHnHujUmHnHujUmHnHu'kkkkkkkkkkkkkkkkkkkkkkkk llllll3l4l5lOlPlQlTlUlVlWlXlYlulvlδάΊά|jUmHnHu&j>*B*UmHnHphujUmHnHumHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHujUmHnHu+vlwlxl~lllllllllllllllllllllllmmm m m mmmm,m-m.m/m5m6mam׿ן׋׿}ןi&j>*B*UmHnHphujUmHnHu&j>*B*UmHnHphu mHnHujUmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j >*B*UmHnHphu)ambmcm}m~mmmmmmmmmmmmmmmmmn n n nnnnnn.n/n0n1n5n6nLnMnNnhninjnmnnnѹѹѹ}ѹojqUmHnHu&j>*B*UmHnHphujwUmHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHuj}UmHnHujUmHnHumHnHu+nnonpnqnrnnnnnnnnnnnnnnnnnnnnnnnoo0o1o2oLoMoNoQoRoSoToUoVoroso۹ۋ۹}jeUmHnHu&j>*B*UmHnHphujkUmHnHujUmHnHumHnHu&j>*B*UmHnHphu mHnHu0JmHnHuCJOJPJQJmHnHtHuj0JUmHnHu*sotouo{o|oooooooooooo|!|}}KQpvq67œǓϓѓՓ׿Ǡ|zslzeze *B*ph *B*ph *B* ph *CJOJQJaJmHnHumH sH  mHnHsH  jJ66] jUj_UmHnHujUmHnHumHnHuCJOJPJQJmHnHtHu0JmHnHuj0JUmHnHu&j>*B*UmHnHphu&oooopqdF & F!EƀfF & F!Eƀfh^h & Fq]qArrq*F & F!EƀfF & F!EƀfF & F!Eƀfrjskslssssqkiii*h^hF & F!EƀfF & F!Eƀfssssq*F* & FEƀf-F* & FEƀf-F* & FEƀf-stttbucuuqoooo*F* & FEƀf -F* & FEƀf-uuw%x7xsFD & F7EƀfCEƀf7xYxux{|qooooommmDFD & F7EƀfFD & F7Eƀf )IōuCEƀf.CEƀf. Ð ͑<bqr,67pCEƀf..ғ?RhyȔ.ABB_`1DW& >,X4` <hDp7$8$H$pՓ֓>?DFPQWYfgklwx~Ôǔ͔Δؔݔߔ !,-/1?@AB *B*ph *B* ph * *B*ph *5B* ph *5 *5B*ph *5B* ph *5NB^4_#%025;C*~ΰϰF׶ϷзDQASp jU jKCI U6]PJ^JaJnHtHj0Jv5KHU\^JmH sH  j0JvU60J6>*B*phjܸU jU] *55 mHnHsH @ė;_ΘϘИSCEƀf.pSqo,CEƀf.F & FHEƀf-F & FHEƀf-)So(F & FFEƀf-F & FFEƀf-F & FFEƀf-HIq*(F & FFEƀf -F & FFEƀf -F & FFEƀf-I[ȝo(F & FEEƀf-F & FEEƀf-F & FEEƀf-ȝ0zq*F & FEEƀf -F & FEEƀf -F & FEEƀf-z֞,q*F & FEEƀf -F & FEEƀf -F & FEEƀf -,]^˟)СHmF & F6EƀfF & FEEƀf- H)sCEƀf.F & F6Eƀf)@oq*F & FGEƀf-F & FGEƀfoF & FGEƀf-פVq.,CEƀfF & FGEƀfoF & FGEƀfoVdJҧwusCEƀf.DCEƀf.)bӯ=аR> uCEƀf.CEƀf. toF & F$EƀfF & F$EƀfBq*F & F$EƀfF & F$EƀfF & F$EƀfBRǷѷ׹9?sqqqqqqqqqqDCEƀfF & F$Eƀf S9oF & F$EƀfF & F$EƀfD99sqf $7$8$H$a$CEƀfDF & F$Eƀf  OX$ & F7$8$Eƀf" H$^`a$X$ & F7$8$Eƀf" H$^`a$  OX$ & F7$8$Eƀf" H$^`a$X$ & F7$8$Eƀf" H$^`a$ )<WopDX$ & F7$8$Eƀf" H$^`a$ $7$8$H$a$X$ & F7$8$Eƀf" H$^`a$p<5"4^CEƀf &'?@TUef56bcd#$NO|} mHnHujU0JsjUjUjU0Jj>U jU6]6jUmHnHu j0JvUD(JqF & FEƀfCEƀf.Jq*F & FEƀfF & FEƀfF & FEƀfL q*F & FEƀfF & FEƀfF & FEƀf /Gq*F & FEƀf F & FEƀf F & FEƀfGkq*F & FEƀf F & FEƀf F & FEƀf ;oqooF & FEƀfF & FEƀf@Ufq*F & FEƀfF & FEƀfF & FEƀff~q*F & FEƀfF & FEƀfF & FEƀfq*F & FEƀf F & FEƀfF & FEƀfq*F & FEƀf F & FEƀf F & FEƀf F6A&PBwuuoouuh^hCEƀf.CEƀf 3" $$Ifa$$IfCEƀf.]^` (bmuh0J5B*CJaJph0J56CJaJ0J5CJaJ0J5B*CJaJph0J6B*CJaJph0JB*CJaJph0JB*CJaJph0JB* CJaJph6jzUjU j0JU j0JvUj0JvUmH nH sH tH 0J mHnHu jU(ev $$Ifa$$Ify$$Ifl0 ," t0644 laefsxvv $$Ifa$$Ify$$Ifl^0 ," t0644 la+,3<v<vvxvT $$Ifa$$Ify$$IflL0 ," t0644 la _`avv`vty$$IflL0 ," t0644 la $$Ifa$$If a 's,F & FEƀfF & FEƀfCEƀf..'4=5qo,CEƀf.F & FEƀfF & FEƀf5&NSX0OGCEƀf..pH=pqo,CEƀfF & F"EƀfF & F"Eƀfp Hp.9=JKpCEƀf.)IJOPijkno &'(*+lmuw}z 0J56jHhf0Jv<U0J50J6OJQJ^J0JjnUjU6jtUjU jUB* CJaJph0J6B* CJaJph0JB* CJaJph0JB*CJaJph0J5B*CJaJph0Keq lsqqk`CEƀf..DCEƀf.. jk.A , 2 P    8       (  9ûððûðûð0JB*CJaJph0JB* CJaJph j0JvU PJnHtH0JB*CJKH ph0J5CJKH 0JB* CJKH phjhUjU jU 0J5CJ0JB*CJph0JB* CJph656Bwl3r bpCEƀf..Bk DNbv , P Z m  pCEƀf..      < = y    ( )    CEƀf..p)m!R /3@ApCEƀf.9ORXqy /?@t}u`        (!Ӻۭ袙yhy j0JvOJQJUmH nH u 0JCJaJ0J5CJaJmH sH  0J560J56B* CJaJph0JB* CJaJph0J5B*CJaJphHhf0J5CJaJ0J56CJaJ0J5CJaJ0J5B* CJaJph0JB*CJaJph0J6B*CJaJph>uvijusspCEƀf..CEƀf.. j`     4!5!Y!!!"##$j$%pCEƀf.(!)!5!6!!!!""""####s##j$$$%%%%U''++,-.x.|.b1112?344467yrk mHnHsH  j0JvU6]mH sH  6mH sH 5OJQJ\aJmH sH  mHnHsH*jHhf0Jv5<U\]^J Hhf cHdhfmH sH 6]jHhf0Jv<U 0JCJaJ0J5CJaJ0jHhf0Jv<OJQJUmH nH u*%A%F%%%%D&]&p&&&&'+'wuuuuuuupCEƀf.CEƀf. +'O''''''h(() *3***uCEƀf.CEƀf.p *++,<,v,,,-../0a1b1112<222CEƀf.^222?3*44z55L6v6667D7t7v78pCEƀf..^7q7s7v788889999<<==r>u>J?K?5@6@7@@@A.D/DzJ{JJJKLLLOLbPlP~o`jHhעf0Jv<UjHhѢf0Jv<UjHhˢf0Jv<U*jHhǢf0Jv5<U\]^J j0JvUjHhĢf0Jv<UjHhf0Jv<U OJQJ^J5OJQJ\aJmH sH j0Jv5U\]^JmH sH  mHnHsH 5mHnHsH #8899999::;oCEƀf^CEƀf .;;C===0>>?wq^CEƀf.CEƀf.??@@@AwCEƀf.CEƀf.AA/BBC:HVHHrIIuCEƀf.CEƀf. II|J}JJJNLOLqLMNusqCEƀf.CEƀf. NiOO:PPQqooi@^@F & FEƀfF & FEƀflPpPqPQQS%S0S1SSSSST7T>TfTnTTTrUsUUUUUU4VW?WFWGW_W`WiWjWqWrWWWWWWWW j0JvU j0J j0J0J0JjU jU0J 0J5\jHhܢf0Jv<U0JjHhڢf0Jv<U0J0J^JBQQRSS3TfTT[S$ & F%d ddEƀf[$\$a$dd[$\$CEƀf TBUZUJV[VcVh_VV $$Ifa$dd[$\$CEƀf .S$ & F%d ddEƀf[$\$a$cVdVeVnVvVLww $$Ifa$$Ify$$Ifl40 D  t0644 lavVwVVVVVs mddm $$Ifa$$If$$Ifl4F  D $  t06    44 laVVWW#W$W6W>WFWGW_WiWtneetneetne $$Ifa$$If$$IflF  D $  t06    44 la iWqWrWWWWWWWWWWkekeke$If$$IflF  D $  t06    44 la $$Ifa$ WWWWWWWWWWWWWWWWWWX'X.XXXHYMYRYWYsYYYYYYZZ[[R\Z\\\\\Z]g]r]]]]^^__h_o___%`(`D`E`i`l`````WaZayaaaa%b@bbbbccceeVg[g6] j0JvU mHnHsH 0JmHnHsH 0J0J j0J0JTWWWWWWXXYYkZlZkek\ZXdd[$\$$If$$IflF  D $  t06    44 la $$Ifa$ lZ[\\^^/^`aaee/epCEƀf .CEƀf . & F /efgg;jsF & F)EƀfCEƀf ..0q*F & F)EƀfoF & F)EƀfoF & F)Eƀfq*(F & F)EƀfoF & F)EƀfoF & F)Eƀfo  ';ERk`$$Ifl4Fl,"`Pp t06    44 la$If Rfpq!8$$Ifl4֞l" rY,"  t0644 la$IfqH($$IflrlrY,"P t0644 la$If !'H$$IflrlrY,"P t0644 la$If',27$If789?'!!$If$$Ifl4֞l" rY,"` t0644 la?EJOU|$If|}~'L!!$If$$Ifl4֞l" rY,"  t0644 laG$$Ifl4rl" ," p t0644 la$If"(hiGLG$$Ifl4rl" ," p t0644 la$Ifijov{GL$$Ifl4rl" ," p t0644 la$If G$$Ifl4rl" ," p t0644 la$If 34_ekqG$$Ifl4rl" ," p t0644 la$IfMGGGGGGG$If$$Ifl4rl" ,"`p t0644 la'L!!$If$$Ifl4֞l" rY,"  t0644 la!"#).3G$$Ifl4rl" ," p t0644 la$If39RW$IfWXY^'L!!$If$$Ifl4֞l" rY,"  t0644 la^djG$$Ifl4rl" ," p t0644 la$If$If'L!!$If$$Ifl4֞l" rY,"  t0644 la345:?DG$$Ifl4rl" ," p t0644 la$IfDIbg$Ifghi'%%$$Ifl4֞l" rY,"  t0644 las qoooF & F*EƀfF & F*Eƀf&w0F & F0EƀfCEƀf ...CEƀf ..$%%&*+-.89)[prs 23 z~OP j0Jv5U\]^J6]PJaJ 56\]6jVUj0JvPJUjU jU j0JvUj0Jv5U\D2wq*F & F0EƀfF & F0EƀfF & F0Eƀf]UNqoooF & F0EƀfF & F0EƀfVwuo@`@CEƀf CEƀf ...Kw4C|EƀfC|EƀfCEƀf .1Ypkekkkkk@`@| & FC|EƀfC|Eƀf | & F^ T]tC|EƀfC|Eƀf| & FCHrpppCEƀf .| & FC|Eƀf ps,F & F.Eƀf.F & F.Eƀf.CEƀf . aAs0C|Eƀf C|EƀfF & F.Eƀf.A:=ip@`@ | & Fh^hC|Eƀf ? 45yttt| & FC|Eƀf C|Eƀf 5J<Tvwu.F & F.Eƀf.CEƀf ..CEƀf .v#q*F & F.Eƀf.F & F.Eƀf.F & F.Eƀf.Dq*(F & F.Eƀf .F & F.Eƀf .F & F.Eƀf.oF| & F8Eƀf.F| & F8Eƀf..q*F| & F8Eƀf.F| & F8Eƀf.F| & F8Eƀf..Byq*F| & F8Eƀf.F| & F8Eƀf.F| & F8Eƀf.yVq*%| & FF| & F8Eƀf .F| & F8Eƀf .F| & F8Eƀf .1Q&BO>y   ^CEƀf ..| & F    w  pq6Kde}~  )$+$))-*1*\+]+&-'-////0"0$0*0|0}00000001#1&1D1K1]1112 2n4o45555W7X788::y;z;;F<G<w>x>>> @@"@ 6mH sH mH sH 6j0Jv5U\]^J6]j0JvPJUPJaJ j0JvUH*O     s,F & F.Eƀf .F & F.Eƀf .CEƀf .  7&Nq*(F & F.Eƀf.F & F.Eƀf.F & F.Eƀf .N1k!J| & FI Eƀf.J| & FI Eƀf.J| & FI Eƀf.Ak!J| & FI Eƀf.J| & FI Eƀf.J| & FI Eƀf.KeF & FJEƀf.CEƀf . | & Fh^h| & F(fq*F & FJEƀf.F & FJEƀf.F & FJEƀf.f5q*F & FJEƀf.F & FJEƀf.F & FJEƀf.5'<dqooooF & FJEƀf .F & FJEƀf.dC=k!J| & FK Eƀf.J| & FK Eƀf.J| & FK Eƀf. Tk!J| & FK 8Eƀf.J| & FK 8Eƀf.J| & FK Eƀf./k!J| & FK Eƀf.J| & FK 8Eƀf.J| & FK 8Eƀf.//  k!J| & FK Eƀf.J| & FK Eƀf.J| & FK Eƀf.  !Y!!k!J| & FK 8Eƀf .J| & FK 8Eƀf .J| & FK Eƀf .!!\"{"k!J| & FK 8Eƀf .J| & FK 8Eƀf .J| & FK 8Eƀf .{"h#6$&k!J| & FK Eƀf .J| & FK Eƀf .J| & FK Eƀf .&u)v)w))a*`^CEƀf . & F | & FL^`LJ| & FK Eƀf .a*s***q*F & F-EƀfoF & F-EƀfoF & F-Eƀf*1+^++q*F & F-EƀfF & F-EƀfoF & F-Eƀfo+H,,--///0"00qkk$IfCEƀf .F & F-Eƀf 000%1&1D1"2#2$2q233 caC|Eƀf $IfP$$Ifl0,"0h t644 la 34s45q666Y7_J| & FL Eƀf.s | & F ^CEƀf ..Y7|778iJ| & FL Eƀf.K| & FL Eƀf.J| & FL Eƀf.88(:;;;H<cH & F Eƀf.| & FJ| & FL Eƀf.H<< ==w>x>mkkf| & FH & F Eƀf.H & F Eƀf.x>>v@ABbBBB8C9CC^DEFF| & FpCEƀf .."@9@BBBBB8C9CGG$H%HBKHKOO.O/ORR VVXXYYYYY Z Z&Z'Z(Z+Z,Zy\z\\\^^4^?^kjJkkkWoXo6PJ]^JaJnHtHj0Jv5U\]^JjPUjU jU j0JvU6j0Jv5OJQJU\^J6] j0JvOJQJUmH nH uOJQJ^JmHnHsH  mHnHsH mH sH  6mH sH 2FFQGGH&H7IIIJJwuooo$IfCEƀf ..CEƀf . JJJ8J}J~JJJJKKKKOKwqqqw qqqqw0qqq$If$$IflF ,"   t06    44 la OKKKKKK1L2L3LLqqoo$$IflF ,"   t06    44 la$If LLM$NMNs,F & F,EƀfF & F,EƀfCEƀf ...MNN0OOOq*(F & F,EƀfF & F,EƀfF & F,EƀfOPPPfQqF & F9EƀfCEƀf ...fQQQR>RLRRRRS+S>Sqommggggggp^pF & F9EƀfF & F9Eƀf >S?STwTUU,UUVVkF & F9EƀfCEƀf ...p^ VVWCWHXq.,CEƀf ...F & F9EƀfF & F9EƀfHXOXaXeYuY|Z}ZusCEƀf ..CEƀf ..p}ZZZZ5[[[\g\h\i\{\]oCEƀf .@`@CEƀf . ]A^___`)`sF & FCEƀfCEƀf ..)`;`h``q*F & FCEƀfF & FCEƀfF & FCEƀf``\abAcc5dAdd,esCEƀf ..F & FCEƀf ,eEe_eyeq*F & FEƀfF & FEƀfF & FEƀfyefgghiikjkiiiiF & FEƀf^F & FEƀfkjjjkkkF & F@Eƀf.H & F@Eƀf.kklmmnVoWosooppXrerwCEƀf ...CEƀf ... Xooopoqoropp}}ƂЂʋˋ̋΋ϋЋыABXYZqr^Y`$+>XYaghʔ˔ܷ̔j0JvPJUaJ CJ^JaJ6aJmH sH 5jUjUjU656 j0JvU jU jU#j(lI OJQJUVaJnHtH?errrs2s[ssst0tMtftttttt u;uRuuuuvOvbvvvw!wp!w>wWwjw~www xFxTxcxdxyz:{h{{{CEƀf p{||||qF & FEƀfCEƀf | }Y}}q*F & FEƀf F & FEƀfF & FEƀf}~~ʀsqqCEƀfF & FEƀf ʀoq*F & FEƀf.F & FEƀf.F & FEƀf.oaWU)oCEƀfpF & FEƀf. )wÍ4qF & FEƀf.CEƀf4pu^Y$=qkkkkkk`CEƀf.F & FEƀf. =>LXYai̔1Rr{u$Ifw$$Ifl0(# t0#644 la{$If` ̔Ӕ18RZry ./0st() !f(:;<{|*CVWcFG`ad !#$%&<=>~KLfgԸ j0JvUj~UjU jU CJ^JaJ B*aJphj0JjUaJ6aJj0JvPJUaJ5aJH <CEƀf..w$$Ifl0(# t0#644 la{$If IЗ 2v(){$Ifv$$Ifl0\(# t0#44 la)=B a !,1!flv$$Ifl0\(# t0#44 la{$IffΜ;<CM*VWchl }$Ifv$$Ifl0\(# t0#44 la{$IfdKLhpߡ  #}}$Ifv$$Ifl0\(# t0#44 la{$Ifgh  ͢΢բQR]ݣޣMZ[ghzΥϥܥǧȧէDE%23?@WXYMN_`yz{#01=>QjxUaJjUaJ jUaJ j0JvU B*aJph6aJj0JvPJUaJ CJ^JaJL#^͢΢բݢ7QR]h}}$Ifv$$Ifl0\(# t0#44 la{$IfM[g>8$IfCEƀf..v$$Ifl0\(# t0#44 la{$IfghzΥϥܥHdyyyy yyyy{$If$Ify$$Ifl0q(# t 0#644 lasǧȧէڧ6`DEy$Ify$$Ifl0q(# t 0#644 la{$IfEFG{$If$IfCEƀf...ݩM*L {{{{{{{{{{$If$Ifx$$Ifl0p(# t 0#44 la %3?@Y^68y$$Ifl0_ ," t 0"644 la{$If$IfCEƀf...^MN_eSl}y$$Ifl0_ ," t 0"644 la{$If #1=>QX6y$$Ifl0,   t 08644 la{$If$IfCEƀf...Xʯѯ012yw$Ify$$Ifl0,   t 08644 la{$If ʯ./01ɰʰijгѳMNe̴ʹ@Z[Yɶʶ˶+tGHߺ^w6CJ^JaJ j0JvU0JjU jUj0Jv5OJQJU\^J CJPJaJ5CJPJ\^JaJ B*aJph6B*aJph6aJ B*aJphj0JvPJUaJ CJ^JaJ82qɰʰذ<x$$Ifl0,"~ t 0"44 la{$IfCEƀf..ذaQk²Dzkгxx$$Ifl)0,"~ t 0"44 la{$IfгѳMNem̴ʹδ{{{{{{y{$If$Ifx$$Ifl)0,"~ t 0"44 la δ @NZ[e:y$$Ifl0,"t$ t 0"644 la{$IfCEƀf..ej=Z}y$$Ifl%0,"t$ t 0"644 la{$If˶ٶ<(y$$Ifl0UtM t 0644 la{$IfCEƀf..+t}:CEƀf..y$$Ifl%0UtM t 0644 la{$If(JKdOIj$IfCEƀf..  -׽^wKǿD{$Ifv$$Ifl0,"(p t0"44 law89tu?GMcV "<=㗆ӄ~6aJ65!B*^JaJmH nH phsH tH  B*]^JmH nH phsH tH !0JB*CJOJQJ^JaJph!jHhf0Jv<PJUj0JvPJUCJPJ^JaJ B*aJphfaJ^JaJB*PJ^JaJphB*^JaJph0ǿп&\5{hlv$$Ifl0,"(p t0"44 la{$IfVtu? xv$$Ifl0,"(p t0"44 la{$If l8{$Ifv$$Ifl0,"(p t0"44 laev$$Ifl0,"(p t0"44 la{$If CV"0<wqkk{$If^CEƀf..CEƀf.<=L]E'SL{{{{{ {{{{{{$If$Ifw$$Ifl0,"  t0"644 la=L'@RSopemnKL&'rs>?de-.6CJ^JaJ5^J^JaJ B*ph B*PJphPJjUjU jU 5PJ\]6aJ/jHhf0Jv5<OJQJU\^Jj0JvPJU B*aJphaJ CJ^JaJ8STUqB<<{$IfCEƀf..w$$Ifl0,"  t0"644 laap{$Ifx$$Ifl0 t"  t 0"44 lacK@{$Ifx$$Ifl%0 t"  t 0"44 laKL`h(0&'2$H0{$Ifx$$Iflh0 t"  t 0"44 la2:=rs >?IQ0x$$Iflh0 t"  t 0"44 la{$IfQJdeDP| & Fx$$Iflh0 t"  t 0"44 la{$If!-.8<6{$Ifw$$Ifl0at"' t0"644 la$IfCEƀf..8K4MNW]E_`qHw$$Ifl0at"' t0"644 la{$If.hiMN_`qrw~^hZ.I[\a{|lmy'()*CUVW)ȞmH sH CJ^JaJmH sH  j0JvU OJQJ^J!B*^JaJmH nH phsH tH  CJ^JaJ65/jHhf0Jv5<OJQJU\^JCJPJ^JaJj0JvPJUaJ<Xqrs| & F{$Ifw$$Ifl0at"' t0"644 lasw:x$$Ifl0 ,"  t 0"44 la{$IfCEƀf..N o  x$$Ifl0 ,"  t 0"44 la{$If_{{x$$Ifl0 ,"  t 0"44 la{$If$If \Z.@Sx4M[]p 2( Px 4 #\'*.25@9 & F]ao{|{"#,16/Qqyyyyyyyyyy$Ifx$$Ifl0 ,"D T t 0"44 la$If*D4`auWf?, $Ifx$$Ifl0 ,"D T t 0"44 la?kl!x x$$Ifl0 ,"D T t 0"44 la$If$IfCEƀf.. & F.N'W`{$Ifv$$Ifl0#(  t0H$44 la *f<l{$Ifv$$Ifl0#(  t0H$44 la3~ & F{$Ifv$$Ifl0#(  t0H$44 la ghyuCEƀf.CEƀfs,F & F1EƀfF & F1EƀfCEƀf..~qood $$Ifa$F & F1EƀfF & F1Eƀf      . / C X     *+QR CV\])******L-x-)2*2333355:5:g?h?BBCJOJPJQJaJmHnHuj0JvPJUmH sH PJ^JmHnHtH j0JvOJQJUmH nH u j0JvU6]5PJ\^JaJnHtHOJPJQJaJnHtH6PJ]^JaJnHtH9 $ j    $$Ifa$<$$Ifl]%l%l%644 la]       ujbbbj$If $$Ifa$$$Ifl4rny 8_]%$ h( l%644 la]         uLjjbbbjj$If $$Ifa$$$Ifl4rny 8_]%$ h( l%644 la]       , O4DDDDDD $$Ifa$$$Ifl4 ֞Cny 8_;!]%`8$ h8l%644 la], . / 0    J ECCCCC$$Ifl֞Cny 8_;!]%`8$ h8l%644 la] $$Ifa$J j  ,S  :oCEƀf..^CEƀf.. |1 %Gs pCEƀf.^$45HUq"Lbr{ J(u|p|5cFM[cde<^p^p^ : ]    L!!!!!!+"A"Z"[""">$?$?$S$W$w$$%F%wuuCEƀf.CEƀf.F%b%c%%t&&w4C|EƀfC|EƀfC|Eƀf&'!'>'y6C|EƀfC|EƀfC|Eƀf>''s((y6C|EƀfC|EƀfC|Eƀf((()hF| & FAEƀf | & FL^`LC|Eƀf))))***+++ | & FL^`L | & F `| & F F| & FAEƀf ++p,,,-L-a-x---).`.v....^`CEƀf....~///s,F & F/EƀfF & F/EƀfCEƀf../0F1+22223%343Q3333=4444 5E5b5q5555(6N66p`p`6667#8l8"9R9]999kF & FBEƀfCEƀf..`p 99::5:O::::;;+;l;;;;;;F & FBEƀf;<4<y<<2=Z===>>H>ywwnlfffddpp`| & F CEƀf..CEƀf. H>>>>???5?{??7@8@@@ AqAAB9B~BBBBBB | & FL^`L | & FL^`L| & F p`pB$C%CI/J0JGJHJIJJJKJLJMJdJeJfJgJhJiJjJJJJJJ4MMBMDMHMJMPPPPPRRJSLSNSSSWWWYeYY[ddfemH sH 66]/jHhf0Jv5<OJQJU\^JOJPJQJ^JH*OJPJQJ^Jo(o(jUmH sH jUmH sH jUmH sH jUmHnHujUmH sH mH sH j0JvPJU4B8CCDD E&EJEEEEEE/FWFrFFG Hpp^| & F  | & FL^`L Hza_CEƀf & FCEƀfN & F hh^h` >z?zlzzP}Y~0}$$$1$Ifa$$1$CEƀf..`LUUUUUGG$$$1$Ifa$ $$1$If$$IfTl4ֈ-&_,v<B5+644 laMBBBBB $$1$If$$IfTl4֞-&_#,v<5+644 la$$$1$Ifa$'$$$1$Ifa$$$IfTl4 -&_#',v<5+6$$$$44 la,Hm$$$1$Ifa$94.... $$1$If$$IfTl4ֈ-&R,iIB <5+644 la+H$$IfTl4ֈ-&R,iIB <5+644 la$$$1$Ifa$рڀ$$$1$Ifa$ $$1$If9X.... $$1$If$$IfTl4ֈ-&R,iIB <5+644 la+$$IfTl4ֈ-&R,iIB <5+644 la$$$1$Ifa$ $%&3QRSǁ߁ GHI‚Ȃɂʂׂx~у҃)4OfirsCJOJ QJ ^J B*^JaJph6]5KH\^JaJ j0JvU6CJPJ]^JaJnHtHCJPJ^JaJnHtHCJOJPJQJaJnHtHD $%&'()39EQRSTj~ܘFfFf/$$$1$Ifa$ $$1$Ifǁ́Ӂف߁ ܸFfO Ff. $$1$IfFf $$$1$Ifa$"/;GHIeFfp $$$1$Ifa$ $$1$If9X.... $$1$If$$IfTl4ֈ-&R,iIB <5+644 la‚Ȃɂ+$$IfTl4ֈ-&R,iIB <5+644 la$$$1$Ifa$ɂʂ˂ׂ݂̂͂Bfsx~܈FfFf$$$1$Ifa$ $$1$If~9.... $$1$If$$IfTl4ֈ-&R,iIB <5+644 laƃȃу҃Lq{$$IfTl4F-,ZB 5+6    44 laFfo$$$1$Ifa$ _ń}6FC & F<Eƀf. & F{$$IfTl4F-,ZB ̙5+6    44 lańhq*FC & F<Eƀf.FC & F<Eƀf.FC & F<Eƀf.hq*%C & FFC & F<Eƀf.FC & F<Eƀf.FC & F<Eƀf.ÆLsFC & F<Eƀf.CEƀf..iӊq*FC & F<Eƀf .FC & F<Eƀf .FC & F<Eƀf .ӊ8m~sqCEƀf.FC & F<Eƀf .~Q)3oK & F27$8$EƀfH$CEƀf..3Us  iggggK & F27$8$EƀfH$K & F27$8$EƀfH$ Ϟܞ"#VaʢXaivҲ޲޳j0Jv<UjHhf0Jv<U 5mH sH  mHnHu jUmH sH jHhf0Jv<UjHhf0Jv<U Hhf cHdhf6]6j0Jv5OJQJU\^JCJOJ QJ ^J j0JvU. Qs,F & F=EƀfF & F=EƀfCEƀf..*Esq*F & F=EƀfoF & F=EƀfF & F=Eƀfosq*F & F=EƀfF & F=EƀfoF & F=Eƀfo@q*F & F=EƀfoF & F=EƀfoF & F=Eƀfoҗ qooF & F=EƀfoF & F=EƀfȘ+gquCEƀf.CEƀf.q;ܞaݠuCEƀf..CEƀf..ݠdW=qF & F:EƀfCEƀf..=sAuCEƀf..CEƀf... %¬58[qoommmmF & F2EƀfF & F2Eƀf'vҲwuCEƀfCEƀf..Ҳ޲޳9w$$Ifl0,"LL t0644 la$If$CEƀf.xAB  $ P8@w$$Ifl0,"LL t0644 la$If}~ |zz & Fw$$Ifl0,"LL t0644 la$IfƼǼȼʽ˽̽  mſ:AI 5H)\T񸾩񸾩y0jHhf0Jv<OJQJUmH nH uCJaJmHnHsH 5CJaJmHnHsH B*CJaJmHnHphsH  5mH sH B* CJaJmHnHphsH j0Jv5U\^Jj UmH sH jUmH sH mH sH jUmH sH /mn=ſƿ:A[opCEƀf.I5\.Ho)B\pTVXq*gp`p~!'(?@ABCDh7AVWnop믜yjUmHnHujHhf0Jv<UjUmH sH $jCJOJQJUaJmHnHujUmH sH 5OJQJmH sH 56mH sH 5CJaJmHnHsH B*CJaJmHnHphsH  5mH sH mH sH B* CJaJmHnHphsH /9v!H\q'Dh^hpDhlmqH & FEƀf.CEƀf.mm$H & FEƀf.H & FEƀf.H & FEƀf.67ABTUsthiCEƀf.pqr})r~ݸ褕z5CJaJmHnHsH B*CJaJmHnHphsH B* CJaJmHnHphsH CJaJmHnHsH j0Jv<UjUmH sH j:UmH sH 5OJQJmH sH jUmH sH jUmHnHumH sH jUmH sH jUmH sH +i m$H & FEƀf)H & FEƀf)H & FEƀf) hiXeH & FEƀf.^H & FEƀf)X|}mkkkkkkkkkkH & FEƀf.H & FEƀf. !:r67ABep7Hef}~"#<=>?@    ,@AXYZ[\vвЩРj0Jv<U j0JvUjUmH sH jUmH sH jgUmH sH jUmH sH jZUmH sH jUmHnHujUmH sH 5OJQJmH sH mH sH CJOJQJaJmH sH 8DE56 \]CEƀf. m$H & FEƀf.H & FEƀf.H & FEƀf.OP?@]uv<CEƀf.^_wCEƀf.CEƀf. ^()@BCDEF]_`abcz|}~    NOKQ}=>1#7#:$g$v$w$$$%%')aJj0Jv5OJQJU\^Jj0JvPJU j7U jU jU jU j0JvUmH sH j0Jv<UJ)Qm$H & FEƀf.H & FEƀf.H & FEƀf.^kH & FEƀf.H & FEƀf.+,qCEƀf .H & FEƀf.(EwuCEƀfCEƀf .. `wuup| & FCEƀf.CEƀf.Aq*F| & F>EƀfF| & F>EƀfF| & F>EƀfA@n e  hF| & F>EƀfF| & F>Eƀf | & F^   > Yull | & Fh^hCEƀfCEƀf..3NPypp-C|Eƀf | & Fh^hC|EƀfC|Eƀf)y6C|EƀfC|EƀfC|Eƀf)e y6C|Eƀf C|EƀfC|EƀfGHTlypp-C|Eƀf# | & Fh^hC|Eƀf"C|Eƀf!l ytrps| & FC|Eƀf%C|Eƀf$)Yl!uC|Eƀf&CEƀf..!GcC|Eƀf( | & Fh^h` | & F^C|Eƀf'4KQgyw4C|Eƀf+C|Eƀf*C|Eƀf)g}yw4C|Eƀf.C|Eƀf-C|Eƀf,wy6) | & FL^`LC|Eƀf1C|Eƀf0C|Eƀf/lH[uC|Eƀf2CEƀf.. ?y6C~EƀfC~EƀfC|Eƀf3?!yw4C|Eƀf5sC~EƀfC|Eƀf4!L""#y6C|Eƀf8C|Eƀf7C|Eƀf6#1#7##$w4C|Eƀf;C|Eƀf:C|Eƀf9$$$:$w$%yw4C|Eƀf>C|Eƀf=C|Eƀf<%`%%D&y6C|Eƀf?C~EƀfC~EƀfD&Y&&'y6C|EƀfAC|Eƀf@C~Eƀf'''''y6- | & Fh^hC|EƀfDC|EƀfCC|EƀfB' (*+ + +!+%+qCEƀf.F & F5Eƀf)**+--*9+9::~;;s=t===========>> >!>4>9>:>@>A>C>D>H>I>S>T>W>Z>[>>>>>>>>> ? ???%?&?,?-?.?/?3?4?>???ǿǰ0JcHdhfmHnHuHhf0JmHnHu0JmHnHu j0JU0J mHnHu jU j0JjU j0JvUaJHhfaJaJcHdhf?%+G++Z,,s,F & F3EƀfF & F3EƀfCEƀf..,--x/00~111qooooomF & F3EƀfF & F3Eƀf11222222G3`^CEƀf.. &dP$ & FF & F4EƀfG3O3Z3a3q*F & F1EƀfF & F1EƀfF & F1Eƀfa3m3v33q*F & F1Eƀf F & F1Eƀf F & F1Eƀf3333q*F & F1Eƀf F & F1Eƀf F & F1Eƀf 33|445sCEƀf..F & F1Eƀf55A667q*(F & F3EƀfF & F3EƀfF & F3Eƀf78*9:~;s=============">#>\>]>t>>>>G?H?$a$ 1??B?E?F?W?X?b?c?u?v?~???????????????AAAABBBBRCSCDDaEbEFF1G2GHH)H*H+HH?HHHOI*$a$OII_JJ KKKLLL MMiN!OROOgPP+QQxRS-TT+UqVV W2WyW*JJJJJJJK K!KLL M!M7M9M:M;MsMMMMMMMMMN#NhNiNjN|se|^|^RjHhfU HhfjHhf0JvUHhf0Jv HhfjHhfU Hhf HhfjHhf0JvUHhf0Jv HhfjHhfU j0JvU Hhf HhfjHhf0JvUjHhfUHhf0JvjNNNNNNNNNNNOO O!O"OROSOOOOOOOOP2PfPgPhP~PPzsl`YPHhĢf0Jv HhĢfjHhĢfU Hhf Hhf HhfjHhf0JvUHhf0Jv HhfjHhfU j0JvU Hhf Hhf Hhf Hhf HhfjHhf0JvUjHhfUHhf0Jv HhfPPPPPP+Q,QBQDQEQFQuQxQQQQQQQQQRvRwRxRyRSS)Sż̮ŧvohaUN HhѢfjHhѢfU HhϢf Hh͢f Hh̢fjHhˢf0JvUHhˢf0Jv HhˢfjHhˢfU Hhɢf HhȢfjHhǢf0JvUHhǢf0Jv HhǢfjHhǢfU j0JvU HhĢfjHhĢf0JvUjHhĢfU)S+S,S-S2S@SIS}SSS,T-T.TDTFTGTHTmTTTTTTTTTTT*U+U|ul|^uWuW HhۢfjHhڢf0JvUHhڢf0Jv HhڢfjHhڢfU HhآfjHhעf0JvUHhעf0Jv HhעfjHhעfU Hh֢f Hhբf HhԢf HhӢf HhҢfjHhѢf0JvUjHhѢfUHhѢf0Jv+U,UBUDUEUFUzUUUUUUUUUUUVUVpVqVrVVV W W2W3WyWzWWWWWWWWWWXXBYCYYYvjHh fUjHh㢶f0JvUHh㢶f0Jv Hh㢶fjHh㢶fU j0JvU Hhᢶf Hhࢶf Hhߢf Hhޢf HhݢfjHhܢf0JvUHhܢf0Jv HhܢfjHhܢfU,yWWWXDXEXXYYBYY[=\p\q\ ] ]^]#^D^E^^^^^R_S___ 7$8$H$*YYYYZQZZZfZmZzZZZZZZZ[w[[[[[[=\>\^]_]#^$^^^P_```aaAaBaMbNbb|i%B*CJOJ PJQJ ^J nHphtH%B*OJPJQJ^JaJnHphtH j0JvU Hh)f Hh&f Hh%f Hh(f Hh'f Hh$f Hh#f Hh"f Hh!fjHh f0JvUjHh fUHh f0Jv Hh f)_``aAaMbbbPc}ccSd=e>e|eeffffgyhhhii:i;ii* 7$8$H$bbbbPcQc}c~cccSdTd|e}eeeggyhzhiiiijjhjijjj(l)lsmtmummnnnoooApBpLpppqqqqkqlqmqrrrrrrrrGsHsssss%t'5B*OJPJQJ\^JnHphtH%B*CJOJ PJQJ ^J nHphtH%B*OJPJQJ^JaJnHphtH!B*OJPJQJ^JnHphtH j0JvUDiijhjjkk'l(ltmvmmmmmnop pApppqdqeqlqrr 7$8$H$u$a$*rrrGssss$t%ttuuvvowpww$xxxzzz{{{{8| 7$8$H$s*%t&tttpwqwww$x%xxzzzzzz{{||?}@}/0|}78 ,-MNӃԃ)*GH78()jHhfUaJ%B*CJOJ PJQJ ^J nHphtH%B*OJPJQJ^JaJnHphtH j0JvUJ8|9||||?}~~kl/|~Ӂԁ7 ,MӃ*Ӄ)IG^_‡Ç7/0(H‹Ë M{*  6GHI  MNdfgh{Ԍ*+$%NOeghi||s|ejHhf0JvUHhf0JvjHhfU Hhf Hhf HhfjHhf0JvUHhf0Jv HhfjHhfU j0JvU HhfjHhf0JvUjHhfUHhf0Jv Hhf%*$Nҏ 9-1$(I4&!"?*|ҏӏ 9:-.$%IJ”45&'?@כ؛LMНѝ iklm]^ƳƳƳ%B*CJOJ PJQJ ^J nHphtH%B*OJPJQJ^JaJnHphtH+5B*OJPJQJ\^JaJnHphtH j0JvU Hhf Hhf Hhf Hhf?()כٛ!"LНhikl 7$8$H$*"#]~ΤϤ̥ͥ#*C$ 7$8$H$*^̤ΤϤФ&()*AsǦȦ˧Чѧmnde{}~ƿƨwHh f0Jv Hh fjHh fU Hh f Hh f HhfjHhf0JvUHhf0Jv HhfjHhfU%B*CJOJ PJQJ ^J nHphtH%B*OJPJQJ^JaJnHphtH j0JvU)#mdJ ussssssqqqq*D*C$Eƀ fD*C$Eƀ f ~ߩFtIJKbcjk    OUykjHhf0JvUHhf0JvjHhfU HhfjHhf0JvUHhf0Jv HhfjHhfUCJOJ QJ ^J j0JvU Hhf Hhf Hhf Hh f Hh fjHh f0JvU*ab˱̱j#ʹ./yܵQ29E*ϳ"#$:<=>gi̴ʹδyzܵݵQR·طڷ۷ܷ,./023EF)* HhfjHhf0JvUHhf0Jv HhfjHhfU j0JvU HhHf HhfjHhf0JvUHhf0Jv HhfjHhfU Hhf Hhf1cdӽԽ'()JuUVn !M 7$8$H$^*JKuvno !MN,-cd\]&'\abefjk|}01459:OJ QJ aJmH sH mH sH  j0JvU B*CJOJ QJ \^JaJphCJOJ QJ aJR)*,c\&,-mn !"*"#$%&'()*+,-./0123456789:;<=>??@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\abefjk|}01459:"#'$a$!"#'(UVYZqrvw  #$78LM^_^JaJmH sH  aJmH sH mH sH B*OJ QJ aJmH phsH OJ QJ aJmH sH R'(UVYZqrvw$a$  #$78LM^_1267;<nor$a$1267;<norsvwUVYZ^_rsvwz{~/03489DEKLno ^JmH sH ^JaJmH sH _rsvw#UUVYZ^_rsvwz{~/03489KLLnoy%&9:HILM%&9:HILMQRefz{$%)/04ABFTUYfgkqrv5CJaJmH sH 5CJOJ QJ aJmH sH CJaJmH sH CJOJ QJ aJmH sH  CJ^JaJCJ^JaJmH sH ^JaJmH sH HMQRefz{$%/07ABITU\fgqry  *+2<=DNOYZ *+/<=ANOSYZ^klp}~  !./3@AEK jUCJaJmH sH CJOJ QJ aJmH sH 5CJaJmH sH 5CJOJ QJ aJmH sH MZakls}~   $./6@AKLMNOPQRSTUVWXYZ[\]]^_`abcdefghijklmnopqrstuvwxyzz{|}~     P jU jUjvDI UVaJ  !"#$%&'()**+,-./0123456789:;<=>?@ABCDEFGGHIJKLMNOP & 00P/ =!"#$%#0P/ =!"#$%`!#dK{jo{: `ER4#x՝ | g<3̙D%UV۵U=چuՐ . EW.t{AR hi( RZ3a9uΜ~<3gI}>>sk~XN8笼r:g5~d}sAHq횯Ǜtş]}.qcΠ-3^ZMÞ=/9^\EUEF[ws{?wcYJj7}Yjڠ^r8}qadz{$:@q9N8NI,B3{4}3b>DYzxU(^S?4&bkO4 i@lr!΅LsEEOJc{C|^J+=0ŏ=tFN>*V>~T6$ qp t쟐#|gY: ;=ԆVЂޛASh&Ѧ15Fh횢asl4n bk| 1G=J:Jo}9fCY!ZzCe,guOI E{Yq7.,?Ws( RgQC 3! %v,=T{0Bک´ N`a>6$ @8zO?sՀpsWIMII͑^uTjD- _>l;O!_sC8DC܅q3>vSOkX{wHж98uRra]*;CU_wJ<8Q?H -,Z(tΡ9;Q`|3a" fë:9-|3eXx;?4 0h|Ӏh zB0^k8J|2'h MׄkBIh~Z"C hs?Gl[][z] ;6zC=Zo- ab9(zBzR?9eTI'&tV߃9}׫0_Νg`7?zWP,RȆ |c9)b-ҟ1g}.|w=C=M]s}Ɯ2԰zB>=Y&-ob2#gARnH6HF=1FwmM X 90<|7MF^l2j@MѨ-67Ҹ]eܦ6c?㌺Ȁm cw1d4dX`r#3*J1"|F;Ģ28Nʞso]:kk|yGzMy kڲ~ב5[AOs O"Ml $YeKV3Fyduiy]:܄ombj[5SO/eSwWΗ;{ QS6Ƣ[Ԗwd#@]OC7g>"7Icp NSib{gu]sgcpzBDYvT?p{q̻3K~;=#mP˗۵PQvvVܩ0?jji/mքE-i,juf]Q PEU7=-odMN=zGCsuΣOg Ĭ#va3[a;cߝJc}9dx ь'ļ@pr 7zBWxǵ\+@djL~1۴^4A8Va >1qĶOpxʵ~ݶZA rl,|$:1XAMw z>F+)9-Wζ)B?zN.` pOM>ۇm}q83D99 vl{ǧ 999k/sa]8vY~~>WR{+\ʼW2W=\ Pge'|3*ˆn26"f$H7zB.5ZKWˬG~h$mzX/*͞CU0:|؍F?Ho4 #Ϳxο5W Ȁ26EHbɑn8z=#,g=\zR? V޳a Z,BfG={ ChmGEhͳ~9,7K!`,+u*;ȱU2`ȵ]J2bX`g{^j~`/fE+{ a؆06T|3`:zOx{{OUUϺ>IÌQyc 6,_0tce /-gl%>9&f kѰ 6l2~L'~BO 9?&N\26ũ'U{;QS~/賃6@FWVIKV=eLdnNu|#qbKydC~Mab0krbB:Ȝ̽@MY)_^9J}TdLrLkd\+u^` gL3nHiI |e,|s8@Og̹'ovO&{9NНAyIk86:MeXǵ$ m#cقVb v۬bGlV?/ &$lgGXrz9ePl`E3ot>42PhJMC(7P} }eo[p}UAlU7Z<ȅ0 D2xb)=f,V;'|wsZY3hB1t܈ΣQ!J4D;QNjR Q,` J6Af(q83Yb~$GrHy?0*bΓ}SO;tuw5~k89;U.Gcp1ΪodL֭$ m#cقVb݊bf|V໒UĮ"*r"Jr`+92"jXN=Mlz=?()BlR~js!.5 P%uQ)QA,DC{f 6#)XֿFȳ>0I0 |&;qĎ%XhH?g+>%9w}P1 T2Z9 3[~se4'Z9 &C.af|໕mn* oa{wb ɵ =9e-K s'Կm6Ji_3Ț^C߻st =>EOSt>EO3t=w݋6kZimrjkʃ\ Md, 'fc1*摞'LDw+)Z'8 |ߢ7(sa;rQJ~ߢw(|O)nmV5l7Zi<ȅ0 D2xb;c-PMlwz!|įRL: /Kt<'_Q"E2P&2P(6&K(2NEL[wCc{j5X-VjeA.LI&2|3XE'粲ShӒRm {73cզlQ_+RЦZ(H%yL)HmWLG}Ir$Ic1i^Vdr,28fyϴ_g}VVA#}sw_mZ;"Khv=_S#ʻGfђck%vo+YZJ> c{܈QG] FbWmAE{J^ފW[3tꞐ.O|S"œ(aw) Rj9t{nO{ݞQV$r,:rLt%Jo+YZ[tzF(HpNC).foG9wJ,RsLe+ R8,3Ka"bEu7w8J,+_J?VrO{(x^xn)pVx&{_E$TbNg,+\ux<~Vj!Xi}oFiEE>@?(鑮*P@w W `xJ+x+6vIWCЁM'v WDB( ;oGH8#+v)^ ފu si9aD_>Gz]b%iuF xv>o1㷮w#ĵWu-V43O*uvawZ2t뢤nZ+vSN:qG+p5.^2XH͡5.[K^}k·+[ TH5<`sk 8@ -NNcw/`V/=~w*5+^ZWxx5uia=%[XO˖ч1֓P$A,6,Pu+]MȽ{D|㷪\|i`'֓fK)I'>'̾\j99D|^=\)ux;j$ŃVE;ՖCvX+VWŊVw`;Wm;)[S)UiϊL\^Vd)Oѧ^8q#Saxc8tX|\2]/%&aC+,ߺ*j|o$S#S4hfLS47z)E"X1=)4QӘ)B~BSLT l׺f|qG?5)+di=әi:UMup iDNbzx]5QLn6Ý%Ktc,JJkҩnؘ&M$(fL=M ME)t;};WF4c2ǹ&C[JcO;͐B* S1ŀA.2cGO|]#'+.3r.,)gz;~3+f`؁}vيk䍔9)+\#1k$}㱚=2(r< U1U %.i,!k$5\#5'49] 1Q{]^X-RFU?(rUY-K#LYtv4Nn+XA܇{m:wlVx+[ZW&KֳdQ㱚RxurNwɗE{v Kl3S=~*ާTU&*^ .WY7yL)gԇzOdڥ"K<}1#\pk,]r}ft$ڻ5{2^ސ[} K^W ҟb| AJo+YZd9FdRsXي*8ؾR,K/a| ~\9b4c.<ܹ]֚Nw9t%Jo%y[̮0ZVїRƞmΆW9dawYk"R,5G*kk.e֜|k=]ɲ[J^`d:Qeϓ7b.'79ι cc.t](}&DžYVx+5.&}62?E (f3a]fËK;wlIw7?ds=~*j K)glmv23Act XjW,SPAXǵ>+ƒk whIۘ'As\7kbxx |ȦЄ&4ܱfask[@>x1@6Xi}3Onc+\'y| '=N1v 9Na7l?UοX(g̔39.Vs{'<r. 5\M7#M["$`e] lluOz).S`w l,,oƷV,tQEv#v8a(Z2֒ r 8V;gQ#лd()^k + 8U5[wCz`sH`|^aVeS!Ч`Xk hlGŒQ4cw.K#K:CshõEA$.wUhRb,ϱGFYd/WR@QUǧ&6n?hVR/F~׶|2Dd0V  3 C"((Dd0V  3 C"((}DyK _Toc165626304}DyK _Toc165626304}DyK _Toc165626305}DyK _Toc165626305}DyK _Toc165626306}DyK _Toc165626306}DyK _Toc165626307}DyK _Toc165626307}DyK _Toc165626308}DyK _Toc165626308}DyK _Toc165626309}DyK _Toc165626309}DyK _Toc165626310}DyK _Toc165626310}DyK _Toc165626311}DyK _Toc165626311}DyK _Toc165626312}DyK _Toc165626312}DyK _Toc165626313}DyK _Toc165626313}DyK _Toc165626314}DyK _Toc165626314}DyK _Toc165626315}DyK _Toc165626315}DyK _Toc165626316}DyK _Toc165626316}DyK _Toc165626317}DyK _Toc165626317}DyK _Toc165626318}DyK _Toc165626318}DyK _Toc165626319}DyK _Toc165626319}DyK _Toc165626320}DyK _Toc165626320}DyK _Toc165626321}DyK _Toc165626321}DyK _Toc165626322}DyK _Toc165626322}DyK _Toc165626323}DyK _Toc165626323}DyK _Toc165626361}DyK _Toc165626361}DyK _Toc165626362}DyK _Toc165626362}DyK _Toc165626363}DyK _Toc165626363}DyK _Toc165626364}DyK _Toc165626364}DyK _Toc165626365}DyK _Toc165626365}DyK _Toc165626366}DyK _Toc165626366}DyK _Toc165626367}DyK _Toc165626367}DyK _Toc165626368}DyK _Toc165626368}DyK _Toc165626369}DyK _Toc165626369}DyK _Toc165626370}DyK _Toc165626370}DyK _Toc165626371}DyK _Toc165626371}DyK _Toc165626372}DyK _Toc165626372}DyK _Toc165626373}DyK _Toc165626373}DyK _Toc165626374}DyK _Toc165626374}DyK _Toc165626375}DyK _Toc165626375}DyK _Toc165626376}DyK _Toc165626376}DyK _Toc165626377}DyK _Toc165626377}DyK _Toc165626378}DyK _Toc165626378}DyK _Toc165626379}DyK _Toc165626379}DyK _Toc165626380}DyK _Toc165626380}DyK _Toc165626381}DyK _Toc165626381}DyK _Toc165626382}DyK _Toc165626382}DyK _Toc165626383}DyK _Toc165626383}DyK _Toc165626384}DyK _Toc165626384}DyK _Toc165626385}DyK _Toc165626385}DyK _Toc165626386}DyK _Toc165626386}DyK _Toc165626387}DyK _Toc165626387}DyK _Toc165626388}DyK _Toc165626388}DyK _Toc165626389}DyK _Toc165626389}DyK _Toc165626390}DyK _Toc165626390}DyK _Toc165626391}DyK _Toc165626391}DyK _Toc165626392}DyK _Toc165626392}DyK _Toc165626393}DyK _Toc165626393}DyK _Toc165626394}DyK _Toc165626394}DyK _Toc165626395}DyK _Toc165626395}DyK _Toc165626396}DyK _Toc165626396}DyK _Toc165626397}DyK _Toc165626397}DyK _Toc165626398}DyK _Toc165626398}DyK _Toc165626399}DyK _Toc165626399}DyK _Toc165626400}DyK _Toc165626400}DyK _Toc165626401}DyK _Toc165626401}DyK _Toc165626402}DyK _Toc165626402}DyK _Toc165626403}DyK _Toc165626403}DyK _Toc165626404}DyK _Toc165626404}DyK _Toc165626405}DyK _Toc165626405}DyK _Toc165626406}DyK _Toc165626406}DyK _Toc165626407}DyK _Toc165626407}DyK _Toc165626408}DyK _Toc165626408}DyK _Toc165626409}DyK _Toc165626409}DyK _Toc165626410}DyK _Toc165626410}DyK _Toc165626411}DyK _Toc165626411}DyK _Toc165626412}DyK _Toc165626412}DyK _Toc165626413}DyK _Toc165626413}DyK _Toc165626414}DyK _Toc165626414}DyK _Toc165626415}DyK _Toc165626415}DyK _Toc165626416}DyK _Toc165626416}DyK _Toc165626417}DyK _Toc165626417}DyK _Toc165626418}DyK _Toc165626418}DyK _Toc165626419}DyK _Toc165626419}DyK _Toc165626420}DyK _Toc165626420}DyK _Toc165626421}DyK _Toc165626421}DyK _Toc165626422}DyK _Toc165626422}DyK _Toc165626423}DyK _Toc165626423}DyK _Toc165626424}DyK _Toc165626424}DyK _Toc165626425}DyK _Toc165626425}DyK _Toc165626426}DyK _Toc165626426}DyK _Toc165626427}DyK _Toc165626427}DyK _Toc165626428}DyK _Toc165626428}DyK _Toc165626429}DyK _Toc165626429}DyK _Toc165626430}DyK _Toc165626430}DyK _Toc165626431}DyK _Toc165626431}DyK _Toc165626432}DyK _Toc165626432}DyK _Toc165626433}DyK _Toc165626433}DyK _Toc165626434}DyK _Toc165626434}DyK _Toc165626435}DyK _Toc165626435}DyK _Toc165626436}DyK _Toc165626436}DyK _Toc165626437}DyK _Toc165626437}DyK _Toc165626438}DyK _Toc165626438}DyK _Toc165626439}DyK _Toc165626439}DyK _Toc165626440}DyK _Toc165626440}DyK _Toc165626441}DyK _Toc165626441}DyK _Toc165626442}DyK _Toc165626442}DyK _Toc165626443}DyK _Toc165626443}DyK _Toc165626444}DyK _Toc165626444}DyK _Toc165626445}DyK _Toc165626445}DyK _Toc165626446}DyK _Toc165626446}DyK _Toc165626447}DyK _Toc165626447}DyK _Toc165626448}DyK _Toc165626448}DyK _Toc165626449}DyK _Toc165626449}DyK _Toc165626450}DyK _Toc165626450}DyK _Toc165626451}DyK _Toc165626451}DyK _Toc165626452}DyK _Toc165626452}DyK _Toc165626453}DyK _Toc165626453}DyK _Toc165626454}DyK _Toc165626454}DyK _Toc165626455}DyK _Toc165626455}DyK _Toc165626456}DyK _Toc165626456}DyK _Toc165626457}DyK _Toc165626457}DyK _Toc165626458}DyK _Toc165626458}DyK _Toc165626459}DyK _Toc165626459}DyK _Toc165626460}DyK _Toc165626460}DyK _Toc165626461}DyK _Toc165626461}DyK _Toc165626462}DyK _Toc165626462}DyK _Toc165626463}DyK _Toc165626463}DyK _Toc165626464}DyK _Toc165626464}DyK _Toc165626465}DyK _Toc165626465}DyK _Toc165626466}DyK _Toc165626466}DyK _Toc165626467}DyK _Toc165626467}DyK _Toc165626468}DyK _Toc165626468}DyK _Toc165626469}DyK _Toc165626469}DyK _Toc165626470}DyK _Toc165626470}DyK _Toc165626471}DyK _Toc165626471}DyK _Toc165626472}DyK _Toc165626472}DyK _Toc165626473}DyK _Toc165626473}DyK _Toc165626474}DyK _Toc165626474}DyK _Toc165626475}DyK _Toc165626475}DyK _Toc165626476}DyK _Toc165626476}DyK _Toc165626477}DyK _Toc165626477}DyK _Toc165626478}DyK _Toc165626478}DyK _Toc165626479}DyK _Toc165626479}DyK _Toc165626480}DyK _Toc165626480}DyK _Toc165626481}DyK _Toc165626481}DyK _Toc165626482}DyK _Toc165626482}DyK _Toc165626483}DyK _Toc165626483}DyK _Toc165626484}DyK _Toc165626484}DyK _Toc165626485}DyK _Toc165626485}DyK _Toc165626486}DyK _Toc165626486}DyK _Toc165626487}DyK _Toc165626487}DyK _Toc165626488}DyK _Toc165626488}DyK _Toc165626489}DyK _Toc165626489}DyK _Toc165626490}DyK _Toc165626490}DyK _Toc165626491}DyK _Toc165626491}DyK _Toc165626492}DyK _Toc165626492}DyK _Toc165626493}DyK _Toc165626493}DyK _Toc165626494}DyK _Toc165626494}DyK _Toc165626495}DyK _Toc165626495}DyK _Toc165626496}DyK _Toc165626496}DyK _Toc165626497}DyK _Toc165626497}DyK _Toc165626498}DyK _Toc165626498}DyK _Toc165626499}DyK _Toc165626499}DyK _Toc165626500}DyK _Toc165626500}DyK _Toc165626501}DyK _Toc165626501}DyK _Toc165626502}DyK _Toc165626502}DyK _Toc165626503}DyK _Toc165626503}DyK _Toc165626504}DyK _Toc165626504}DyK _Toc165626505}DyK _Toc165626505}DyK _Toc165626506}DyK _Toc165626506}DyK _Toc165626507}DyK _Toc165626507}DyK _Toc165626508}DyK _Toc165626508}DyK _Toc165626509}DyK _Toc165626509}DyK _Toc165626510}DyK _Toc165626510}DyK _Toc165626511}DyK _Toc165626511}DyK _Toc165626512}DyK _Toc165626512}DyK _Toc165626513}DyK _Toc165626513}DyK _Toc165626514}DyK _Toc165626514}DyK _Toc165626515}DyK _Toc165626515}DyK _Toc165626516}DyK _Toc165626516}DyK _Toc165626517}DyK _Toc165626517}DyK _Toc165626518}DyK _Toc165626518}DyK _Toc165626519}DyK _Toc165626519}DyK _Toc165626520}DyK _Toc165626520}DyK _Toc165626521}DyK _Toc165626521}DyK _Toc165626522}DyK _Toc165626522}DyK _Toc165626523}DyK _Toc165626523}DyK _Toc165626524}DyK _Toc165626524}DyK _Toc165626525}DyK _Toc165626525}DyK _Toc165626526}DyK _Toc165626526}DyK _Toc165626527}DyK _Toc165626527}DyK _Toc165626528}DyK _Toc1656265289DyK  yK http://www.oasis-open.org/committees/download.php/4952/wd-entity-xml-catalogs-1.0_2e.htmlrfc2119)'Dd +0  # A"&7%KЭ4I8C&@=y&7%KЭ4I8C4 EHG4G&x] |E֯LrL.‘cL#T$2GȄ.K$/ .fY G>%a9\DtuEU_әd2=huWWϫW_)Bpc4BH֥ ꗍH U_PB?B7QT77^DduT( ΛlI;P$P8lhE籐w3(4W#SNnywoH/tx ?a?oh@\SťQܕ"+#I]Pu91e(!|Rv2hfoFC@2D{:l֏c$urR"&QHVg {l _IB];E?7N>nNt{Ϫ+}`@J 'ldAɶk6-iBu.n -\QV e=<#Ō!f-6ceV ( ÝnW;.ŵ>WjLsQc5OaF)fT*=+#w[f0aBmB13QQ;l90 l25sh>3~Z\hDqQZ~ Zj 1hx\e,Uu\$xp'.= ~!.$EZ<.q!). D rڥ5ECt8i#6-emҶ1;=oDŽPA#аƱ{l)UDp@WCq>{8h`>c3P!/f9_=M#%$Cz8#O@U;%׹1;~ uJ#':%~Ѻ/JBiݡf3o/R }Pc &3]DtN nn궟 !N!21IߥUN%=F)vq!8h8f<.J`(ki8'Ap$tl.= nal@Ơ? rO%t(h:rZ:i.!-BݬA4I] B𗃕`zEUx?J`N"bdM q2g B[N~g~SORB?=ܛTW Mj -D$O_"^o-sR-xoeǑ2 )h7!*t3V14:@]T2ߚ3 M;ο-? *gMq(/G>j.>j!jئ4_ 65^j2K]95كڬ?Ns覚Ʀa H?6Cz΀KWpKy$Cl/g9bY9RIT2 ->[ʵ cfW}\X}"X_]qq<&beh4cbǍۚ`Cn\(@ok_ͦR:ݧ욋^馶1^\7x[_k-Jٵ<P7*صnZ'2rR|\uSqxIiuO0)DC{dB^wJ覍OO9&gzhƵ"X:1ALu>h6Ѝ֘㙵yLu82WE@f*W]CUR"A\$z9v\$H!.~BRUż.$E8ER=.d H.Rx\q!.~e퐵 wWQ:m9ZY궅T(cÓ9_F9# B~9V|7O^t^iQRhkGtxܦab2".%T773G2x̤p,L2n7B"Fl' p,%y\t!.x7Tj8[ e{9``QI=G9>ОP7E!%=UsLs >Itgiy/M;K?8w^Fo;矍&;? /팦NˣNᐽԚSwe4Sx7ȿ¶_~2: "Tb*jӌJx?zx㢎Qi{M%k4Gp&/6e9#gGGGΎGNQԳq Ͻo_pth+-[ۃ48D^;[Kxk1ZtAf--Ch!|]-u0n@K0lp{䣑Tҩ} | {y^|H¦Hjg4d?. 8ݏFRn O3<1%{pΧTo8Punxjۻ[Tݸ00W|< 8C;tFRǷ^ԍ#{0N`x} .|͇߁u]#( ;~gv`h2.z8E{j.O &.j] Ͻopv8k+~}r8u4bVpjꐭ8p*6n_8XEò1?x̍pv!QGlkf0jRfo/FmƇ.v،ʰp8r3.~*p2zcpj`^9O ܖb5+`ՅQ&aWƗ᜞aԴ2<=/pױ 7):Х Q'7>F/m +¨ paԭpy Ͻ)TC^lK =al8ю{ڰl23`y5/f0> B{gs'f4;6#:w|F)\&37y~a1#;n3R&^  BZ|ߞ:u[Ofy7}@OZ>Lyp[6w,7,3Y2E[M9t|Cw 5p%,O+=G2,y-߲LDK@X;ʗyэ|K>Bfi;Xy 7y oyU`YdYO܌4|?2u2Ld62M;dN;&eOiiߙO]`|@vFz뼇2Nk.Nd~.y3SGTОnƛ9́gρvl6`BɞϬmɮH~B6@n6]a߳Kxz)P9U&."Łm} MP&C\akšM ࢇ@qѣ2ąB\(= Džd8 U0 HrT>U5ݾ GغuF|7gkX`P!/f)6ЖCj/}kV>HrMX B~W눗ͱo$L/1v$c>m$nk$ݘw{$9*TR$5.WS r5[ߟkE{FںoR>}υ7x&ОXSu7aWTy~\#Q} qBs@U}w:(@£$OT$vrz3F9O/åea.:iZ.a6T~o4 e[gFS0@"UտC#^'6N"f-g ڔgl8x+aq[㬄܄@c3UULN'l0~ٺ_8(8?,<ChH[?PtTmLwӔtk-ytE=j 6ER/rNMNjy"udNjjC(pPb HL' \{:d"Gb\NJqZ͋Hw0H?vss,~78KA B`C=Dy2|a;~H{}#', X~53|0fX3kwpWo|޷lR/T- g-KŘ!U1C _%3,!ؠ=_Wu@cq6f0fi dihܵڎ&w1;>dN0Ɍc.ޯjƱt;/w?&IJ?O"& G8pSA~iY v %{ȅ硬 Wo < ʓ/->~{*~0?jgOR>ОC=3wҙ $ZПPudc.9]H۰} (X9tYP2c"HauqH˦k'Hy^ik3Waۙ\iU-z'`1z%.;w^\cpbFN?Z_ť{oJ0: XLxEC~kA%ew}Kz9=DӸC$Mҝ}H:~x:9Ei{# E0{۸naw?N{,qUwl>܋AK- Ohv 6\p/Jp/z\\aa<.Bt@s#(e۰ HrJvLrsHVu+V55'B-"lY1ZH?L9ګXra1 }‗#M>wU:KWyߤO"cOIҍyϳ1/|cl`j0ck8Qq~5]+B0ϱ/W׽|R%bo#0=Zr#3tuȾ_)w5 H dtrڳ,ePxz%=+E|]u8B~Ș{\Hw+\XLJC[*fL U&ƃ # #Y Z_{/Ⱥ*ƇGp/A|m@ږ6xg^+Y-O?Lr08 Tȋr9S=G$Q[c$^w$?HFi9GwT77:1t_c&Y~ߜaoEt pxT)2E]jԌڷjە ?HORWϑ{??Gl,}S6ߛزbguzo&KT;uPa9U,H }&8єi'q?.>h"=`A>³]g0s=.|^|7*og7qK]pCe*Әt3IL?C2n97B"Fc:;sfxωPdz-Y ǣ>{R9;n9* 9٩#K|Kq߼^mQf>֣\|) 0bdvK]s]Hg:3A3FP*'v"F@:]"8x*n5|Ojzcs[$">6o^QǾ׋ԑH: Z%sUV{+Й Rqzz`b |Rcxɝo-k7;|4KE7aktO|o/[X|ڊ1cd8sU."7Ƕ4> &?:糘1.þͱ~Ib{u!PIg~ksҼ op q{g LݴbJOQ.¶=lUEZ*c|vf5ʼթ 2iwu@Mې{}joH tV|V?K1 [:BHOuoPsb]%~cڎ׽7$Bx%ib1V `<&docu; GvץoCN@b-ۚa_$|>Yf֖q-)>XP-> D`$p00OxY:.Vs׾ykRpEkȼ2wL<'^BK/xJqxIpL:D >Զ.Q@myLɰ{K@"(buh80!+_a.wK2T3ze'; Xau1ZMvv<=;vWpcgxL}'ޱpsoImj( >6؀ E bg^u:mP[A@O崡*!T|K=.%E<?ii\gjG\T "xpXq!X}[P5m]śf>i.<_&mR6 m*ms1Udon_s5* B^Ӛ_g{7]|ͯUf̝؎@cP߫xx k~9ܬx'eH'u_D/fT!NI['I7,.2=]㢳 qQWǼA w fa<28g}AJ9kk}9k7G q3(v~ Gc;!~.>h–BeDyK yK .http://dataformat.org/DyK http://dataformat.org/dfdl-1.0yK >http://dataformat.org/dfdl-1.0DyK http://dataformat.org/dfdl-1.0yK >http://dataformat.org/dfdl-1.0DyK yK Phttp://dataformat.org/dfdl-1.0/dfdl.xsd}DyK _Ref157419914}DyK _Ref161823626}DyK _Ref161820525}DyK _Ref161823893}DyK _Ref140934918}DyK _Ref140935092}DyK _Ref161824338}DyK _Ref140936368}DyK _Ref140936382}DyK _Ref161828896}DyK _Ref161836873}DyK _Ref161823893}DyK _Ref161823893}DyK _Ref162000445}DyK _Ref162000445}DyK _Ref162001275}DyK _Ref162001275Dd\  c $A? ?#" `" ՀU?=8@=ՀU?=8U8)h+xYklTE>-f)m5h+ 劚ҵ@i  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~     !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~;:Root Entry F3Data  7BWordDocumentJ ObjectPool033_1238199336  F0303Data 1TableCompObjoDd 5 D  3 @@"?N@N HNormal$a$ CJOJQJ_HaJmH sH tH DAD Default Paragraph FontViV  Table Normal :V 44 la (k(No List )7Nm  )7NQm  @Vm%-4;@FT]en+%,-4:;@EFST]ejkn0000000000000000%,-4:nh0j0h0Cj0w.Pmmlm_8  @ (  v /Z #  s"*?`  c $X99?/ZT  # `'h. T  # `'h.S T  # `'h.  4  ! h.> HB   # Gv/Hi`'h.Jh   3 "`D%  h   3 "`t".(f B S  ?mtnn+-349;DFRTinnFHV@mP@UnknownGz Times New Roman5Symbol3& z Arial"h݀&݀&!!~4d3QHP)?H2Avaya AssociatesMichael J. Beckerle   FMicrosoft Office Word Picture MSWordDocWord.Picture.89q  dO)Microsoft PowerPoint SlideMSPresentationPowerPoint.Slide.89q+_6Michael J. BeckerleMichaelObjInfo WordDocument4SummaryInformation( DocumentSummaryInformation8#` 0mbjbj\.\. 4>D>DO  hA A A  $hp A  "A A A Y" A  A V@  `Q  80h a R  $A A A A A A A   A A A hA A A A $  SHAPE \* MERGEFORMAT  Integer String String Byte Byte Bits input stream populate logical data kmhFjhHUmHnHuhHjhHU%,-4:;@EFST]ejklmgdFgdHl21h:pHN N!"#!$l% Oh+'0   @ L Xdlt|Avaya Associates Normal.dotMichael J. Beckerle2Microsoft Office Word@@@՜.+,0 hp   Avaya Inc.  Title_1239368822dO)q3q3Ole PRINT BEPRINT8S      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~15% NT   --$  --'3ff--N$%QJNJLKJLHMFOEQESDVDEEFHJLNQVSQOMLKJJQJ----N%%QJNJLKJLHMFOEQESDVDEEFHJLNQVSQOMLKJJQJ--'@Times New Roman-. 2 } anySimpleType  ."System7---N$%R0O1M1K3I4G6F8F:E<EmFoFqGsIuKwMxOyRyyyxwusqom<:8643110R0----N%%R0O1M1K3I4G6F8F:E<EmFoFqGsIuKwMxOyRyyyxwusqom<:8643110R0--'@Times New Roman-. 2 ckstring  .---N%%0113468:<moqsuwxyyyyxwusqom<:86431100--'@Times New Roman-. 2 cQNameg.---N%%0113468:<moqsuwxyyyyxwusqom<:86431100--'@Times New Roman-. 2 cNOTATION .---N$%*0'1%1#3!4 68:<moq s!u#w%x'y*yyyxwusqom<:8643110*0----N%%*0'1%1#3!4 68:<moq s!u#w%x'y*yyyxwusqom<:8643110*0--'@Times New Roman-. 2 c;floatI  .---N$%0113468:<moqsuwxyy<y>yAxCwEuFsGqHoHmH<H:G8F6E4C3A1>1<00----N%%0113468:<moqsuwxyy<y>yAxCwEuFsGqHoHmH<H:G8F6E4C3A1>1<00--'@Times New Roman-. 2 cdouble .---N$%j0h1f1d3b4`6_8_:^<^m_o_q`sbudwfxhyjyyyx w u sqom<:8 6 4 3110j0----N%%j0h1f1d3b4`6_8_:^<^m_o_q`sbudwfxhyjyyyx w u sqom<:8 6 4 3110j0--'@Times New Roman-. 2 c|decimalN  .---N$%E0C1A1>3=4;6:89:9<9m9o:q;s=u>wAxCyEyyyxwusqom<:8643110E0----N%%E0C1A1>3=4;6:89:9<9m9o:q;s=u>wAxCyEyyyxwusqom<:8643110E0--'@Times New Roman-. 2 cXbooleanN .---N$%1113468:=moqsuwxyyyy x w u s q o m = : 8 6 4 3 1111----N%%1113468:=moqsuwxyyyy x w u s q o m = : 8 6 4 3 1111--'3ff--N$%! 1 1 1 3 4 6 8 : = m o q s u w x y! y y y x w u s q o m = : 8 6 4 3 1 1 1! 1----N%%! 1 1 1 3 4 6 8 : = m o q s u w x y! y y y x w u s q o m = : 8 6 4 3 1 1 1! 1--'@Times New Roman-. 2 c3 hexBinaryT .---N%% 1 1 1 3 4 6 8 : = m o q s u w x y y y y x w u s q o m = : 8 6 4 3 1 1 1 1--'@Times New Roman-. 2 c anyURI .---N%%   >ACEGHIJJ(J*J-I/H1G2E3C4A4>4 4 3 21/-*(--'@Times New Roman-. 2 4normalizedString   .---N%%\YWUSQPOOOOPQSUWY\\--'@Times New Roman-. 2 ntokenI .---N%%mkhfdcbaaaabcdfhkm "$%''((''%$" m--'@Times New Roman-. 2 language .---N%%WUSPOMLKKKKLMOPSUWW--'@Times New Roman-.  2 iName.---N%%641/.,+****+,./146      6--'@Times New Roman-. 2 GNMTOKENe .---N%%* ' %!#"!$ %'*,]_a c!e#g%h'i*iiihgeca_],*'%$"!  * --'@Times New Roman-. 2 S;NMTOKENS .---N%%> ; 9!7"5$4%2'2*2,2]2_2a4c5e7g9h;i>iiihgeca_],*'%$"!  > --'@Times New Roman-. 2 SONCName.---N%% !""" "#!% &()****)(&%# --'@Times New Roman-.  2 ID .---N%%ROMKIGFFEEFFGIK M!O"R"""! R--'@Times New Roman-. 2 cIDREFe .---N%% !""""! --'@Times New Roman-. 2 -ENTITY .---N%%E|C|@}>~<;:9999:;<>@CE~}||E|--'@Times New Roman-. 2 WIDREFS .---N%% ||}~ ~}|| |--'@Times New Roman-. 2 ENTITIES .---N%%rpnljhg f f f>fAgChEjGlHnIpJrJJJIHGEC A >     r--'@Times New Roman-. 2 4integerS  .---N$%vtqonlkjjjjklnoqtvv----N%%vtqonlkjjjjklnoqtvv--'@Times New Roman-.  2 long .---N%%        VX[]^`abbbba`^][XV--'@Times New Roman-. "2 (nonPositiveInteger   .---N%%D G I K M N O P P P P O N M K I G D --'@Times New Roman-. "2 nonNegativeInteger   .---N%%/,*(&$##""##$&(*,/=@BDFHIIJJIIHFDB@=/--'@Times New Roman-. 2 AnegativeIntegerg   .---N%%ligecba````abcegilnprtvxyzzzzyxvtrpnl--'@Times New Roman-. 2 ~positiveIntegerg   .---N$%                  ----N%%                  --'@Times New Roman-. 2  unsignedLong .---N$%,,,./1358hkmoqrstt t t s r q o m k h 8 5 3 1 / . , , ,,----N%%,,,./1358hkmoqrstt t t s r q o m k h 8 5 3 1 / . , , ,,--'@Times New Roman-. 2 ^ unsignedIntg   .---N$%                      ----N%%                      --'@Times New Roman-. 2  unsignedShorte  .---N$%ppprsuwy|          | y w u s r p p pp----N%%ppprsuwy|          | y w u s r p p pp--'@Times New Roman-. 2  unsignedByte  .---N$%yz~z|{{}yxwwwwxy{|~}{zzyy----N%%yz~z|{{}yxwwwwxy{|~}{zzyy--'@Times New Roman-.  2 int  .---N$%pmkigfedddMdPeRfTgViXkYmYpZZYYXVTRPMp----N%%pmkigfedddMdPeRfTgViXkYmYpZZYYXVTRPMp--'@Times New Roman-. 2 Dshorte  .---N$%vtqonlkjjjjklnoqtvv----N%%vtqonlkjjjjklnoqtvv--'@Times New Roman-.  2 byte .---N$%acfhjklmmmmlkjhfca----N%%acfhjklmmmmlkjhfca--'@Times New Roman-.  2 date .---N$%      ----N%%      --'@Times New Roman-.  2 time .---N$%?<:864332233468:<??----N%%?<:864332233468:<??--'@Times New Roman-. 2 OdateTime  .---N%%41/-+*)(((()*+-/144--'@Times New Roman-. 2 EgYeari.---N%%--'@Times New Roman-. 2  gYearMonth .---N%%    --'@Times New Roman-. 2 "gMonth  .---N%%--'@Times New Roman-. 2  gMonthDayh  .---N%%hjmoprsttttsrpomjh--'@Times New Roman-.  2 gDay.---N$%4 7 9 ; = ? @ A A A A @ ? = ; 9 7 4 ----N%%4 7 9 ; = ? @ A A A A @ ? = ; 9 7 4 --'@Times New Roman-. 2 duration .---T8"&----H%"%&--'--T8"JKKKKJJIIHHHHIIJTJ&?TT----H%"JKKKKJJIIHHHHIIJ%TJ&?TT--'--T8"WYYYXXWVVUUUUVVWaW&Maa----H%"WYYYXXWVVUUUUVVW%aW&Maa--'--T8"ZZ[[\\[[ZZYYXXXZdZ&Odd----H%"ZZ[[\\[[ZZYYXXXZ%dZ&Odd--'--T8"&----H%"%&--'--T8"&----H%"%&--'--N8%----B%%%--'--N8%v----B%%%v--'--N8~ ~       ~ ~ } | | | | ~  ~ %s   ----B%~ ~       ~ ~ } | | | | ~ % ~ %s   --'--N8T T U U V V U U T T S S R R R T ^ T %I ^ ^ ----B%T T U U V V U U T T S S R R R T %^ T %I ^ ^ --'--%D--'--B8B.B0@0i/i/j/j.k-j-j,i,i,@,?-?.>>??@AAABB8e.z#e8e8e----6%B.B0@0i/i/j/j.k-j-j,i,i,@,?-?.>>??@AAABB%8e.z#e8e8e--'--B8BB@iijjkjjii@??>>??@AAABBezeee----6%BB@iijjkjjii@??>>??@AAABB%ezeee--'--B8BB@iijjkjjii@??>>??@AAABBezeee----6%BB@iijjkjjii@??>>??@AAABB%ezeee--'-->8BrBs@sisisjrjrkqjpjpipip@p?p?r>>?@AABB|erzge|e|e----2%BrBs@sisisjrjrkqjpjpipip@p?p?r>>?@AABB%|erzge|e|e--'--@8>\>]?]?]@]i]i]j\j\k[jZjZiZ@\BBAAA@??>>fe\zQefefe----4%>\>]?]?]@]i]i]j\j\k[jZjZiZ@\BBAAA@??>>%fe\zQefefe--'-->8>Z>[?\?\@\i\i[j[jZkYjYjXiXiX@ZBBAA@?>>deZzPedede----2%>Z>[?\?\@\i\i[j[jZkYjYjXiXiX@ZBBAA@?>>%deZzPedede--'-->8>K>L?M?M@MiMiLjLjKkJjJjIiIiI@KBBAA@?>>VeKzAeVeVe----2%>K>L?M?M@MiMiLjLjKkJjJjIiIiI@KBBAA@?>>%VeKzAeVeVe--'-->8>.>/?/?0@0i/i/j.j.k-j-j,i,i,@.BBBA@?>>8f.z#f8f8f----2%>.>/?/?0@0i/i/j.j.k-j-j,i,i,@.BBBA@?>>%8f.z#f8f8f--'-->8>>??@iijjkjjii@BBBA@?>>fzfff----2%>>??@iijjkjjii@BBBA@?>>%fzfff--'--88----,%%--'--P8 U|{{{{|||~~~}}|UUTTTTTUUU----D% U|{{{{|||~~~}}|UUTTTTTUUU%--'--T8";;<<==;cdddedddc;::999;_t___----H%";;<<==;cdddedddc;::999;%_t___--'--T8";;<<==;cdddedddc;::999;_t___----H%";;<<==;cdddedddc;::999;%_t___--'--T8";999::;cdddedddc;==<<;;_t___----H%";999::;cdddedddc;==<<;;%_t___--'--88----,%%--'--T8"----H%"%--'--88ttssrrrsstt----,%ttssrrrsstt%--'--T8"ttssrrrsstt----H%"ttssrrrsstt%--'--R8!thijjjjjjihhgggghtssrrrssttsh^ss----F%!thijjjjjjihhgggghtssrrrsstt%sh^ss--'--88-_`aaaaa`_-,,+++,,--\p\\\----,%-_`aaaaa`_-,,+++,,--%\p\\\--'--T8"j-jNjOjPiPiPhPjNj_j`iaiahagagag`f_fNgNgMgMhMiMgNg-g,g,h+i+i+j,j,j-j-r\hp^\r\r\----H%"j-jNjOjPiPiPhPjNj_j`iaiahagagag`f_fNgNgMgMhMiMgNg-g,g,h+i+i+j,j,j-j-%r\hp^\r\r\--'--T8"----H%"%--'--T8"UUUTTTTTUUU----H%"UUUTTTTTUUU%--'--T8"U~~~~UUTTTTTUUU----H%"U~~~~UUTTTTTUUU%--'--L8UUTTTUUU----@%UUTTTUUU%--'--88bcdddddcb       _t___----,%bcdddddcb       %_t___--'--N8 <=====<^^_____^<;:::<   ZoZZZ----B% <=====<^^_____^<;:::<   %ZoZZZ--'--T8"----H%"%--'--L8eedcccddee----@%eedcccddee%--'--N8@ABBBB@bccdddccb@@???@     _s___----B%@ABBBB@bccdddccb@@???@     %_s___--'--J8@?6 ?7 ?8 @8 @8 b8 c7 c7 d6 d5 d5 c5 c4 b4 @6 BBBB@    A _6 s, _A _A _---->%@?6 ?7 ?8 @8 @8 b8 c7 c7 d6 d5 d5 c5 c4 b4 @6 BBBB@    %A _6 s, _A _A _--'--R8!8 8 6 7 8 9 9 9 9 8 8 7 6 6 6 5 5 7 6 6 5 5 5 5 5 5 6 6 7 7 8 8 8 A 7 - A A ----F%!8 8 6 7 8 9 9 9 9 8 8 7 6 6 6 5 5 7 6 6 5 5 5 5 5 5 6 6 7 7 8 8 8 %A 7 - A A --'--889 9 9 8 8 7 6 6 6 5 5 6 ~6 ~6 }7 }8 }8 ~9 ~9 9 A 7 - A A ----,%9 9 9 8 8 7 6 6 6 5 5 6 ~6 ~6 }7 }8 }8 ~9 ~9 9 %A 7 - A A --'--R8!9 9 =9 >8 >8 ?7 ?7 ?8 =8 S8 T8 U7 U7 U6 U5 U5 T5 S5 =5 <5 <7 <7 <5 =5 5 6 6 7 8 8 9 9 9 A P7 d- PA PA P----F%!9 9 =9 >8 >8 ?7 ?7 ?8 =8 S8 T8 U7 U7 U6 U5 U5 T5 S5 =5 <5 <7 <7 <5 =5 5 6 6 7 8 8 9 9 9 %A P7 d- PA PA P--'@Times New Roman-. 2 c base64Binary  .-      !"#$%&'()*+,-./0123456789< ?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~l 1-% EMF8S]'F, EMF+@XXF\PEMF+"@ @ $@ 0@?!@ @ F(GDIC FXLEMF+*@$?? @$;E E!b $$>>'% % V0 LF]LF]% % $$AA" FEMF+@ FGDICF(GDICSFGDICF(GDICFGDICF(GDIC FGDICF(GDIC+ FGDICF(GDIC GF(GDICV XFGDICF(GDIC HFGDICF(GDICCHFEMF+*@$??@!DCGDCD]ЧCD#CD1wCDCGDDI % $$AAFdXEMF+@D8UU%@A@$$==_888)% % ; EX(DDDDD]6DDgX(DDD( E(6Y(X(FZ(ZZg6Z]X(ZFZY6 E<@BG% % $$AA( " FEMF+@ FGDICF(GDIC]FGDICRp@Times New Roman@pial!̜ <Z@ArialArial0  Dt@}0( pDttXo}0t0$dv%    T_^@ \@} LhanySimpleTypex   % ( F(GDICD/{FEMF+*@$??@օD< D[D< DUqDi DUqD9DUqDGDUqDD[DqMDօDqMDro6DqMD!8DqMD9DD9DGD9D9D9Di D!8D< Dro6D< DօD< D@ff3!b $$==%  ;%#X($#U$\#U$#6U$&X(U$7'$'%'6-'X(.'Y.7'Y.&6Y.#X(Y.\#.#-#6%#<>E0y % $$AAFdXEMF+@D8L&@A@$$==_888*% % ;%#X($#U$\#U$#6U$&X(U$7'$'%'6-'X(.'Y.7'Y.&6Y.#X(Y.\#.#-#6%#<@C.|% % $$AA( " FEMF+@ FGDICF(GDICjCkFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0gDt(DtǾ0Dttdv%    TpkEi@ \@kcLXstring   % ( F(GDIC/{F<0EMF+*@$??@D8L&@A@^?D< D=D< D#X(c># >\# >#6 >&X( >7'c>'>'6L'X(L'L7'L&6L#X(L\#L#L#6>#<@.|% % $$AA( " FEMF+@ FGDICF(GDICCkFGDICRp@Times New Romanv00t00tDt0Dtm0}t0 }0" 0  W" 0NDt(DtǾ0Dttrdv%    T|Ei@ \@cL\NOTATION  % ( F(GDIC/{FEMF+*@$??@ED< D=mD< DDi DD9DDGDDD=mDqMDEDqMD |DqMDTDqMDRDDRDGDRD9DRDi DTD< D |D< DED< D@ff3!b $$==%  ;R#X(/R#Q\#Q#6Q&X(Q7'/R'R'6X'X(#Y'{Y7'{Y&6{Y#X({Y\##Y#X#6R#<>0y % $$AAFdXEMF+@ D8L&@A@ $$==_888*% % ;R#X(/R#Q\#Q#6Q&X(Q7'/R'R'6X'X(#Y'{Y7'{Y&6{Y#X({Y\##Y#X#6R#<@.|% % $$AA( " FEMF+@ FGDICF(GDIC9C|kFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0tDt(DtǾ0Dttdv%    Tl;Ezi@ \@;cLXfloat   % ( F(GDIC/K{FEMF+*@$??@ D< DWD< DUDi DUD9DUDGDUDDWDqMDDqMDDqMDGfDqMDODDODGDOD9DODi DGfD< DD< DD< D@ ff3!b $$==%  ;:[#X(Z#wZ\#wZ#6wZ&X(wZ7'Z':['6c'X(,d'd7'd&6d#X(d\#,d#c#6:[#<>0Iy % $$AAFdXEMF+@ D8L&@A@  $$==_888*% % ;:[#X(Z#wZ\#wZ#6wZ&X(wZ7'Z':['6c'X(,d'd7'd&6d#X(d\#,d#c#6:[#<@.K|% % $$AA( " FEMF+@ FGDICF(GDICC'kFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0eDt(DtǾ0Dttdv%    TpE$i@ \@cLXdouble  % ( F(GDIC]/{FEMF+*@$??@ ]D< DdD< DUDՎ DUDX8DUD;IDUDDdDtMD]DtMDkDtMDHDtMDDDD;IDDX8DDՎ DHD< DkD< D]D< D@ ff3!b $$==%  ;f#X(;f#e\#e#6e&X(e3';f'f'6.p'X(p'p3'p&6p#X(p\#p#.p#6f#<>^0y % $$AAFdXEMF+@ D8L&@A@  $$==_888*% % ;f#X(;f#e\#e#6e&X(e3';f'f'6.p'X(p'p3'p&6p#X(p\#p#.p#6f#<@[.|% % $$AA( " FEMF+@ FGDICF(GDIC{CkFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0lDt(DtǾ0Dttdv%    Tx|Ei@ \@|cL\decimal    % ( F(GDIC8/{FEMF+*@$??@'D< D"D< DU/DՎ DU/DX8DU/D;IDU/DD"DtMD'DtMD$$DtMD*DtMDDDD;IDDX8DDՎ D*D< D$$D< D'D< D@ff3!b $$==%  ;Ut#X(s#s\#s#6s&X(s3's'Ut'6 ~'X(y~'~3'~&6~#X(~\#y~# ~#6Ut#<>90y % $$AAFdXEMF+@D8L&@A@$$==_888*% % ;Ut#X(s#s\#s#6s&X(s3's'Ut'6 ~'X(y~'~3'~&6~#X(~\#y~# ~#6Ut#<@6.|% % $$AA( " FEMF+@ FGDICF(GDICVCkFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0nDt(DtǾ0Dttdv%    TxXEi@ \@XcL\boolean/  % ( F(GDIC/ {FEMF+*@$??@xE< D; E< DUgDՎ DUgDX8DUgD;IDUgDD; EtMDxEtMD^EtMD%EtMD}ED}E;ID}EX8D}EՎ D%E< D^E< DxE< D@( !b $$>>'%  ;9@X(@??6?fX(?@9@6GX(H;H;Hf6;HX(;HHG69@<>0 y % $$AAFdXEMF+@D8UU%@A@$$>>_888% % ;9@X(@??6?fX(?@9@6GX(H;H;Hf6;HX(;HHG69@<@. |% % $$AA( " FEMF+@ FGDICF(GDIC / {FEMF+*@$??@>E< DE< DPEՎ DPEX8DPE;IDPEDEtMD>EtMDEtMD.EtMDREDRE;IDREX8DREՎ D.E< DE< D>E< D@ff3( !b $$>>'3ff%  ;IX(HHH6HfX(HHI6NX(O?O?Of6?OX(?OON6I<> 0 y % $$AAFdXEMF+@D8UU%@A@$$>>_888% % ;IX(HHH6HfX(HHI6NX(O?O?Of6?OX(?OON6I<@ . |% % $$AA( " FEMF+@ FGDICF(GDIC2 C kFGDICRp@Times New Romanv00t00tDt0 Dtm0}t0 }0" 0  W" 0yDt(DtǾ0Dtt2dv%    T3 E i@ \@3 c L`hexBinary  % ( F(GDIC / {F<0EMF+*@$??@D8L&@A@ E< D; E< DUEՎ DUEX8DUE;IDUED; EtMD EtMD:)EtMDY*EtMD*ED*E;ID*EX8D*EՎ DY*E< D:)E< D E< D@!b $$>>_888% % ;RPX(POO6OfX(OPRP6TX()UUUUUf6UUX(UU)UT6RP<@ . |% % $$AA( " FEMF+@ FGDICF(GDIC C kFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0IDt(DtǾ0Dttdv%    Tp E i@ \@ cLXanyURI  % ( F(GDIC7LF<0EMF+*@$??@D8L&@A@|Dr@DYCr@DCADC1wCDCODCJQDYCtRD|DtRDJDtRDiKDtRDK-MDJQDK-MDODK-MD1wCDK-MDADiKDr@DJDr@D|Dr@D@!b $$==_888*% % ;6 0X(0sl0s06s3X(sK446 4624X(24D3K4D336D30X(D3l0202066 0<@7M% % $$AA( " FEMF+@ FGDICF(GDIC<FGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0gDt(DtǾ0Dttdv%    T :@ \@4LlnormalizedString    % ( F(GDICNF<0EMF+*@$??@D8L&@A@DkDMDkDD)mDD1nDDzDD|DMDt~DDt~DiY4Dt~DG 6Dt~Dn7D|Dn7DzDn7D1nDn7D)mDG 6DkDiY4DkDDkD@!b $$==_888*% % ;%:X(L%:$C;$;6$>X($"?L%y?%y?6-y?X(|-y?-"?->6-;X(-C;|-:-:6%:<@L% % $$AA( " FEMF+@ FGDICF(GDIClFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0nDt(DtǾ0Dttdv%    Tln@ \@nLXtoken  % ( F(GDIC_~*F<0EMF+*@$??@D8L&@A@CDhSCDCODC;vDC%DC]DhSC_ DC_ DD_ DD_ DK D]DK D%DK D;vDK DODDDDDCD@!b $$==_888*% % ;GX(cG IH H6 KX( 'Lc~L~L6!~LX(!"~Lx"'Lx"K6x"HX(x"IH!"G!G6G<@^|*% % $$AA( " FEMF+@ FGDICF(GDIC}FGDICRp@Times New Romanv00t00tDt0Dtm0}t0 }0" 0  W" 0eDt(DtǾ0Dtt dv%    T|@ \@L\language  % ( F(GDICJ~F<0EMF+*@$??@D8L&@A@DDBDDDODD;vDD%DD]DBD_ DD_ DN;5D_ D6D_ DW8D]DW8D%DW8D;vDW8DOD6DDN;5DDDD@!b $$==_888*% % ;v%GX( %G$IH$H6$KX($'L %~Lv%~L6G-~LX(-~L.'L.K6.HX(.IH-GG-G6v%G<@H|% % $$AA( " FEMF+@ FGDICF(GDICgFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0eDt(DtǾ0Dttdv%    Tdi@ \@iLTName % ( F(GDIC)~F<0EMF+*@$??@D8L&@A@ӦMDDKDDJDODJD;vDJD%DJD]DKD_ DӦMD_ DD_ DsD_ D D]D D%D D;vD DODsDDDDӦMDD@!b $$==_888*% % ;b3GX(2G2IH2H62KX(2'L2~Lb3~L6F@~LX(@~L A'L AK6 AHX( AIH@GF@G6b3G<@'|% % $$AA( " FEMF+@ FGDICF(GDICFFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0NDt(DtǾ0Dttgdv%    TxG@ \@GL\NMTOKEN  % ( F(GDICkF<0EMF+*@$??@ D8L&@A@!gJDDHDDzGDlDzGDCDzGD0DzGD{DHDd)DgJDd)D@Dd)D͂Dd)D~D{D~D0D~DCD~DlD͂DD@DDgJDD@! !b $$==_888*% % ;2RX(.2R1WR1R61UX(16V.2V2V6@VX(_AVA6VAU6ARX(AWR_AR@R62R<@l% % $$AA( " FEMF+@ FGDICF(GDIC:3[FGDICRp@Times New Romanv00t00tDt0Dtm0}t0 }0" 0  W" 0SDt(DtǾ0Dttdv%    T|;5Y@ \@;SL\NMTOKENS  % ( F(GDIC0kF<0EMF+*@$??@"D8L&@A@#DD DD~ DlD~ DCD~ D0D~ D{D Dd)DDd)Dc;Dd)DP=Dd)Dv>D{Dv>D0Dv>DCDv>DlDP=DDc;DDDD@#"!b $$==_888*% % ;#RX(p#R#WR#R6#UX(#6Vp#V#V6.VX(>/V/6V/U6/RX(/WR>/R.R6#R<@/l% % $$AA( " FEMF+@ FGDICF(GDICM3[FGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0eDt(DtǾ0Dttdv%    TpO5Y@ \@OSLXNCName % ( F(GDIC,$F<0EMF+*@$??@$D8L&@A@%_CNDCND@CYD@C̼D@CD@CƘDCFD_CFD݋DFDM@ DFD DƘD DD D̼D DYDM@ DND݋DND_CND@%$!b $$==_888*% % ;]X(7]]^^6[aX(a7bb6!bX(I"b"a"[a6"^^X("]I"]!]6]<@-%% % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0DDt(DtǾ0Dtt\dv%    TX@ \@ LPID  % ( F(GDICD$F<0EMF+*@$??@&D8L&@A@'\}DNDDNDUqDYDUqD̼DUqDDUqDƘDDFD\}DFD6DFDl8DFD9DƘD9DD9D̼D9DYDl8DND6DND\}DND@'&!b $$==_888*% % ;%]X($]U$]U$^^6U$[aX(U$a$b%b6-bX(.bj.aj.[a6j.^^X(j.].]-]6%]<@C%% % $$AA( " FEMF+@ FGDICF(GDICaFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0FDt(DtǾ0Dttdv%    Tlc@ \@c LXIDREF  % ( F(GDIC$F<0EMF+*@$??@(D8L&@A@)GDNDQEDNDCDYDCD̼DCDDCDƘDQEDFDGDFD+)nDFD+oDFD>qDƘD>qDD>qD̼D>qDYD+oDND+)nDNDGDND@)(!b $$==_888*% % ;1]X(M1]0]0^^60[aX(0aM1b1b6;bX(;bH~D:DqDӮDqDDqDDqDRD>~DRD̓|DRD}pDRDinDDmDDmDӮDmD@0ff3!b $$==%  ;bWX;X(VX;V;V<6V?X(V?V?bW?6]?X(]?D^?D^?6D^<X(D^;]X;]X;6bWX;<>j % $$AAFdXEMF+@1D8L&@A@01$$==_888*% % ;bWX;X(VX;V;V<6V?X(V?V?bW?6]?X(]?D^?D^?6D^<X(D^;]X;]X;6bWX;<@g% % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0gDt(DtǾ0Dttdv%    Td@ \@LTlong  % ( F(GDIC dF<0EMF+*@$??@2D8L&@A@3DnDDnDlDioDlDqDlD̿}DlDjDD^DD^DD^DD^DODjDOD̿}DODqDODioDDnDDnDDnD@32!b $$==_888*% % ;ta;X(a;`;`e<6`h?X(`?a(@ta(@6[u(@X(u(@ v? vh?6 ve<X( v;u;[u;6ta;<@e% % $$AA( " FEMF+@ FGDICF(GDIC'5FGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0rDt(DtǾ0Dttdv%    T(4@ \@(LpnonPositiveInteger    % ( F(GDICS F<0EMF+*@$??@4D8L&@A@5EDnDDnDRDioDRDqDRD̿}DRDjDD^DED^D0IE^DҵE^DR EjDR E̿}DR EqDR EioDҵEnD0IEnDEDnD@54!b $$>>_888% % ;?X(|?Q?Q?36Q?X(Q?|? ? 6!J X(WJ JJ6J3X(JWJ!J6?<@S % % $$AA( " FEMF+@ FGDICF(GDIC! FGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0rDt(DtǾ0Dtt0dv%    T @ \@LpnonNegativeInteger    % ( F(GDIC!~LF<0EMF+*@$??@6D8L&@A@7BDD DDZDkDZDtDZD|DZDPQD DDBDDDDDD@DPQD@D|D@DtD@DkDDDDDBDD@76!b $$==_888*% % ;bGX(~bG&bFH&bH6&bKX(&b!L~bvLbvL6svLX(BtvLt!LtK6tHX(tFHBtGsG6bG<@ |L% % $$AA( " FEMF+@ FGDICF(GDIC?FGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0rDt(DtǾ0Dttdv%    TA@ \@ALlnegativeInteger    % ( F(GDIC^}|F<0EMF+*@$??@8D8L&@A@9DUDDUDD DD'`DD;kDDY@DD DD DE DzLE DEY@DE;kDE'`DE DzLEUDEUDDUD@98!b $$>>_888% % ;^;#X((;#:$:U$6:%X(: &(;7&^;7&6lC7&X(C7&C &C%6CU$X(C$C#lC#6^;#<@]|}% % $$AA( " FEMF+@ FGDICF(GDIC|TFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0rDt(DtǾ0Dttdv%    T~R@ \@~LlpositiveInteger    % ( F(GDIC} FEMF+*@$??@:r EUD< EUDU E DU E'`DU E;kDU EY@D< E Dr E D58E DӤE DREY@DRE;kDRE'`DRE DӤEUD58EUDr EUD@:ff3!b $$>>%  ;E#X(E#pE$pEU$6pE%X(pE &E7&E7&6M7&X(M7&M &M%6MU$X(M$M#M#6E#<>~  % $$AAFdXEMF+@;D8L&@A@:;$$>>_888% % ;E#X(E#pE$pEU$6pE%X(pE &E7&E7&6M7&X(M7&M &M%6MU$X(M$M#M#6E#<@| % % $$AA( " FEMF+@ FGDICF(GDIC FGDICRp@Times New Romanv00t00tDt0 Dtm0} t0 }0" 0  W" 0g Dt(Dt Ǿ0Dt tdv%    T @ \@ LdunsignedLong  % ( F(GDIC* wFEMF+*@$??@<f E~D{ E~D# E&(D# ED# ED# ED{ EDf EDEED EDEDEDEDE&(D E~DEE~Df E~D@<ff3!b $$>>%  ;qF\)X(:F\)F)F)6FB+X(Fx+:F+qF+6M+X(=M+hMx+hMB+6hM)X(hM)=M\)M\)6qF\)<>+ u % $$AAFdXEMF+@=D8L&@A@<=$$>>_888% % ;qF\)X(:F\)F)F)6FB+X(Fx+:F+qF+6M+X(=M+hMx+hMB+6hM)X(hM)=M\)M\)6qF\)<@) w% % $$AA( " FEMF+@ FGDICF(GDIC> fFGDICRp@Times New Romanv00t00tDt0 Dtm0} t0 }0" 0  W" 0t Dt(Dt Ǿ0Dt t^dv%    T@ d@ \@^ LdunsignedInt    % ( F(GDIC FEMF+*@$??@>x E`D E`D El D ECD E!D ED EdyDx EdyDڀEdyDEdyDQFEDQFE!DQFECDQFEl DE`DڀE`Dx E`D@>ff3!b $$>>%  ;E.X(E._E@._Eu.6_E/X(_E00E[0E[06M[0X(M[0 N00 N/6 Nu.X( N@.M.M.6E.<>  % $$AAFdXEMF+@?D8L&@A@>?$$>>_888% % ;E.X(E._E@._Eu.6_E/X(_E00E[0E[06M[0X(M[0 N00 N/6 Nu.X( N@.M.M.6E.<@ % % $$AA( " FEMF+@ FGDICF(GDIC FGDICRp@Times New Romanv00t00tDt0 Dtm0} t0}0" 0  W" 0t Dt(Dt Ǿ0Dt tdv%    T @ \@ LhunsignedShort   % ( F(GDICn FEMF+*@$??@ EUDt EUD) E D) ED) E;D) EY\Dt E D E DJE DpE DSEY\DSE;DSEDSE DpEUDJEUD EUD@ff3!b $$>>%  ;E|3X(E|3E3E36E^5X(E5E5E56M5X(M5M5M^56M3X(M3M|3M|36E|3<>o  % $$AAFdXEMF+@D8L&@A@$$>>_888% % ;E|3X(E|3E3E36E^5X(E5E5E56M5X(M5M5M^56M3X(M3M|3M|36E|3<@m % % $$AA( " FEMF+@ FGDICF(GDIC FGDICRp@Times New Romanv00t00tDt0 Dtm0} t0 }0" 0  W" 0e Dt(Dt Ǿ0Dt tdv%    T @ \@ LdunsignedByte   % ( F(GDICvxFEMF+*@$??@VuD:D8D:DUDODUDXDUD DUDD8D2DVuD2D D2DD2DDDD DDXDDODD:D D:DVuD:D@ff3!b $$==%  ;3XGX(WGpWGpWUH6pWRKX(pWKWL3XL6\LX(\LB]KB]RK6B]UHX(B]G\G\G63XG<>wy % $$AAFdXEMF+@D8L&@A@$$==_888*% % ;3XGX(WGpWGpWUH6pWRKX(pWKWL3XL6\LX(\LB]KB]RK6B]UHX(B]G\G\G63XG<@tw% % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0tDt(DtǾ0Dtt`dv%    T`@ \@LTint   % ( F(GDICb\FEMF+*@$??@ D,D3D,DDעDDﬣDDٽDDƓD3D FD D FDrĻD FDD FDNDƓDNDٽDNDﬣDNDעDD,DrĻD,D D,D@ff3!b $$==%  ;VQX(VQcZ % $$AAFdXEMF+@D8L&@A@$$==_888*% % ;VQX(VQj % $$AAFdXEMF+@D8L&@A@$$==_888*% % ;cW[X(V[V4\V\6V_X(V`Vj`cWj`6]j`X(]j`D^`D^_6D^\X(D^4\][][6cW[<@g % % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0eDt(DtǾ0Dttdv%    Td@ \@LTbyte  % ( F(GDICpFEMF+*@$??@ CUDwCUDCjDCqCDCKDC DwCDCDZDD DDoD DoDKDoDqCDoDjD DUDZDUDCUD@ ff3!b $$==%  ;YxX(gYxxy6|X(|g||6&|X(|&|&|&|6&yX(&x|&Yx&Yx6Yx<>n % $$AAFdXEMF+@D8L&@A@ $$==_888*% % ;YxX(gYxxy6|X(|g||6&|X(|&|&|&|6&yX(&x|&Yx&Yx6Yx<@p% % $$AA( " FEMF+@ FGDICF(GDICMFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0eDt(DtǾ0Dttdv%    TdJ@ \@LTdate  % ( F(GDICFEMF+*@$??@ (DUDA&DUD~%DjD~%DqCD~%DKD~%D DA&DD(DDbADDBDDF1DD DF1DDKDF1DDqCDF1DDjDBDUDbADUD(DUD@ ff3!b $$==%  ;*YxX()YxX)xX)y6X)|X(X)|)|*|6?0|X(0|1|1|61yX(1x0Yx?0Yx6*Yx<> % $$AAFdXEMF+@ D8L&@A@  $$==_888*% % ;*YxX()YxX)xX)y6X)|X(X)|)|*|6?0|X(0|1|1|61yX(1x0Yx?0Yx6*Yx<@% % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0eDt(DtǾ0Dttdv%    Td@ \@LTtime  % ( F(GDIC1FEMF+*@$??@ ODUD NDUDLDjDLDqCDLDKDLD D NDDODD|DDD}DDD-D DD-DKDD-DqCDD-DjDD}DUD|DUDODUD@ ff3!b $$==%  ;3YxX({3Yx$3x$3y6$3|X($3|{3|3|6>|X(k?|?|?|6?yX(?xk?Yx>Yx63Yx<>2 % $$AAFdXEMF+@ D8L&@A@  $$==_888*% % ;3YxX({3Yx$3x$3y6$3|X($3|{3|3|6>|X(k?|?|?|6?yX(?xk?Yx>Yx63Yx<@/% % $$AA( " FEMF+@ FGDICF(GDICMFGDICRp@Times New Romanv00t00tDt0Dtm0}t0 }0" 0  W" 0eDt(DtǾ0Dttdv%    T|O@ \@OL\dateTime   % ( F(GDIC&F<0EMF+*@$??@D8L&@A@CDUDDUDDjDDqCDDKDD DDDCDD$DDDDRD DRDKDRDqCDRDjDDUD$DUDCDUDd@!b $$==_888*% % ;>CYxX(BYxyBxyBy6yB|X(yB|B|>C|6 K|X(yK|K|K|6KyX(KxyKYx KYx6>CYx<@%% % $$AA( " FEMF+@ FGDICF(GDICDFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0rDt(DtǾ0Dttdv%    TlE@ \@ELXgYear % ( F(GDICF<0EMF+*@$??@D8L&@A@ʴDUDۜDUDU/DjDU/DqCDU/DKDU/D DۜDDʴDD-;DDDDĺD DĺDKDĺDqCDĺDjDDUD-;DUDʴDUD@!b $$==_888*% % ;NYxX(fNYxNxNy6N|X(N|fN|N|6\|X(]|[]|[]|6[]yX([]x]Yx\Yx6NYx<@% % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0 Dtm0} t0 }0" 0  W" 0h Dt(Dt Ǿ0Dt ttdv%    T@ \@ L`gYearMonth  % ( F(GDICF<0EMF+*@$??@D8L&@A@DUD@DUDDjDDqCDDKDD D@DDDD~DD}xDDQ-D DQ-DKDQ-DqCDQ-DjD}xDUD~DUDDUD@!b $$==_888*% % ;aYxX(`YxB`xB`y6B`|X(B`|`|a|6Hj|X(j|k|k|6kyX(kxjYxHjYx6aYx<@% % $$AA( " FEMF+@ FGDICF(GDIC!FGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0hDt(DtǾ0Dttdv%    Tp"@ \@"LXgMonth   % ( F(GDICF<0EMF+*@$??@D8L&@A@JDUD3mDUDDjDDqCDDKDD D3mDDJDD<}DDZDDD DDKDDqCDDjDZDUD<}DUDJDUD@!b $$==_888*% % ;nYxX(mYxXmxXmy6Xm|X(Xm|m|n|67{|X({|{|{|6{yX({x{Yx7{Yx6nYx<@% % $$AA( " FEMF+@ FGDICF(GDICFGDICRp@Times New Romanv00t00tDt0 Dtm0}t0 }0" 0  W" 0yDt(DtǾ0Dtt\dv%    T@ \@ L`gMonthDay   % ( F(GDICvF<0EMF+*@$??@D8L&@A@xDUDDUDRDjDRDqCDRDKDRD DDDxDDEDEDSGE DSGEKDSGEqCDSGEjDEUDEUDxDUD@!b $$>>_888% % ;?-<X(|?-X(Q?E>|?o>?o>6>Co>X(tCo>CE>C>6C<X(CWC-<6?-<<@w% % $$AA( " FEMF+@ FGDICF(GDICSFGDICRp@Times New Romanv00t00tDt0Dtm0}t0}0" 0  W" 0yDt(DtǾ0Dttdv%    TdP@ \@LTgDay % ( F(GDICC FEMF+*@$??@| EUD^ EUDEjDEqCDEKDE D^ ED| ED}MEDEDSE DSEKDSEqCDSEjDEUD}MEUD| EUD@ff3!b $$>>%  ;D-<X(D-X(XDE>Do>Do>6Io>X(Io>JE>J>6J<X(JWA  % $$AAFdXEMF+@D8L&@A@$$>>_888% % ;D-<X(D-X(XDE>Do>Do>6Io>X(Io>JE>J>6J<X(JW& % $$AAFdXEMF+@D8?A@$$==_888% % ;O6OX(O,wO8iO8Y(X)8s)s)J!X4s)Z!g)f!X)f!H)f!<)Z!<)J!6<)X(<) H)X)Y(iOMOMOX4MOYOiOwOOO=)!Y(X)_"(!)!=<@(% % $$AA( " FEMF+@ FGDICF(GDIC>'FthEMF+*@$??@0$OD:COD% CODC(D`CD`CzRD`C0RD% C0RDJGD0RDDRDDzRDD MRDDRDDRDJGDRD% CRDC MRDBCzRDBCDBCD% CD:CDОCĞD@CD@C(D@CODОCOD:C!UDqDzRDo DUODqD!UDqDC@!b $$==%  ;O6OX(O,yO8kO8Y(4844J!X44Z!4f!4f!4f!4Z!4J!64X(4 44Y(kOOOOOX4OO[OkOyOOO=A5!Y(4_"3!A5!=<>?& % $$AAFdXEMF+@D8?A@$$==_888% % ;O6OX(O,yO8kO8Y(4844J!X44Z!4f!4f!4f!4Z!4J!64X(4 44Y(kOOOOOX4OO[OkOyOOO=A5!Y(4_"3!A5!=<@=(% % $$AA( " FEMF+@ FGDICF(GDICK'FthEMF+*@$??@0$PD:CPD% CPDC1D`CD`CD`C#D% C#DJGD#DD DDDDΊDDDDDJGDD% CDCΊDBCDBCDBCӨD% CӨD:CӨDОCD@CD@C1D@CPDОCPD:C:8DqDDo DUDqD:8DqDC@!b $$==%  ;O6OX(O,wO8iO8Y(pE8EEJ!X4EZ!~Ef!pEf!`Ef!TEZ!TEJ!6TEX(TE `EpEY(iOMOMOX4MOYOiOwOOO=F!Y(pE_"D!F!=<>L& % $$AAFdXEMF+@D8?A@$$==_888% % ;O6OX(O,wO8iO8Y(pE8EEJ!X4EZ!~Ef!pEf!`Ef!TEZ!TEJ!6TEX(TE `EpEY(iOMOMOX4MOYOiOwOOO=F!Y(pE_"D!F!=<@K(% % $$AA( " FEMF+@ FGDICF(GDICf'FthEMF+*@$??@ 0$%D:C%D% CDBCIDBCeDBC큫DC큫D% C큫DJGD큫DDeDDIDDz)DD[DD[DJGD[D% CID`CD`CtўD`CUDCUD% CUD:CUDОCtўD@CD@C D@C%DОC%D:CPDqDIDo DDqDPDqD@ !b $$==%  ;OY(OoOUX(UU U6UJ!X4UZ!Uf!Uf!Uf!UZ!UJ!Y(UU8oO8X(aO8UO,UO6UOX4UOaOoOOOO=BV!Y(U_"T!BV!=<>e& % $$AAFdXEMF+@!D8?A@ !$$==_888% % ;OY(OoOUX(UU U6UJ!X4UZ!Uf!Uf!Uf!UZ!UJ!Y(UU8oO8X(aO8UO,UO6UOX4UOaOoOOOO=BV!Y(U_"T!BV!=<@f(% % $$AA( " FEMF+@ FGDICF(GDIC'FthEMF+*@$??@"0$3&D:C3&D% CDBCD DBC+DBCCDCCD% CCDJGDCDD+DDD DD DDҾDDҾDJGDҾD% CD D`CD`CўD`CUDCUD% CUD:CUDОCўD@CD@CD@C3&DОC3&D:C]DqDD Do DDqD]DqDC@"!b $$==%  ;OY(OoO~_X(__ _6_J!X4_Z!_f!~_f!p_f!b_Z!b_J!Y(b_~_8oO8X(aO8UO,UO6UOX4UOaOoOOOO='`!Y(~__"^!'`!=<>& % $$AAFdXEMF+@#D8?A@"#$$==_888% % ;OY(OoO~_X(__ _6_J!X4_Z!_f!~_f!p_f!b_Z!b_J!Y(b_~_8oO8X(aO8UO,UO6UOX4UOaOoOOOO='`!Y(~__"^!'`!=<@(% % $$AA( " FEMF+@ FGDICF(GDIC'FthEMF+*@$??@$0$%D:C%D% CDBCIDBCzDBCDCD% CDJGDDDzDDIDDDDDDDJGDD% CID`CD`CzўD`CUDCUD% CUD:CUDОCzўD@CD@C D@C%DОC%D:CO!DqDIDo DODqDO!DqD@$!b $$==%  ;OY(OoO`kX(pk|k |k6|kJ!X4|kZ!pkf!`kf!Rkf!FkZ!FkJ!Y(Fk`k8oO8X(aO8UO,UO6UOX4UOaOoOOOO= l!Y(`k_"j! l!=<>& % $$AAFdXEMF+@%D8?A@$%$$==_888% % ;OY(OoO`kX(pk|k |k6|kJ!X4|kZ!pkf!`kf!Rkf!FkZ!FkJ!Y(Fk`k8oO8X(aO8UO,UO6UOX4UOaOoOOOO= l!Y(`k_"j! l!=<@(% % $$AA( " FEMF+@ FGDICF(GDIC'FthEMF+*@$??@&0$ &DC &DkCD)C ]D)CV}D)CD^CDkCD 1DDpDV}D8D ]D8D@D8D(DpD(D 1D(DkC ]D@CD@Cw͞D@CUDxCUDkCUDCUDCw͞D@CD@C D@C &DC &DCNDU\D ]Dx DDU\DNDU\DC@&!b $$==%  ;OY(OoO'yX(7yEy Ey6EyE!X4EyT!7yb!'yb!yb! yT! yE!Y( y'y3oO3X(_O3UO)UO6UOX4UO_OoOOOO=y!Y('yV"x!y!=<>& % $$AAFdXEMF+@'D8?A@&'$$==_888% % ;OY(OoO'yX(7yEy Ey6EyE!X4EyT!7yb!'yb!yb! yT! yE!Y( y'y3oO3X(_O3UO)UO6UOX4UO_OoOOOO=y!Y('yV"x!y!=<@'% % $$AA( " FEMF+@ FGDICF(GDIC'FthEMF+*@$??@(0$&DC&DkCD)C E)CE)C+E^C+EkC+E 1D+EpDE8D E8DE8DEpDE 1DEkC E@CD@Cv͞D@CUDxCUDkCUDCUDCv͞D@CD@C D@C&DC&DCEU\D Ex DeEU\DEU\DC@(!b $$>>%  ;' Y(' 'DX( DDD 6DX4D DDCCCY(C D'X(''' 6' X4' ' ' ' ' ' =WDY(D+CWD=<>& % $$AAFdXEMF+@)D8?A@()$$>>_888% % ;' Y(' 'DX( DDD 6DX4D DDCCCY(C D'X(''' 6' X4' ' ' ' ' ' =WDY(D+CWD=<@'% % $$AA( " FEMF+@ FGDICF(GDIC 'FthEMF+*@$??@*0$ &DC &DkCD)CE)CE)CE^CEkCE 1DEpDE8DE8DE8DEpDE 1DEkCE@CD@Cv͞D@CUDxCUDkCUDCUDCv͞D@CD@C D@C &DC &DCEU\DEx D7EU\DEU\D@*!b $$>>%  ;' Y(' 'KX(KKK 6KX4KKKKKKY(K K'X(''' 6' X4' ' ' ' ' ' =@LY(K+K@L=<> & % $$AAFdXEMF+@+D8?A@*+$$>>_888% % ;' Y(' 'KX(KKK 6KX4KKKKKKY(K K'X(''' 6' X4' ' ' ' ' ' =@LY(K+K@L=<@ '% % $$AA( " FEMF+@ FGDICF(GDIC` 'FthEMF+*@$??@,0$ &DC &DkCD)CA%E)CR%E)C^%E^C^%EkC^%E 1D^%EpDR%E8DA%E8D3%E8D'%EpD'%E 1D'%EkCA%E@CD@Cw͞D@CUDxCUDkCUDCUDCw͞D@CD@C D@C &DC &DC%EU\DA%Ex DϚ$EU\D%EU\D@,!b $$>>%  ;' Y(' 'RX(RRR 6RX4RRRRRRY(R R'X(''' 6' X4' ' ' ' ' ' =RY(R+JRR=<>_ & % $$AAFdXEMF+@-D8?A@,-$$>>_888% % ;' Y(' 'RX(RRR 6RX4RRRRRRY(R R'X(''' 6' X4' ' ' ' ' ' =RY(R+JRR=<@` '% % $$AA( " FEMF+@ FGDICF(GDICFFEMF+*@$??@.D8L&@A@/, UDC>DUD@/.!b $$==_888*% % W$GnOO?t% % $$AA( " FEMF+@ FGDICF(GDIC">}F@4EMF+*@$??@1DC@D DC@D D* D D'D D9GDo D^D D^DV D^DR& D9GDR& D'DR& D* DR& DDV DD DDDDDD)DD)D* D)D(DDC@DDC@Du3DzD DNDDzDu3DzD@1!b $$==%  ;qOtY("t"s"vX4"v"v"v"v"v"v6"sX("s"s"s6qOsX4OsOsOsO tOtqOt=#WvY("w7"Wv#Wv=<>#>z % $$AAFdXEMF+@0D8?A@10$$==_888% % ;qOtY("t"s"vX4"v"v"v"v"v"v6"sX("s"s"s6qOsX4OsOsOsO tOtqOt=#WvY("w7"Wv#Wv=<@!<|% % $$AA( " FEMF+@ FGDICF(GDIC>}F@4EMF+*@$??@2ODC@D4DC@DT 5D* DT 5D'DT 5D9GD4D^D4D^DEZ4D^D)4D9GD)4D'D)4D* D)4DDEZ4DD4DDODDzDD:DD:D* D:D(DzDC@DODC@D67DzD4DND1DzD67DzD@2!b $$==%  ;zOtY(-t;-s;-vX4;-v--v-v-v-v-v6-sX(-s-s-s6zOsX4OsOsOsO tOtzOt=-WvY(-wx,Wv-Wv=<>>z % $$AAFdXEMF+@3D8?A@23$$==_888% % ;zOtY(-t;-s;-vX4;-v--v-v-v-v-v6-sX(-s-s-s6zOsX4OsOsOsO tOtzOt=-WvY(-wx,Wv-Wv=<@<|% % $$AA( " FEMF+@ FGDICF(GDIC>}F@4EMF+*@$??@4DC@D͐eDC@DeD* DeD'DeD9GD5eD^D͐eD^DWPeD^DeD9GDeD'DeD* DeDDWPeDD͐eDDDDDD)DD)D* D)D(DDC@DDC@D-hDzD͐eDNDbDzD-hDzD@4!b $$==%  ;qOtY(]9tw9sw9vX4w9vk9v]9vM9v@9v@9v6@9sX(@9sM9s]9s6qOsX4OsOsOsO tOtqOt=:WvY(]9w8Wv:Wv=<>>z % $$AAFdXEMF+@5D8?A@45$$==_888% % ;qOtY(]9tw9sw9vX4w9vk9v]9vM9v@9v@9v6@9sX(@9sM9s]9s6qOsX4OsOsOsO tOtqOt=:WvY(]9w8Wv:Wv=<@<|% % $$AA( " FEMF+@ FGDICF(GDICf>}F@4EMF+*@$??@6DC@D3ADC@DyD* DyD'DyD9GDaaD^D3AD^D %D^DD9GDD'DD* DDD %DD3ADDDD2DDODDOD* DOD(D2DC@DDC@DDzD3ADNDUDzDDzD@6!b $$==%  ;kOtY(Gt5Gs5GvX45Gv)GvGv GvFvFv6FsX(Fs GsGs6kOsX4{OsOsOsO t{OtkOt=GWvY(GwrFWvGWv=<>g>z % $$AAFdXEMF+@7D8?A@67$$==_888% % ;kOtY(Gt5Gs5GvX45Gv)GvGv GvFvFv6FsX(Fs GsGs6kOsX4{OsOsOsO t{OtkOt=GWvY(GwrFWvGWv=<@e<|% % $$AA( " FEMF+@ FGDICF(GDIC>i}F@4EMF+*@$??@8DDcDDDDѻDDѻD* DѻD'DѻD9GDD^DcD^D$cD^DND9GDND'DND* DcDC@DDC@DDC@DڞD(DڞD* DڞDDDDDDլDzDcDND4DzDլDzD@8!b $$==%  ;Os6UsX(UsUsUs6UvX4UvUvUvUvUvUvY(UsUtOtX4rOtfO tfOsfOsrOsOs=cVWvY(UwUWvcVWv=<>>gz % $$AAFdXEMF+@9D8?A@89$$==_888% % ;Os6UsX(UsUsUs6UvX4UvUvUvUvUvUvY(UsUtOtX4rOtfO tfOsfOsrOsOs=cVWvY(UwUWvcVWv=<@<h|% % $$AA( " FEMF+@ FGDICF(GDIC>g}F@4EMF+*@$??@;ADD,MDD`mDDDDD* DD'DD9GD`mD^D,MD^D0D^DD9GDD'DD* D,MDC@DADC@D DC@D D(D D* D DD DDADDODzD,MDNDDzDODzD@;!b $$==%  ;Os6esX(eseses6evX4evevevevevevY(esetOtX4OtO tOsOsOsOs=FfWvY(ewdWvFfWv=<>>ez % $$AAFdXEMF+@:D8?A@;:$$==_888% % ;Os6esX(eseses6evX4evevevevevevY(esetOtX4OtO tOsOsOsOs=FfWvY(ewdWvFfWv=<@<f|% % $$AA( " FEMF+@ FGDICF(GDIC>X}F@4EMF+*@$??@= ADDmDD֍DDDDD* DD'DD9GD֍D^DmD^DjQD^D?9D9GD?9D'D?9D* DmDC@D ADC@D DC@D D(D D* D DD DD ADDDzDmDNDGDzDDzD@=!b $$==%  ;Os6tsX(tststs6tvX4tvtvtvtvtvtvY(tsttOtX4OtO tOsOsOsOs=XuWvY(twtWvXuWv=<>>Vz % $$AAFdXEMF+@<D8?A@=<$$==_888% % ;Os6tsX(tststs6tvX4tvtvtvtvtvtvY(tsttOtX4OtO tOsOsOsOs=XuWvY(twtWvXuWv=<@<W|% % $$AA( " FEMF+@ FGDICF(GDIC>:{F@4EMF+*@$??@?VDDEDEDEDE* DE'DE9GDE^DE^DE^DE9GDE'DE* DEC@DVDC@D!ޞDC@DʞD(DʞD* DʞDD!ޞDDVDDEzDEND<EzDEzD@?!b $$>>%  ;'96nA9X(uA9}A9}A96}AF;X4}AN;uAT;nAT;fAT;`AN;`AF;Y(`A9nA :' :X4' :':'9'9'9'9=A,;Y(nA;A,;A,;=<>>9z % $$AAFdXEMF+@>D8?A@?>$$>>_888% % ;'96nA9X(uA9}A9}A96}AF;X4}AN;uAT;nAT;fAT;`AN;`AF;Y(`A9nA :' :X4' :':'9'9'9'9=A,;Y(nA;A,;A,;=<@<:|% % $$AA( " FEMF+@ FGDICF(GDIC>{F@4EMF+*@$??@ADD_EDoED{ED{E* D{E'D{E9GDoE^D_E^DrQE^D^EE9GD^EE'D^EE* D_EC@DADC@D DC@D D(D D* D DD DDADDEzD_ENDm EzDEzD@!b $$>>%  ;'96,G9X(4G9:G9:G96:GF;X4:GN;4GT;,GT;%GT;GN;GF;Y(G9,G :' :X4' :':'9'9'9'9=G,;Y(,G;F,;G,;=<>>z % $$AAFdXEMF+@D8?A@$$>>_888% % ;'96,G9X(4G9:G9:G96:GF;X4:GN;4GT;,GT;%GT;GN;GF;Y(G9,G :' :X4' :':'9'9'9'9=G,;Y(,G;F,;G,;=<@<|% % $$AA( " FEMF+@ FGDICF(GDICFEMF+*@$??@\%D5!D\%Djp9D\%Dd9D%D9D~%D9D=%D9D %Dd9D %Djp9D %D5!D %D D=%D D~%D D%D D\%D D\%D5!D4(Dܛ8D~%D̮=D"Dܛ8D4(Dܛ8D@!b $$==%  ;s)F(6s)U.X4s)d.f)p.X)p.H)p.<)d.<)U.6<)F(X4<)8(H),(X),(f),(s)8(s)F(=).Y(X)d/(.).=<> % $$AAFdXEMF+@D8?A@$$==_888% % ;s)F(6s)U.X4s)d.f)p.X)p.H)p.<)d.<)U.6<)F(X4<)8(H),(X),(f),(s)8(s)F(=).Y(X)d/(.).=<@% % $$AA( " FEMF+@ FGDICF(GDICSFthEMF+*@$??@0$%DlUD%D+_D%D^D%D^D%D^D &Di^D &D+_D &DdD &D4eD%D/eD%D/eDP[%D/eD*%D4eD*%DdD*%D+_D%D'_D%D'_DC%D'_D%Db_D%D+_D%DlUD%D4UDC%DUUD%DUUDH%DUUD%D4UD%DlUD2(DcD%D iDU#DcD2(DcD@!b $$==%  ;t)S5Y(t)7Y)7_)7X(p)7|)7|)76|))9X4|)99p)D9_)D9O)D9C)99C))9Y(C)7_)7Y)7X(I)7=)7=)76=)S5X4=)F5I):5Y):5h):5t)F5t)S5=*8Y(_);:(8*8=<>S % $$AAFdXEMF+@D8?A@$$==_888% % ;t)S5Y(t)7Y)7_)7X(p)7|)7|)76|))9X4|)99p)D9_)D9O)D9C)99C))9Y(C)7_)7Y)7X(I)7=)7=)76=)S5X4=)F5I):5Y):5h):5t)F5t)S5=*8Y(_);:(8*8=<@R% % $$AA( " FEMF+@ FGDICF(GDICwFthEMF+*@$??@0$%DSD%DgD%DD%DfD%DfDCfDCgDChDCDCRDCRDCRD1.CD1.ChD1.CgD1.CLDCS4DCS4D%DS4D4"%DgD4"%DSD4"%D7DR%D D%D D%D D%D7D%DSDJCDC DUCDJCD@!b $$==%  ;w)"@6w)CX(w)Ck)C])CY(:CUCU-FX4U=FIIF:IF*IF=F-F6CX(C*C:CY(])CA)CA)"@X4A)@M)@])@k)@w)@w)"@=EY(:@GEE=<>t % $$AAFdXEMF+@D8?A@$$==_888% % ;w)"@6w)CX(w)Ck)C])CY(:CUCU-FX4U=FIIF:IF*IF=F-F6CX(C*C:CY(])CA)CA)"@X4A)@M)@])@k)@w)@w)"@=EY(:@GEE=<@v% % $$AA( " FEMF+@ FGDICF(GDICwFthEMF+*@$??@0$&DSD&DgD&DD%DfD%DfD~%DfD\%DgD\%DhD\%DD%DRD~%DRD=%DRD %DD %DhD %DgD %DLD=%DS4D~%DS4D%DS4D<%%DgD<%%DSD<%%D7DV%D D%D D%D D&D7D&DSD4(DD~%D D"DD4(DD@!b $$==%  ;{)"@6{)CX({)Cn)C^)CY(X)Cs)Cs)-FX4s)=Ff)IFX)IFH)IF<)=F<)-F6<)CX(<)CH)CX)CY(^)CB)CB)"@X4B)@N)@^)@n)@{)@{)"@=)EY(X)@G(E)E=<>t % $$AAFdXEMF+@ D8?A@ $$==_888% % ;{)"@6{)CX({)Cn)C^)CY(X)Cs)Cs)-FX4s)=Ff)IFX)IFH)IF<)=F<)-F6<)CX(<)CH)CX)CY(^)CB)CB)"@X4B)@N)@^)@n)@{)@{)"@=)EY(X)@G(E)E=<@v% % $$AA( " FEMF+@ FGDICF(GDICwFthEMF+*@$??@ 0$@%DSD@%DgDn%DS4D5gDS4D(ngDS4DgDLDgDgDgDhDgDD(ngDRD5gDRDGfDRDfDDfDhDfDgD5gDfDn%DfDK%DfD%DD%DgD%DSD%D7DK%D Dn%D D%D D@%D7D@%DSDiDD5gD DdDDiDD@ !b $$==%  ;v)"@Y(v)CY)C9CX(9C9C9C69-FX49=F9IF9IF9IF9=F9-FY(9C9CY)CX(K)C?)C?)C6?)"@X4?)@K)@Y)@i)@v)@v)"@=m:EY(9@G9Em:E=<>t % $$AAFdXEMF+@ D8?A@  $$==_888% % ;v)"@Y(v)CY)C9CX(9C9C9C69-FX49=F9IF9IF9IF9=F9-FY(9C9CY)CX(K)C?)C?)C6?)"@X4?)@K)@Y)@i)@v)@v)"@=m:EY(9@G9Em:E=<@v% % $$AA( " FEMF+@ FGDICF(GDICFEMF+*@$??@ \%D]D\%D:D\%DD%DĠD~%DĠD=%DĠD %DD %D:D %D]D %D0BD=%D*D~%D*D%D*D\%D0BD\%D]D4(DyD~%DD"DyD4(DyD@ !b $$==%  ;s)'M6s)?PX4s)MPf)[PX)[PH)[P<)MP<)?P6<)'MX4<)MH)MX)Mf)Ms)Ms)'M=)PY(X)PQ(P)P=<> % $$AAFdXEMF+@ D8?A@  $$==_888% % ;s)'M6s)?PX4s)MPf)[PX)[PH)[P<)MP<)?P6<)'MX4<)MH)MX)Mf)Ms)Ms)'M=)PY(X)PQ(P)P=<@% % $$AA( " FEMF+@ FGDICF(GDICFthEMF+*@$??@0$ĴgD]DĴgD僞DĴgDAD?gDźDCgDźDJ+gDźDkgD僞DkgD:DkgDDcgDĠDJ+gDĠDfDĠDfDDfD:DfD僞DfDthDfDPDJ+gDPDCgDPDVfD僞DVfD]DVfD0BDgD*DCgD*D?gD*DĴgD0BDĴgD]DiDyDJ+gDDdDyDiDyD@!b $$==%  ;9'M69:OX(9JO9VO9VOY(9VO9:O9?PX49MP9[P9[P9[P9MP9?P69:OX(9-O9!O9!OY(9!O9:O9'MX49M9M9M9M9M9'M=m:PY(9PQ9Pm:P=<> % $$AAFdXEMF+@D8?A@$$==_888% % ;9'M69:OX(9JO9VO9VOY(9VO9:O9?PX49MP9[P9[P9[P9MP9?P69:OX(9-O9!O9!OY(9!O9:O9'MX49M9M9M9M9M9'M=m:PY(9PQ9Pm:P=<@% % $$AA( " FEMF+@ FGDICF(GDICrFEMF+*@$??@\%D䌮D\%DķD\%DxD%DDD~%DDD=%DDD %DxD %DķD %D䌮D %D!qD=%DUYD~%DUYD%DUYD\%D!qD\%D䌮D4(DYD~%DD"DYD4(DYD@!b $$==%  ;s)?W6s)[X4s)[f)[X)[H)[<)[<)[6<)?WX4<)1WH)%WX)%Wf)%Ws)1Ws)?W=)[Y(X)\([)[=<>r % $$AAFdXEMF+@D8?A@$$==_888% % ;s)?W6s)[X4s)[f)[X)[H)[<)[<)[6<)?WX4<)1WH)%WX)%Wf)%Ws)1Ws)?W=)[Y(X)\([)[=<@p% % $$AA( " FEMF+@ FGDICF(GDICrFthEMF+*@$??@0$B&DDB&Dq6DB&DRD%DiD6%DiD1CiDCq6DCʷDCDǢC6D1C6DC6DOCDOCʷDOCq6DOCDC#D1C#D6%D#D+;%Dq6D+;%DD+;%D qDk%DUYD6%DUYD%DUYDB&D qDB&DDD@`D1C DUC@`DD@`D@!b $$==%  ;)?W6)ZX()"Zr)-Zd)-ZY(-ZZ[X4[[[[[[6ZX(ZYYY(d)YG)ZG)?WX4G)1WS)%Wd)%Wr)%W)1W)?W=f [Y(\[f [=<>r % $$AAFdXEMF+@D8?A@$$==_888% % ;)?W6)ZX()"Zr)-Zd)-ZY(-ZZ[X4[[[[[[6ZX(ZYYY(d)YG)ZG)?WX4G)1WS)%Wd)%Wr)%W)1W)?W=f [Y(\[f [=<@p% % $$AA( " FEMF+@ FGDICF(GDICruFthEMF+*@$??@0$|%D䌮D|%Dvrs % $$AAFdXEMF+@D8?A@$$==_888% % ;m)?WY(m)ZQ)Y6YX(6Y6Z6Z66[X46[6[6[w6[k6[k6[Y(k6Z62ZQ)2ZX(C)2Z7)'Z7)Z67)?WX47)1WC)%WQ)%Wa)%Wm)1Wm)?W=,7[Y(6\5[,7[=<@pu% % $$AA( " FEMF+@ FGDICF(GDIC+sFEMF+*@$??@\%D^D\%DpD\%D D%D0D~%D0D=%D0D %D D %DpD %D^D %DD=%DvD~%DvD%DvD\%DD\%D^D4(DΊD~%DD"DΊD4(DΊD@!b $$==%  ;s)b6s)eX4s)ff)fX)fH)f<)f<)e6<)bX4<)bH)bX)bf)bs)bs)b=)eY(X)g(e)e=<>+q % $$AAFdXEMF+@D8?A@$$==_888% % ;s)b6s)eX4s)ff)fX)fH)f<)f<)e6<)bX4<)bH)bX)bf)bs)bs)b=)eY(X)g(e)e=<@)r% % $$AA( " FEMF+@ FGDICF(GDIC]+tsFthEMF+*@$??@0$ԨZD^DԨZDDԨZDDEyZD{DAZD{D"ZD{D ZDD ZDpD ZD D}aZD0D"ZD0DYD0DYD DYDpDYDDYDDYD̤D"ZD̤DAZD̤DYDDYD^DYDD^ZDvDAZDvDEyZDvDԨZDDԨZD^D\DΊD"ZDDWDΊD\DΊD@!b $$==%  ;6b66dX(6d6e6eY(6e6d6eX46f6f6fs6fg6fg6e6g6dX(g6ds6d6dY(6dm6dm6bX4m6by6b6b6b6b6b=#7eY(6g5e#7e=<>^+sq % $$AAFdXEMF+@D8?A@$$==_888% % ;6b66dX(6d6e6eY(6e6d6eX46f6f6fs6fg6fg6e6g6dX(g6ds6d6dY(6dm6dm6bX4m6by6b6b6b6b6b=#7eY(6g5e#7e=<@\)tr% % $$AA( " FEMF+@ FGDICF(GDICFthEMF+*@$??@0$D5!DD(b/DBD.DD.D D.D$D.#/D$D(b/D$Djp9D$Dd9D D9DD9DKD9DDd9DDjp9DD(b/DD_/DBD_/DD_/DŝD#/DŝD(b/DŝD5!DŝD DD DBD DD DD DD5!D 2Dܛ8DD̮=DDܛ8D 2Dܛ8DD@!b $$==%  ;}kF(Y(}k+ck+qk+X(k+k+k+6kU.X4kd.kp.qkp.akp.Ukd.UkU.Y(Uk+qk+ck+X(Sk+Gk+Gk+6GkF(X4Gk8(Sk,(ck,(qk,(}k8(}kF(=l.Y(qkd/j.l.=<> % $$AAFdXEMF+@D8?A@$$==_888% % ;}kF(Y(}k+ck+qk+X(k+k+k+6kU.X4kd.kp.qkp.akp.Ukd.UkU.Y(Uk+qk+ck+X(Sk+Gk+Gk+6GkF(X4Gk8(Sk,(ck,(qk,(}k8(}kF(=l.Y(qkd/j.l.=<@% % $$AA( " FEMF+@ FGDICF(GDICSFthEMF+*@$??@0$(DlUD(DK`D(D`D3DaDDaDDaDA DK`DA DgDA D=gDDhDDhDyDhD͞D=gD͞DgD͞DK`D͞D [`DyD+`DD+`DD+`DjDK`DjDlUDjD4UDDUUDDUUD3DUUD(D4UD(DlUDd!DfDDkDDfDd!DfD@!b $$==%  ;kS56k8X(k/8k;8qk;8Y(ck;8k8k9X4k9sk9ck9Tk9Hk9Hk96Hk8X(Hk8Tk8ck8Y(qk8Vk8VkS5X4VkF5bk:5qk:5k:5kF5kS5= l9Y(ck:j9 l9=<>S % $$AAFdXEMF+@D8?A@$$==_888% % ;kS56k8X(k/8k;8qk;8Y(ck;8k8k9X4k9sk9ck9Tk9Hk9Hk96Hk8X(Hk8Tk8ck8Y(qk8Vk8VkS5X4VkF5bk:5qk:5k:5kF5kS5= l9Y(ck:j9 l9=<@R% % $$AA( " FEMF+@ FGDICF(GDICSFthEMF+*@$??@0$P'DkUDP'D_DP'D.`D/D]`D D]`DnشD]`DD_DDTfDDfDDfDnشDfDGDfD&DfD&DTfD&D_D&D_DGDZ_DnشDZ_D DZ_DD_DDkUDD4UDDUUD DUUD/DUUDP'D4UDP'DkUD;*D4eDnشD˚jDD4eD;*D4eD@!b $$==%  ;kS56k7X(k8k8rk8Y(eZ8Z7Z9X4Z9uZ9eZ9WZ9KZ9KZ96KZ7X(KZ7WZ7eZ7Y(rk7Vk7VkS5X4VkF5bk:5rk:5k:5kF5kS5=[Y9Y(eZ:YY9[Y9=<>S % $$AAFdXEMF+@D8?A@$$==_888% % ;kS56k7X(k8k8rk8Y(eZ8Z7Z9X4Z9uZ9eZ9WZ9KZ9KZ96KZ7X(KZ7WZ7eZ7Y(rk7Vk7VkS5X4VkF5bk:5rk:5k:5kF5kS5=[Y9Y(eZ:YY9[Y9=<@R% % $$AA( " FEMF+@ FGDICF(GDICSFthEMF+*@$??@!0$@#DlUD@#D3`DD+`D E+`D, E+`D< Eb`D< E3`D< EgD< E=gD, EhD EhD EhD E=gD EgD E3`D EaDDaDDaDD`DD3`DDlUDD,UDDUUDDUUD DUUD@#D,UD@#DlUDw EfD EkD1( EfDw EfD@!!b $$>>%  ;5Y(55DX(DD D6DX4DDDDDDY(DD5X(55565X4555555=8EY(DyD8E=<>S % $$AAFdXEMF+@ D8?A@! $$>>_888% % ;5Y(55DX(DD D6DX4DDDDDDY(DD5X(55565X4555555=8EY(DyD8E=<@R% % $$AA( " FEMF+@ FGDICF(GDIC uFEMF+*@$??@#A DDA D]DA Dz}DD2DD2DyD2D͞Dz}D͞D]D͞DD͞DcDyDDDDDDA DcDA DDd!DDDbDDDd!DD@#!b $$==%  ;k@6k'FX4k7FskCFckCFTkCFHk7FHk'F6Hk@X4Hk@Tk@ck@sk@k@k@= lEY(ck8GjE lE=<> t % $$AAFdXEMF+@"D8?A@#"$$==_888% % ;k@6k'FX4k7FskCFckCFTkCFHk7FHk'F6Hk@X4Hk@Tk@ck@sk@k@k@= lEY(ck8GjE lE=<@ u% % $$AA( " FEMF+@ FGDICF(GDICpFthEMF+*@$??@%0$D+DDDDUDMDDߴDDϴDD1DD1DċD1D2DiDDϴDDDD.D2D.DċD.DD.DkDDjSDϴDjSDߴDjSDDDD+DD\DڿDDߴDDMDDD\DD+DDVDϴDcDDVDDVD@%!b $$==%  ;Z@6ZCX(ZCvZChZCY(`ZC|ZC|ZEX4|ZEpZE`ZERZEGZEGZE6GZCX(GZCRZC`ZCY(hZCMZCMZ@X4MZ@XZu@hZu@vZu@Z@Z@=[EY(`ZFYE[E=<>o % $$AAFdXEMF+@$D8?A@%$$$==_888% % ;Z@6ZCX(ZCvZChZCY(`ZC|ZC|ZEX4|ZEpZE`ZERZEGZEGZE6GZCX(GZCRZC`ZCY(hZCMZCMZ@X4MZ@XZu@hZu@vZu@Z@Z@=[EY(`ZFYE[E=<@q% % $$AA( " FEMF+@ FGDICF(GDICFthEMF+*@$??@'0$zD~DzD$D2δDDڴDDDDAD\ DAD$DADDADžDDHڞDڴDHڞDyDHڞD͢DžD͢DD͢D$DڴD\D2δD\DD\DDuDDD$DD~DDDDUsD2δDUsDDUsDzDDzD~Dd%D4DڴDʠDD4Dd%D4D@'!b $$==%  ;yZLY(yZN`ZqNeZqNX(uZqNZ}NZN6ZJOX4ZZOuZfOeZfOVZfOJZZOJZJOY(JZNeZN`ZNX(PZNBZNBZN6BZLX4BZLPZL`ZLmZLyZLyZL= [OY(eZ^PYO [O=<> % $$AAFdXEMF+@&D8?A@'&$$==_888% % ;yZLY(yZN`ZqNeZqNX(uZqNZ}NZN6ZJOX4ZZOuZfOeZfOVZfOJZZOJZJOY(JZNeZN`ZNX(PZNBZNBZN6BZLX4BZLPZL`ZLmZLyZLyZL= [OY(eZ^PYO [O=<@% % $$AA( " FEMF+@ FGDICF(GDICcFthEMF+*@$??@)0$DDD|DD'DMDDߴDDϴDD1D|D1DFD1D'fDiD}DϴD}DD}D.D'fD.DFD.D|D.DOaDDIDϴDIDߴDIDD|DDDDDڿDvDߴDvDMDvDDDDDDܳDϴDhDDܳDDܳD@)!b $$==%  ;ZMV6ZXX(ZXvZXhZXY(`ZX|ZX|ZZX4|Z,ZpZ7Z`Z7ZRZ7ZGZ,ZGZZ6GZXX(GZXRZX`ZXY(hZXMZXMZMVX4MZ?VXZ3VhZ3VvZ3VZ?VZMV=[YY(`Z-[YY[Y=<>c % $$AAFdXEMF+@(D8?A@)($$==_888% % ;ZMV6ZXX(ZXvZXhZXY(`ZX|ZX|ZZX4|Z,ZpZ7Z`Z7ZRZ7ZGZ,ZGZZ6GZXX(GZXRZX`ZXY(hZXMZXMZMVX4MZ?VXZ3VhZ3VvZ3VZ?VZMV=[YY(`Z-[YY[Y=<@a% % $$AA( " FEMF+@ FGDICF(GDIC tFthEMF+*@$??@+0$S EDS EiDS E8DD EOD0 EODDOD5DiD5DLD5D^hDDDDDtDDXD^hDXDLDXDiDXDDtDDDD0 ED EiD ED EtD ED0 EDD EDS EtDS EDD݋DDnDUGD݋DD݋D@+!b $$>>%  ;Dm 6D"X(D "D"D"Y(b?"o?"o?#X4o?#i?#b?#Z?#S?#S?#6S?"X(S?!Z?!b?!Y(D!D"Dm X4De D` D` D` De Dm =?"Y(b?#?"?"=<> s % $$AAFdXEMF+@*D8?A@+*$$>>_888% % ;Dm 6D"X(D "D"D"Y(b?"o?"o?#X4o?#i?#b?#Z?#S?#S?#6S?"X(S?!Z?!b?!Y(D!D"Dm X4De D` D` D` De Dm =?"Y(b?#?"?"=<@ u% % $$AA( " FEMF+@ FGDICF(GDIC C tFthEMF+*@$??@-0$ ED EiDn EDiEDwED˅ED˅EiD˅ELD˅E^hDwEDiEDYEDME^hDMELDMEiDiEODn EOD_ EODU E8DU EiDU EDU EtD_ EDn ED~ ED EtD EDSE݋DiEnDE݋DSE݋D@-!b $$>>%  ;Dm Y(D"D!I!X(I!I!I"6I#X4I#I#I#I#I#I#Y(I"I"D"X(D"D "D"6Dm X4De D` D` D` De Dm =J"Y(I#^I"J"=<> A s % $$AAFdXEMF+@,D8?A@-,$$>>_888% % ;Dm Y(D"D!I!X(I!I!I"6I#X4I#I#I#I#I#I#Y(I"I"D"X(D"D "D"6Dm X4De D` D` D` De Dm =J"Y(I#^I"J"=<@ C u% % $$AA( " FEMF+@ FGDICF(GDIC, C !FthEMF+*@$??@.0$EMDE$DekED7wEDEDʒEODʒE$DʒEDʒEDE)D7wE)DmiE)D]ED]ED]E$D7wE[DekE[D[E[DOEDDOE$DOEMDOE1D[EDekED/yEDE1DEMDEńD7wE DEńDEńD@.!b $$>>%  ;I&Y(I'I'I'X(I'I'I'6Ix(X4I(I(I(I(I(Ix(Y(I'I'I'X(I'I'I'6I&X4I&I&I&I&I&I&= J^(Y(I(hI^( J^(=<>- B  % $$AAFdXEMF+@/D8?A@./$$>>_888% % ;I&Y(I'I'I'X(I'I'I'6Ix(X4I(I(I(I(I(Ix(Y(I'I'I'X(I'I'I'6I&X4I&I&I&I&I&I&= J^(Y(I(hI^( J^(=<@+ C "% % $$AA( " FEMF+@ FGDICF(GDIC, }C FEMF+*@$??@0ʒEDʒEHܴDʒEDED7wEDmiED]ED]EHܴD]ED]EϯDmiEUD7wEUDEUDʒEϯDʒEDEmD7wE DEmDEmD@0!b $$>>%  ;I+6I4-X4I:-I@-I@-I@-I:-I4-6I+X4I+I+I+I+I+I+= J-Y(I-hI- J-=<>- }B  % $$AAFdXEMF+@1D8?A@01$$>>_888% % ;I+6I4-X4I:-I@-I@-I@-I:-I4-6I+X4I+I+I+I+I+I+= J-Y(I-hI- J-=<@+ {C % % $$AA( " FEMF+@ FGDICF(GDIC+ C fFthEMF+*@$??@30$UEDUEDUEIDEDvEDpEDtEDtEvDtED~ḘDpḘDaḘDEUEDEUEvDEUEDEUEDaE\DpE\DvE\D.[ED.[ED.[E\DhEDvEDEDUE\DUED]E DpEcDUE D]E D@3!b $$>>%  ;I06I1X(I1I1I1Y(I1I1I2X4I2I2I2I2I2I26I1X(I1I1I1Y(I1I1I0X4I0I0I0I0I0I0=J2Y(I#3dI2J2=<>, A e % $$AAFdXEMF+@2D8?A@32$$>>_888% % ;I06I1X(I1I1I1Y(I1I1I2X4I2I2I2I2I2I26I1X(I1I1I1Y(I1I1I0X4I0I0I0I0I0I0=J2Y(I#3dI2J2=<@+ C f% % $$AA( " FEMF+@ FGDICF(GDICCkFGDICRp@Times New Romanv00t00tDt0 Dtm0} t0 }0" 0  W" 0y Dt(Dt Ǿ0Dt tdv%    TEi@ \@c Ldbase64Binary   % ( FGDICF4(EMF+*@$??!b Ld  )??" FEMF+@ CompObjuObjInfoPicturesCurrent UserY J. BeckerleOh+'0 X`p  Slide 2Michael J. BeckerleMichael J. Beckerle1Microsoft Office PowerPoint@q@u^՛@`՛-՜.+,0 SummaryInformation( 4PowerPoint Document(>ZDocumentSummaryInformation81Table  ( `/ 0DArialNew Romantt-a0DTimes New Romantt-a0@ .  @n?" dd@  @@`` x  0AA@@80___PPT10 :   0` 33` Sf3f` 33g` f` www3PP` ZXdbmo` \ғ3y`Ӣ` 3f3ff` 3f3FKf` hk]wwwfܹ` ff>>\`Y{ff` R>&- {p_/̴>?" dd@,|?" dd@   " @ ` n?" dd@   @@``PR    @ ` ` p>> f(    6*  `}  T Click to edit Master title style! !  0  `  RClick to edit Master text styles Second level Third level Fourth level Fifth level!     S  0L1 ^ `  >*  0> ^   @*  04A ^ `  @*H  0޽h ? 3380___PPT10.pM" Default Design 0  (  L"  c $G  L"  c $G l@@F     N"  S G0*  T"  c $G G(  # B CPDEHF03ffb,,b#,ObO O O #  b , bb@    "`2z "  6QG    anySimpleType&.]'  6 @ @ @    BCKDEHF03ff̙b,+a,JbJJJa+bb@    ]5"   <_G YE string&.]'  6 @ @ @   B|CKDEHF0a++a+JaJJOJ{{{a{+Oaa@    5 "   <dG Y QName&.]'  6 @ @ @   B\CKDEHF0a++a+JaJJ0J[[[a[+0aa@    s5: "  <oG Y  NOTATION& .] '  6 @ @ @   BCKDEHF03ff̙b,+a,JbJmJJa+mbb@     5  "  < ~G  Y  float&.]'  6 @ @ @   BCKDEHF03ff̙a++a+JaJJJa+aa@     5 "  < G  Y  double&.]'  6 @ @ @   BCLDEHF03ff̙a++a+KaKKTKa+Taa@    ; 5 "  <|G s YI  decimal&.]'  6 @ @ @   BCLDEHF03ff̙b++a+KbK7KnKa+n7bb@     59"  < G Y boolean&.]'  6 @ @ @F  # BXCLDEHF0b++a+KbKK+KWWWaW++bb@    c"$ `S5W(  # BCLDEHF03ffb++a+KbK.KeKa+e.bb@    "`p5"  <4G Y  hexBinary& .] '  6 @ @ @  BbCLDEHF0b++a+KbKK5Kaaaaa+5bb@    05|"  <G fY@ anyURI&.]'  6 @ @ @  B CPDEHF0a+,b#+OaOy O O #  b , y aa@    (R"  <G 4 normalizedString&.]'  6 @ @ @  BjCPDEHF0c,,b#,OcOO=Oi#iibi,=cc@    p "  <ʊG 6C token&.]'  6 @ @ @   B0CMDEHF0b,,b ,LbLLL/ //b/,bb@    $/ " ! <,֊G   language& .] '  6 @ @ @ " BCMDEHF0b,,b ,LbLEL{L b,{Ebb@    h/  " # <G ?  Name&.]'  6 @ @ @ $ B,CMDEHF0a+,b +LaLLL+ ++b+,aa@    / " % < G J  NMTOKEN&.]'  6 @ @ @ & BCPDEHF0a+,b#+OaOOO#b,aa@     d " ' <G 3 F  NMTOKENS& .] '  6 @ @ @ ( B:CPDEHF0b,,b#,ObOO O9#99b9, bb@    7 d " ) <4G m iF  NCName&.]'  6 @ @ @ * BCHDEHF0a++a+GaGwGGa+waa@    x= )  " + <GQ a   ID&.]'  6 @ @ @ , BCHDEHF0a++a+GaGGGa+aa@    ]=   " - <@G a \  IDREF&.]'  6 @ @ @ . BCHDEHF0a++a+GaG=GsGa+s=aa@    = = " / <\%G a   ENTITY&.]'  6 @ @ @ 0 BCHDEHF0a++a+GaG`GGa+`aa@    Et  " 1 <G } i  IDREFS&.]'  6 @ @ @ 2 BCHDEHF0a++a+GaG<GrGa+r<aa@    t Y " 3 <p8G  (  ENTITIES& .] '  6 @ @ @ 4 B CPDEHF0a,,b#,OaOOO #  b ,aa@    J  R" 5 <CG  B 4 integer&.]'  6 @ @ @ 6  BCKDEHF03ff̙a++a+JaJnJJa+naa@    f Q  " 7 <OG  D  long&.]'  6 @ @ @ 8 B CKDEHF0b++b+JbJH J~ J   b +~ H bb@     )." 9 <ZG  M  nonPositiveInteger&.]'  6 @ @ @ : B" CKDEHF0a++b+JaJ J J! ! ! b! + aa@    3)" ; <eG iM nonNegativeInteger&.]'  6 @ @ @ < B+ CLDEHF0b,+b ,KbKKK* * * b* +bb@      . " = <qG     negativeInteger&.]'  6 @ @ @ > BCKDEHF0a++a+JaJcJJa+caa@    )G- " ? <}G a  positiveInteger&.]'  6 @ @ @ @  BCKDEHF03ff̙a++a+JaJJSJ~~~a~+Saa@    - " A <dG i   unsignedLong& .] '  6 @ @ @ B  BNCPDEHF03ff̙b,+b$,ObOO"OM$MMbM+"bb@     z " C <G  R\   unsignedInt& .] '  6 @ @ @ D  BCPDEHF03ff̙b+,b$+ObONOO$b,Nbb@      " E <tG 4 o}   unsignedShort&.]'  6 @ @ @ F  BFCKDEHF03ff̙a++b+JaJJJEEEbE+aa@    \  " G <䪎G  \   unsignedByte& .] '  6 @ @ @ H  BCGDEHF03ff̙a++a+FaFFFa+aa@     2 "  " I <G     int&.]'  6 @ @ @ J  B-CMDEHF03ff̙a++a+LaLLL,,,a,+aa@    Z \ G  " K <G  )  short&.]'  6 @ @ @ L  BCPDEHF03ff̙a+,b#+OaOjOO#b,jaa@    f  Q  " M <͎G  ,  u  byte&.]'  6 @ @ @ N  BCLDEHF03ff̙b,+b ,KbKzKK b+zbb@    r " O <h؎G i date&.]'  6 @ @ @ P  BCLDEHF03ff̙a++b +KaKmKK b+maa@    r " Q <G / time&.]'  6 @ @ @ R  BCCLDEHF03ff̙b++b +KbKKKB BBbB+bb@    $r" S <t;G Y] dateTime& .] '  6 @ @ @ T BCLDEHF0b++b +KbKEK|K b+|Ebb@    r  " U <G 2 gYear&.]'  6 @ @ @ V BCLDEHF0a++b +KaK<KrK b+r<aa@    _ r5 " W <G     gYearMonth& .] '  6 @ @ @ X BaCLDEHF0a++b +KaKK3K` ``b`+3aa@     r " Y <G    gMonth&.]'  6 @ @ @ Z BFCLDEHF0b++b +KbKKKE EEbE+bb@     r" [ <HG Y   gMonthDay& .] '  6 @ @ @ \ BLCLDEHF0a++b +KaKKKK KKbK+aa@    3r< " ] <$G j gDay&.]'  6 @ @ @ ^  BCLDEHF03ff̙b++b +KbKEK{K b+{Ebb@    hr" _ </G  duration& .] '  6 @ @ @z `  JBMC^DEF`!!LL5L=EC>CSC`5``ZSKEEE5E-K'S'>'05006>ELLLS]-0@      `@` !z a  JB C^DEF`!!  5 = C CRC`5``ZRKEEE5E-K'R' ' 5     R]-0@      `@`= !z b  JBYC^DEF`!!XX5X=QCJCSC`5``ZSKEEE5E-K'S'J'<5<<BJQXXXS]-0@      `@`B !z c  JBsC^DEF`!!5 ' '''.-.5..' 5 C CC=5 r ]rr-0@      `@` [ !z d  JBYC^DEF`!!5 '' '-5 5C CC=5 X]XX-0@      `@`  !z e  JBEC^DEF`!!5 ' ' ' - 5        5 C CC=5 D ] DD-0@      `@`  !z f  JBC]DEF`!!5 '''-55B BB=5 \t-0@      `@`  z g  JBC]DEF`!!5 '*'2'9-95992*#5*B BB=5 ~*\~~-0@      `@` h z h  JBZ$C]DEF`!!5 '$' $'$-$5$$ $$####5$B BB=5 Y$$\#Y$Y$-0@      `@` N z i  JB*C]DEF`!!5 '*'*'*-*5********5*B BB=5 **\X***-0@      `@`  HB j C D  R k  "BCDElFPwS` `Z`bZhShKhEbEZE EKSw ww?S???%(@     `@` \R l  "BuCDElFPfSa aZabZhShKhEbEZE EKSfmtt tmff?S???%(@     `@`W \R m  "BX CDElFPI S` `Z`bZhShKhEbEZE EKSI Q W W W Q I I ?S???%(@     `@` \R n  "BCDElFPvSa aZab[hShLhEbEZE ELSv~ ~vv?S???%(@     `@`u \R o  "ByCDElFP$,22 2Z2b,h$hhbZ $ x?$?x?x?%(@     `@` _ \R p  "BR CDElFP   Z b h h h b Z    Q ?  ?Q ?Q ?%(@     `@` G \R q  "BCDElFP w ZbhwhphjbjZj w   ?w$???%(@     `@` \R r  "BCDElFP  ZbhhhbZ    ?B???%(@     `@` \R s  "BCDElFP 7?EE EZEb?h7h0h*b*Z* 7   ?7???%(@     `@` *\* t  BCDETF@_ _!_)Y/R/J/D)D!D DJRY__ _ R @    `@` z u  JBCDEF`!!\ \IO;R;Z;`A`I``Z R J DDDIRWOWGWAPAIA AGOV\\ \ R-0@      `@`d z v  JBCDEF`!! S```!Z'S'K'E!EEEKS   S-0@      `@`Pz w  JBCDEF`!!c cc]UR___!Y'R'J'D!DDDJRUGG GMU]cc c R-0@      `@` z x  JBCDEF`!!  4;AAAA!;'4','&!&&4     4-0@      `@`* y  BC-DETF@_ __YRJDDD DJRY__ _ R, @    `@`@  z z  JBC-DEF`!!e ee$_*W*T*aaa[TLEEEELTWII IOW_ee e T,-0@      `@`@  * {  BCDETF@_ _`_hYnRnJnDhD`D DJRY__ _ EREEE @    `@`v ( z |  JB)CDEF`!!( (|(!Sa|adalZrSrKrElEdE|EtKnSnn |  !(( ( ISIII-0@      `@`v ( z }  JBCDEF`!! | nnnt|`hnnnh`| |    ELEEE-0@      `@`v ( * ~  BC1DETF@_ __YRJDDD DJRY__ _ R0 @    `@` ^ z   JBC1DEF`!!b bb$\*U*Q*___YQJDDDDJQUGG GMU\bb b Q0-0@      `@`x ^ z   JBCDEF`!!X XKRY___!_)Y/R/J/D)D!DRKC=== =CKRXX X R-0@      `@`  z   JBCDEF`!!i iwic[Tbwb[bc\iTiLiFcF[FwFoLiTi[iMwM MS[cii i ?T???-0@      `@` d z   JBCDEF`!! ckqqRq`c`3`;ZARAKAE;E3EcE[KURUUc   R-0@      `@` d z   JBzCDEF`!! x i%i-i3p3x3[3c-i%iic[x% x    y?%?y?y?-0@      `@` d*   BCGDETF@b bb\TLFFF FLT\bb b TF @    `@`  z   JBCHDEF`!!b bb\UQ___YQJDDDDJQUGG GMU\bb b QG-0@      `@`  z   JBCDEF`!!^^QT\bbbQbY\_T_L_FYFQFTQIBBBBIQX^^^5T555-0@      `@` 5 z   JBCDEF`!!b bHbP\VUVQV_H__Y Q J DDDHDAJ;Q;U;GHG GMU\bb b Q-0@      `@` Y z   JBCBDEF`!! S```ZSKDDDDKS   SA-0@      `@`#z   JB(CBDEF`!!       'A''-0@      `@`z   JBCDEF`!!X XIK<Q<Y<_A_I__YQJDDDIQWKWCW=Q=I= =CKRXX X Q-0@      `@`?  *   BCDETF@__M_TYZQZJZDTDMDDJQY___1Q111 @    `@`  z   JBCDEF`!!c cKcS]YUYRY_K__Y R J DDDKDCJ>R>U>GKG GNU]cc c R-0@      `@` G "  <GG Y  base64Binary" .] #  6 @ @ @H  0޽h ? 3380___PPT10.p$P"r0    QOn-screen ShowIBMZ- ArialTimes New RomanDefault DesignSlide 2  Fonts UsedDesign Template Slide TitlesOh+'0 !V@M U Q|DD )H"J|4GOb"xΝw͞sΜ3̜oޫ@oHG^"닡pfa hv b4+!oTby/`pPCDBucK )gIvʈd"plK{aVS:D=l.ݾϲOVB2/$~FAT O*uv P `]puB:IN]Jv8BÌc?hOGFu ?ʉ[yOđϧtM/rucڊjʦ,آ9F<}&LrW/jʭeP^ihhM9l.K.W귰:mbyl.# Uy#''I.GrZuYyKccxnh=قV"IC8/b( >4ZW"H 8ށ l3PiUQ=!%=SC4y IEJ%EC!G X&puaX5jjR?)EZ;S1H(~)nvӁ <;})]}/2F{}w7a%yk4u?twl؍QO7U?':i+` T@%R5Je9d^fIBWvn ___7Pח.k6_alyzVKx#^KBqҽ,OcxLy\7N<X908uGTUx;qU׶M4YEJ"o[\Kg ^⚦=3,~57Ni898a87Xc8Y8;w-X.EX<ȉs&qbp'jqB {-wT={yGgWP;" co ϵɄ υ/ f=['K"0{̃6cvag<}iZ$>o1O%q1ώ{Xnc`~aJa9C`^< ע\zH(fag}A9oe[G DGQ(7iK?aaaCl4x ^}7|7|EE?b| :8 | X>RIba&v< "z"%q))G8%QJ]K|u"ɯ4u,0pl,2 Cȿ-Vze*эcDDmV*糗k9wՈ)<+h6Bϰ; `M FzU92~r^*͝_Q8thYwc3 Yc29>sk~XN8笼r:g5~d}sAHq횯Ǜtş]}.qcΠ-3^ZMÞ=/9^\EUEF[ws{?wcYJj7}Yjڠ^r8}qadz{$:@q9N8NI,B3{4}3b>DYzxU(^S?4&bkO4 i@lr!΅LsEEOJc{C|^J+=0ŏ=tFN>*V>~T6$ qp t쟐#|gY: ;=ԆVЂޛASh&Ѧ15Fh횢asl4n bk| 1G=J:Jo}9fCY!ZzCe,guOI E{Yq7.,?Ws( RgQC 3! %v,=T{0Bک´ N`a>6$ @8zO?sՀpsWIMII͑^uTjD- _>l;O!_sC8DC܅q3>vSOkX{wHж98uRra]*;CU_wJ<8Q?H -,Z(tΡ9;Q`|3a" fë:9-|3eXx;?4 0h|Ӏh zB0^k8J|2'h MׄkBIh~Z"C hs?Gl[][z] ;6zC=Zo- ab9(zBzR?9eTI'&tV߃9}׫0_Νg`7?zWP,RȆ |c9)b-ҟ1g}.|w=C=M]s}Ɯ2԰zB>=Y&-ob2#gARnH6HF=1FwmM X 90<|7MF^l2j@MѨ-67Ҹ]eܦ6c?㌺Ȁm cw1d4dX`r#3*J1"|F;Ģ28Nʞso]:kk|yGzMy kڲ~ב5[AOs O"Ml $YeKV3Fyduiy]:܄ombj[5SO/eSwWΗ;{ QS6Ƣ[Ԗwd#@]OC7g>"7Icp NSib{gu]sgcpzBDYvT?p{q̻3K~;=#mP˗۵PQvvVܩ0?jji/mքE-i,juf]Q PEU7=-odMN=zGCsuΣOg Ĭ#va3[a;cߝJc}9dx ь'ļ@pr 7zBWxǵ\+@djL~1۴^4A8Va >1qĶOpxʵ~ݶZA rl,|$:1XAMw z>F+)9-Wζ)B?zN.` pOM>ۇm}q83D99 vl{ǧ 999k/sa]8vY~~>WR{+\ʼW2W=\ Pge'|3*ˆn26"f$H7zB.5ZKWˬG~h$mzX/*͞CU0:|؍F?Ho4 #Ϳxο5W Ȁ26EHbɑn8z=#,g=\zR? V޳a Z,BfG={ ChmGEhͳ~9,7K!`,+u*;ȱU2`ȵ]J2bX`g{^j~`/fE+{ a؆06T|3`:zOx{{OUUϺ>IÌQyc 6,_0tce /-gl%>9&f kѰ 6l2~L'~BO 9?&N\26ũ'U{;QS~/賃6@FWVIKV=eLdnNu|#qbKydC~Mab0krbB:Ȝ̽@MY)_^9J}TdLrLkd\+u^` gL3nHiI |e,|s8@Og̹'ovO&{9NНAyIk86:MeXǵ$ m#cقVb v۬bGlV?/ &$lgGXrz9ePl`E3ot>42PhJMC(7P} }eo[p}UAlU7Z<ȅ0 D2xb)=f,V;'|wsZY3hB1t܈ΣQ!J4D;QNjR Q,` J6Af(q83Yb~$GrHy?0*bΓ}SO;tuw5~k89;U.Gcp1ΪodL֭$ m#cقVb݊bf|V໒UĮ"*r"Jr`+92"jXN=Mlz=?()BlR~js!.5 P%uQ)QA,DC{f 6#)XֿFȳ>0I0 |&;qĎ%XhH?g+>%9w}P1 T2Z9 3[~se4'Z9 &C.af|໕mn* oa{wb ɵ =9e-K s'Կm6Ji_3Ț^C߻st =>EOSt>EO3t=w݋6kZimrjkʃ\ Md, 'fc1*摞'LDw+)Z'8 |ߢ7(sa;rQJ~ߢw(|O)nmV5l7Zi<ȅ0 D2xb;c-PMlwz!|įRL: /Kt<'_Q"E2P&2P(6&K(2NEL[wCc{j5X-VjeA.LI&2|3XE'粲ShӒRm {73cզlQ_+RЦZ(H%yL)HmWLG}Ir$Ic1i^Vdr,28fyϴ_g}VVA#}sw_mZ;"Khv=_S#ʻGfђck%vo+YZJ> c{܈QG] FbWmAE{J^ފW[3tꞐ.O|S"œ(aw) Rj9t{nO{ݞQV$r,:rLt%Jo+YZ[tzF(HpNC).foG9wJ,RsLe+ R8,3Ka"bEu7w8J,+_J?VrO{(x^xn)pVx&{_E$TbNg,+\ux<~Vj!Xi}oFiEE>@?(鑮*P@w W `xJ+x+6vIWCЁM'v WDB( ;oGH8#+v)^ ފu si9aD_>Gz]b%iuF xv>o1㷮w#ĵWu-V43O*uvawZ2t뢤nZ+vSN:qG+p5.^2XH͡5.[K^}k·+[ TH5<`sk 8@ -NNcw/`V/=~w*5+^ZWxx5uia=%[XO˖ч1֓P$A,6,Pu+]MȽ{D|㷪\|i`'֓fK)I'>'̾\j99D|^=\)ux;j$ŃVE;ՖCvX+VWŊVw`;Wm;)[S)UiϊL\^Vd)Oѧ^8q#Saxc8tX|\2]/%&aC+,ߺ*j|o$S#S4hfLS47z)E"X1=)4QӘ)B~BSLT l׺f|qG?5)+di=әi:UMup iDNbzx]5QLn6Ý%Ktc,JJkҩnؘ&M$(fL=M ME)t;};WF4c2ǹ&C[JcO;͐B* S1ŀA.2cGO|]#'+.3r.,)gz;~3+f`؁}vيk䍔9)+\#1k$}㱚=2(r< U1U %.i,!k$5\#5'49] 1Q{]^X-RFU?(rUY-K#LYtv4Nn+XA܇{m:wlVx+[ZW&KֳdQ㱚RxurNwɗE{v Kl3S=~*ާTU&*^ .WY7yL)gԇzOdڥ"K<}1#\pk,]r}ft$ڻ5{2^ސ[} K^W ҟb| AJo+YZd9FdRsXي*8ؾR,K/a| ~\9b4c.<ܹ]֚Nw9t%Jo%y[̮0ZVїRƞmΆW9dawYk"R,5G*kk.e֜|k=]ɲ[J^`d:Qeϓ7b.'79ι cc.t](}&DžYVx+5.&}62?E (f3a]fËK;wlIw7?ds=~*j K)glmv23Act XjW,SPAXǵ>+ƒk whIۘ'As\7kbxx |ȦЄ&4ܱfask[@>x1@6Xi}3Onc+\'y| '=N1v 9Na7l?UοX(g̔39.Vs{'<r. 5\M7#M["$`e] lluOz).S`w l,,oƷV,tQEv#v8a(Z2֒ r 8V;gQ#лd()^k + 8U5[wCz`sH`|^aVeS!Ч`Xk hlGŒQ4cw.K#K:CshõEA$.wUhRb,ϱGFYd/WR@QUǧ&6n?hVR/F~׶|2 2 _^&@& TOC 3 `^&@& TOC 4 aX^X&& TOC 5 b ^ && TOC 6 c^&& TOC 7 d^&& TOC 8 ex^x&& TOC 9 f@^@>V@q> FollowedHyperlink >*B* ph@@  Balloon TexthCJOJ QJ ^J aJ88 Comment Subjecti5\8&@8 Footn i@@@ NormalxOJQJ_HaJmH sH tH N@N Heading 1$ & Fx<@&5KH \^JaJ F@F Heading 2$ & F@&5\]^JaJJ@J Heading 3$ & F@&5OJ QJ \^JaJN@ABN Heading 4$ & F<@&5OJQJ\aJLL Heading 5 & F<@&56CJ\]aJNN Heading 6 & F<@&5CJOJQJ\aJDD Heading 7 & F<@& CJOJQJJJ Heading 8 & F<@&6CJOJQJ]D D Heading 9 & F<@& CJ^JaJ<A@< Default Paragraph Font&O& nobreak$DOD nobreak CharOJQJ_HaJmH sH tH POP Char Char5*5KH OJQJ\^J_HaJ mH sH tH PO!P Char Char4)5OJQJ\]^J_HaJmH sH tH LO1L Char Char3&5OJ QJ \^J_HaJmH sH tH :OB: normal$`a$ OJQJaJ8OQ8 normal Char1_HmH sH tH 8ORa8 Char Char25OJQJ\aJPrP HTML Body 7$8$H$ CJOJ QJ _HaJmH sH tH ,@, Header  !BOB Char Char1OJQJ_HaJmH sH tH , @, Footer  !.U@. Hyperlink >*B*ph&)@& Page NumberDTD Block Texth]^h CJOJQJ4"@4 Caption xx 5\aJ,^@, Normal (Web)@Z@ Plain Text ^OJQJ^J aJ*B* Body Text!x4P"4 Body Text 2 "dx6Q26 Body Text 3#xCJaJHMBH Body Text First Indent $`@CR@ Body Text Indent%hx^hLNQbL Body Text First Indent 2 &`JRrJ Body Text Indent 2'hdx^hLSL Body Text Indent 3(hx^hCJaJ*?* Closing )^0@0  Comment Text*aJL Date+JYJ  Document Map,-D M OJ QJ ^J 4[4 E-mail Signature-0+0  Endnote Text.aJ\$\ Envelope Address!/@ &+D/^@ CJ^J:%: Envelope Return0^JaJ2@2  Footnote Text1aJ2`"2 HTML Address26]Fe2F HTML Preformatted3OJQJ^J aJ@OA@ Char CharOJQJ^J _HmH sH tH 2 2 Index 158^`82 2 Index 268^`82 2 Index 37X8^X`82 2 Index 48 8^ `822 Index 598^`822 Index 6:8^`822 Index 7;x8^x`822 Index 8<@8^@`822 Index 9=8^`88!R8  Index Heading> 5\^J,/, List?h^h`020 List 2@^`030 List 3A8^8`04"0 List 4B^`(5@2( List 5 C & F*0@B* List BulletD66R6 List Bullet 2 E & F67b6 List Bullet 3 F & F68r6 List Bullet 4 G & F696 List Bullet 5 H & F:D: List ContinueIhx^h>E> List Continue 2Jx^>F> List Continue 3K8x^8>G> List Continue 4Lx^>H> List Continue 5Mx^21@2 List Number N & F6:6 List Number 2 O & F6;6 List Number 3 P & F6<6 List Number 4 Q & F 6="6 List Number 5 R & F d-2d  Macro Text"S  ` @ OJQJ^J _HmH sH tH IB Message HeadergT8$d%d&d'd-DM NOPQ^8`CJ^J6R6 Normal Indent U^,O, Note HeadingV(K( SalutationW.@. Signature X^:J: SubtitleY$<@&a$CJ^JL,L Table of AuthoritiesZ8^`8D#D Table of Figures[p^`pF>@F Title\$<@&a$5CJ KH\^JaJ <.<  TOA Heading]x5CJ\^J@ TOC 1^&@& TOCote ReferenceH*.O. SemanticLabelH*vv ToDoWl$d%d&d'd-DM NOPQ588 normal Charm$`a$LOL normal Char CharOJQJ_HaJmH sH tH @@ XML exampleo$a$OJQJmH sH TOT CodeBlockp$h*$^hCJOJQJaJmHnHuTOTCodeBlock Char'CJOJQJ_HaJmHnHsH tH uXX OpenIssue'r & F hhdd[$\$^h OJQJaJ&X@1& Emphasis6]OA tx15\NORN Doc Historyu$<<[$\$a$@ CJ^JaJ:'@a: Comment ReferenceCJaJ,O, Body xPJaJ>O> Body CharOJPJQJ_HmH sH tH \O\ Table Cell Char Char$CJOJPJQJ_HaJmH sH tH 4O4 Table Cell{ CJPJaJROR Bullet List)| & F L((^`L0O0 Bullet List CharO %Bullet List (double indent alternate)+~ & F L((^`Ltt Bullet List (double indent)+ & F E((^`E8O8 Code CJOJQJ^JaJFOF Code Char$CJOJQJ^J_HaJmH sH tH @O!@ Code (Character)CJOJQJaJ^2^ Numbered List (double indent) & F((PBP Numbered List# & F 8((^JRJ copyright 7@CJOJQJaJmH sH 8b8  Instructions <B*phXOq abbrev"O" citetitle,O, status-headingFg@F HTML TypewriterCJOJPJQJ^JaJ:b@: HTML CodeCJOJPJQJ^JaJ6O6 Source TextOJPJQJ^J:O: msobjpropval1OJQJ^Jo(Bf@B HTML SampleCJOJPJQJ^JaJo(*O* msobjprop16]"O " greytableO  XML ExcerptW$d%d&d'd-DM NOPQ#OJQJ^J_HmHnHsH tH uTO! TXML Excerpt Char#OJQJ^J_HmHnHsH tH u6O1 6 XML Reference CJOJQJJOA J XML Excerpt Emphasis5CJOJQJ\0OQ 0 Table Font CJOJQJ.OR a . Table Heading5POr P New Table Font$d ((a$ mH sH tH JOq J New Table Font Heading$a$5dO d Table Caption$$d ((a$56CJOJQJmH sH tH /sPTI`c  !"#$%&'()*+,-./0123456789:;<=>?@FJOas :>V[1Clquw SW[o:>CW[_ch0Sh -16J_q &9KVh{ ! 3 > P b t    % 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 P&    ? !"#$%'()*+,-./01a3456789:;<=>                                             7 6 4 2 1 0 / , * & % $ #           = < ; : I H F E D C S R Q P \ [ Z Y d c b l k j i u t s r       !"#$%&' ( ) * + ,-./0123456789:;<=> ?!@"A#B$C%D&E'F(G)H*I+J,K-L.M/N0O1P2Q3R4S5T6U7V8W9X:Y;Z<[=\>]?^@_A`BaCbDcEdFeGfHgIhJiKjLkMlNmOnPoQpRqSrTsUtVuWvXwYxZy[z\{]|^}_~`bcf gijklmnopqrs      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^`abcdefghijklmnopqrstuvwxyz{|}~dtuvwxyz{|}~      2   !"#$%&'()*+,-./0123456789:;<=>?@FJOas :>V[1Clquw SW[o:>CW[_ch0Sh -16J_q &9KVh{ ! 3 > P b t    % 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~                            ! " # $ % & ' ( ) * + , - . / 0 1 2 5       !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Michael J. BeckerleMichael J Beckerle Tom Sugden Simon Parker IBM_USERάϳ&N] (!04J;5<6<<.@zFFKHM0OSD\p q![ok "#$-8r2Opd}%\'&)|,,n01W3y7F8>$D.KNyXlygʐ.{F`fݟW.iɲ߶8oh['C rs* Q\&&&).//1g;$?L_ugr]s.x|"N=&PMJBv MJB MJBU MJBagMJBfC MJBD MJBP5 MJB MJBZ MJB׳ MJB԰ MJBU TPCSb TPCS4b sp # MJBA MJB spz# sp# sp\# MJB MJB spG# sp*# MJB sp# sp# MJB sp;# sp# spM# sp# MJB*G TPCSc MJBੲ MJB. sp# MJB MJB~ MJBaȰ MJBa sp# MJB- MJB MJB_G MJBG MJBG MJBMJBXI MJB! MJB! MJBQ3 MJB! MJB]3 MJB! MJB! MJB! MJB3 MJB MJB/ MJB/ MJB MJBYN MJBN MJB MJB MJBO MJBO MJB%P MJBP MJBP MJBP MJB; MJBʰ MJBnΰ MJB MJBz MJB MJB MJB4 MJB6 MJB MJB MJBR MJBS MJB MJB MJBS MJB?l MJB MJBfMJBfMJB MJBfMJBifMJBfMJB/ MJBNfMJBx MJBfMJB fMJBx MJB'fMJB MJBffMJBSfMJBfMJBFfMJBfMJBfMJB]fMJBl MJBfMJBfspC# MJBF9 MJBfspV# MJBx MJB4bgMJBVy MJB!y sp# MJBbgMJBy MJBS MJB, MJB] MSOfficegMSOfficeMJBiogMJBgMJB5gMJB_ MJB}gMJB MJB MJBVT MJB  MJB MJBl MJBU MJBU MJB+ MJBU MJB MJB" MJBx< MJBV MJB MJB MJBu? MJBA sp# MJBMJBgMJBgsp%# MJB MJB] MJB]e MJB\ MJB8 MJB$ sp<# sp# spF# MJB MJBMSOfficeMJBgsp# sp͛# IMSOfficeMSOfficeMSOfficeMJB\MSOfficeMSOfficeIMSOfficeMJBfficeMSOfficeMJB' MJBj MJBJ8 MJBMJB` MJBȰ MJBT MJBT MJBY MJBV MJBd\ MJBc\ MJB= WnA Q 4 | ] | } 1n:g&F<AH@!b!!"#?###D$$%&&'()I*o**+,-F/00n11t22=3M33334 57;88m:2;"<<=B@@@XA`BBKCbCiCCCD/DUDD EBEF GGHHGJJPKKfLL=MMNNNO.PiPPPQSSTUVWXZ3\r]]],^]`aaWbbcc+eeSf_fkfVhhhiklmoorNsst)uu8vwxqxyyzHz{~bMтʄ|u(LwzkP ( /Bhikl./89IK\|}7m "?JKO]yFa 6  Z [ f g k y [fgky nYdeiw )lwx| !%3yz $T_`dr,789J](67[GdefgirsF 6!!!H"""M##$o$$#%%%@&&&_''(h((;))***i++Y,,--- .w..Q//300111F222D33 4m44)555B667v77:889g99:w::\;;<t<<1===T>>>??B@@@SAA>BB%CCC@DDDNEEFFFQGG2HH(II,JJ5KKELLLMM)NNNQOO2PPQiQQ7RRSmSS=TTTPUU1VVVTWWXlXXHYYY_ZZ [][[U\\4]]^p^^]__?``aabbb)ccdd"ee2ffgggWhhiijpjjTkkkkklm]mAnnjokolooooooopppbqcqqqs%t7tYtutwx{|~~)IʼnÌ ͍<bqr,67ҏ?RhyȐ.ABB_`1DWē;_ΔϔДS)SHI[ș0z֚,]^˛)НH)@oנVdJң)bӫ=ЬR> tBRdzѳ׵9?Sֿ99  )<Wop<5"4(JL /Gk;o@Uf~F6A&PB3"efs+,3_`a '4=5&NSX0OGH=p Hp.9=JKeq lBwl3r bBk DNbv,PZm <=y()    )   m!R /3@A>uvij`45Y j !A!F!!!!D"]"p""""#+#O######h$$% &3&&&''(<(v((()**+,a-b---.<.....?/*00z11L2v2223D3t3v344595556677C9990::;;<<<==/>>?:DVDDrEEE|F}FFFNHOHqHIJiKK:LLMMNOO3PfPPBQZQJR[RcRdReRnRvRwRRRRRRSS#S$S6S>SFSGS_SiSqSrSSSSSSSSSSSSSSSTTYUkVlVWXXZZ/Z\]]aa/abcc;fϼ0ý  ';ERfpq !',2789?EJOU|}~"(hijov{ 34_ekq!"#).39RWXY^dj345:?DIbghis &2w]UNVK1YT]CHp aA:=ip? 45J<Tv#D.ByV1Q&BO>y    7 & N 1   A  K(f5'<dC= T// Y\{h6 "u%v%w%%a&s&&&1'^''H(())+++,",,,,%-&-D-".#.$.q.//0s01q222Y3|3344(6777H88 99w:x::v<=>b>>>8?9??^@ABBBQCCD&D7EEEFFFF8F}F~FFFFGGGGOGGGGGG1H2H3HHHI$JMJJ0KKKLLLfMMMN>NLNNNNO+O>O?OPwPQQ,QQRRRSCSHTOTaTeUuU|V}VVVV5WWWXgXhXiX{XYAZ[[[\)\;\h\\\\]^A__5`A``,aEa_ayabccdeekfffggghiijVkWkskkllXnennno2o[ooop0pMpfpppppp q;qRqqqqrOrbrrrs!s>sWsjs~sss tFtTtctdtuv:whwwwxxxx yYyyzz{{|||o}~~~~~aWU)wÉ4pu^Y$=>LXYai̐1Rr IГ 2v()=B a !,1!fΘ;<CM*VWchdKLhpߝ  #^͞Ξ՞ݞ7QR]hM[ghzΡϡܡHdsǣȣգڣ6`DEFGݥM*%3?@Y^MN_eS#1=>QXʫѫ012qɬʬجaQk®ǮkЯѯMNem̰Ͱΰ @NZ[ej=Z˲ٲ+t(JKdOIj -׹^wKǻл&\׼5{VtuӾ޿? eCV"0<=L]E'STUqacKL`h(0&'2:=rs >?IQJdeD!-.8K4MNW]E_`qXqrswN o_\Z.@Sx4M[]ao{|mn)*VWsx'h*+ET{"#,16/Qq*D4`auWf?kl!x.N'W *f3ghy~$j,./0J j  ,     S  :|1 %Gs $45HUq"Lbr{ J(u|5cFM[cde<^:]L+AZ[> ? S W w  !F!b!c!!t""#!#>##s$$$$%%%%&&&''''p((()L)a)x))))*`*v*****~+++,F-+..../%/4/Q////=0000 1E1b1q1111(2N22223#4l4"5R5]55556656O666677+7l777777848y8829Z999::H::::;;;5;{;;7<8<<< =q==>9>~>>>>>>8??@@ A&AJAAAAAA/BWBrBBC Ds?slssPvYw0x}xxxxxxxxxxxxxxxxxxxxxxxxxyyy,yHymyyyyyyyyyyyyyyyyyyyyyyyyyyyyzz zzz$z%z&z'z(z)z3z9zEzQzRzSzTzjz~zzzzzzzzzzzzzzzzzzzzzzz{{ {{{{{{{"{/{;{G{H{I{e{{{{{{{{{{{{{{{{{{{{{{{{{{{|||||B|f|s|x|~||||||||||||||||||}}}_}}}~h~~LiӃ8m~Q)3Us  Q*Es@Ґ ȑ+gq;ܗaݙdW=sA%¥58['vҫޫެxAB  $ }~ mn=ŸƸ:A[oϹI׺5\.HoƼ)B\ƽTھV̿ͿڿXq*g9v!H\q'Dhlmm67ABTUsthi hiX|}!:r67ABeDE56 \] OP?@]uv<^_)Q^+,(E`A@ne>Y3NP ) e    G H T l    )Yl!G4KQg}wlH[?L17$:w`DY      !#$ $ $!$%$G$$Z%%&&x())~****++++++G,O,Z,a,m,v,,,,,,|--..A//01*23~4s666666666"7#7\7]7t7777G8H8P8Q88\abefjk|}01459:"#'(UVYZqrvw  #$78LM^_1267;<norsvw#UVYZ^_rsvwz{~/03489KLnoy%&9:HILMQRefz{$%/07ABITU\fgqry  *+2<=DNOYZakls}~  $./6@AKQ0\00000000000000000/D0/0/0u0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0Ku0Ku0Ku0Ku0K0K0K0# 09# 0J9# 0J9# 0J9# 0J9@09@09@09@09@09@09@09@09@09; 09; 09@09@09@09? 09? 09? 09? 09? 09@09@09@09@09@09@09@09@09@09@0@0i@^0i@^0i@^0i@^0i@^0i@^0i@^0i@_0i@_0i@`0i@_0i@_0i@_0i@^0i@_0i@_0i@_0i@_0i@^0i@^0i@^0i@_0i@^0i@_0i@_0i@`0i@_0i@`0i@^0i@_0i@`0i@`0i@`0i@`0i@`0i@_0i@`0i@`0i@_0i@_0i@_0i@_0i@_0i@_0i@`0i@_0i@^0i@_0i@_0i@_0i@_0i@_0i@_0i@_0i@_0i@^0i@_0i@_0i@_0i@_0i@_0i@_0i@_0i@^0i@_0i@_0i@_0i@_0i@`0i@`0i@`0i@a0i@a0i@^0i@_0i@_0i@_0i@_0i@`0i@`0i@_0i@_0i@_0i@_0i@`0i@`0i@_0i@`0i@a0i@a0i@a0i@a0i@`0i@`0i@_0i@_0i@`0i@`0i@a0i@a0i@^0i@^0i@^0i@^0i@^0i@_0i@`0i@`0i@a0i@a0i@a0i@`0i@`0i@`0i@`0i@`0i@_0i@`0i@`0i@`0i@`0i@`0i@`0i@^0i@_0i@`0i@`0i@`0i@_0i@_0i@_0i@`0i@`0i@`0i@_0i@`0i@`0i@^0i@_0i@`0i@`0i@`0i@`0i@^0i@^0i@^0i@^0i@^0i@^0i@^0i@^0i@^0i@^0i@`0i@`0i@_0i@`0i@`0i@_0i@_0i@`0i@`0i@`0i@a0i@`0i@`0i@^0i@_0i@_0i@_0i@_0i@_0i@_0i@_0i@_0i@_0i@`0i@^0i@_0i@_0i@`0i@^0i@`0i@`0i@_0i@`0i@`0i@`0i@@0i@0@0k! 0k! 0k! 0k! 0k! 0k! 0k! 0k@0k@*0k@*0k@*0k *0k *0k *0k *0k *0k@*0k@*0k@*0k@*0k 0@0q@0q7 D0q7 D0q7 D0q@0q@0q@0q@0q@0q@D0q@D0q@D0q 0qq@0@0@0@0@0 0qq@0@0( 0@0@p0@p0@p0@p0@0@0@p0@p0@p0@p0@p0@p0@0@0@p0@p0@p0@0@0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@0@0@0@p0@0@0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@0@0 0qq@0ДH 0ДH 0Д@0Д 0qq@0F 0F 0F 0F 0F 0F 0@0@0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0 @0@0@0@0@0@0@06 06 0@0@0 0qqG 0G 0)G 0G 0oG 0o 0@0 0@D0V@D0V 0@0@0 0@0@0@0@0@0@0 0@0Ь@0Ь@0Ь@0Ь@0Ь@0Ь@0Ь$ 0Ь$ 0Ь$ 0Ь$ 0Ь$ 0Ь$ 0Ь@0Ь 0@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz@D0dz$ 0dz$ 0dz$ 0dz@D0dz@D0dz@D0dz 0@0@0 0 0 0 0 0@0 0@0@0 0@0p@0p@0p@0p@0p@0p@0p@0p@0p@0p@0p 0pp@0@0@0 0 0 0 0 0 0 0 0 0 0  0  0  0  0  0@0@0 0 0 0 0 0 0 0 0 0 0  0  0  0@0@0 0@06@06@06@06@06@06@06@06 0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0( 0@0a 0a 0a 0a 0a@0a 0@0@p0@p0@0@0@p0@p0@p0@p0@p0@0@0( 0@00@00@00" 00" 00@00 0@0= 0==@0@0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@p0@0( 0@0K@D0K@D0K@0K( 0@0@0@0@0@0@0@0( 0@0B@0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@0B@0B@0B@0B@0B( 0@0B@0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@0B@0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@p0B@0B( 0@0@0@0 0==@0 @0 @0 @0 @0 @0 @0 @p0 @p0 @p0 @p0 @p0 @p0 @p0 @p0 @p0 @p0 @p0 @0 @0 @0 @0 ( 0  @0@0( 0  @0@p0@p0@0@0@0 0==@0j@0j@0j@0j@p0j@p0j@p0j@p0j@p0j@p0j@p0j@0j@0j@0j@0j@0j@0j@0j 0==@0!@0!@0! 0==@0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@p0!@0!@0!@0!@0! 0==@0 & 0==@0&@0&@0&@0&@0&@0&@0&@0&@0&@0&@0&@0&@0&@0& 0==@0b-@0b-@0b-@0b-@0b-@0b-@0b-@0b-@0b-@0b-@0b-@0b-@0b-( 0b-b-@0L2@p0L2@p0L2@p0L2@p0L2@p0L2@0L2 0==@04@04@04@04@04 0@06 066@07@07 066@09@09@09 066@0;@0; 066@0< 066@0=@0=@0=@0= 066@0:D@0:D@0:D 066@0E@0E@0E@0E@0E@0E 066@0OH@0OH 0OH 0OH@0OH@0OH@0OH 0@0M@0M@0M@0M@0M% 0M% 0M 0MM@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0BQ@0M 0MM@0Z@0Z@0Z@0Z@0M 0MM@0a@0a@0a@0a@0M 0MM@0 |0> |0> |0@|0@|0> |0@|0@|0@|0> |0( 0@0@0@0@0 0@|0@|0 |0 |0@|0@|0 |0 |0 |0 |0 |0 |0 |0 |0  |0!@|0@|0 |0" |0# |0$@|0@s0@0( 0@0@0@0@0@0 |0% |0&@|0@|0 |0' |0( |0)@0 |0* |0+ |0,@0 |0- |0. |0/ |00@|0@0@0@0@0@0( 0@0@0@0@0@0 |01 |02 ~0 ~0 |03 ~0@s0 |04 |05 |06 |07 |08@0 |09 |0: |0; |0<@0 |0= ~0 ~0 |0> ~0 |0? |0@ |0A |0B |0C@|0@05 0@0@0@0 0@0 $( 0 $ $@0%$3 0%$3 0%$3 0%$3 0%$@0%$@0%$@0%$@0%$@0%$@0%$4 0%$@0%$@0%$@00+0+( 0 $+0+1 0+1 0+1 0+1 0+1 0+1 0 +1 0 +1 0 +1 0 +1 0 +0+( 0 $+01-3 01-3 01-3 01-01-01-0@10@10@10@10 0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0@0 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000@0000000000000000000000000000000000000000000000000000000@000000000000000000000000000000000@0000000000000000000000000000000000000000000@0000000@000@000@000@00000@000@000@00000@000@000@00000@000@000@000@000@00000@000@000@00000@000@000@00000@000@00000@000@000@00000@000@000@0000 m#$%i&G'!())*+f,Z-c.g/x0u1u2p345G67889:t;Y<D=>>?@ABCaDE7F&GGHIJKLM.OFPlQRRSRTbU8V1W6XXYZ[\]`^,_M`5a9bUc@d9ezf&g;hijkvlamnnsoՓB9(!7lPW[g|! "@Xo̔gw=.)Bfekrp)??JjNP)S+UYb%t|^~P ,9CEJMRY`dm~ #.FUWdu|" yxrJG %/:BD,NPY?doqrssu7xSIȝz,H)VB9 pJ Gfea'5pK j%+'*28;?AINQTcVvVViWWlZ/ellllot%w z ݓߖyRq'7?|i 3W^DgA5v.y  Nf5d/ !{"&a**+03Y78H<x>FJOKLMNOfQ>SVHX}Z])``,eyekjker!w{|}ʀo)4= )f#gE^X2ذгδeǿ<SK2Q8s]?   , J |^?$F%&>'()+./69;H>B HhHHJL|SUX[]^_elr>zɂ~ńhӊ~3 sqݠ=ҲDi XA )l!g?!#$%D&''%+,1G3a33357H?OIyW_ir8|Ӄ#"?\'rULMZ ]z *GP     !"#$%&'()*+-./012345678:;<=>?@ABDFGHIKLNOPQSTUVWXZ[\]^_abcefghijklnopqrstuvwxyz{|}     !"$%&'()*+,-/0123456789:;<=>?@ABCDEGHIJKLMNOPQRSTVXYZ[\]^_`abcefghijklmnopqrstvwxyz{|}~Os % A C D F f x !!1!3!4!6!V!y!!!!!!!!!!! "&"B"E"F"H"h"{"""""""""""#+#G#J#K#M#m##########$$"$M$i$l$m$o$$$$$$$$%% %!%#%C%w%%%%%%%%%%%&&:&=&>&@&`&&&&&&&&&&&&'='Y'\']'_''''''''''((($(F(b(e(f(h(((((((()5)8)9);)[))))))))****;*d*********** +G+c+f+g+i+++++++,7,S,V,W,Y,y,,,,,,, -'-*-+---M-v-------. . . .-.U.q.t.u.w.......///K/N/O/Q/q///////0-0001030S00000000111151e111111111112$2@2C2D2F2f2z222222222223"3>3A3B3D3d33333333444 4*4K4g4j4k4m444444445#5&5'5)5I5e555555555556 6<6?6@6B6b66666666 777737T7p7s7t7v7777777 88487888:8Z8y88888888889!9E9a9d9e9g999999999::::=:U:q:t:u:w:::::::::;V;Y;Z;\;|;;;;;;;; < < <</<R<n<q<r<t<<<<<<<<=+=.=/=1=Q=l===========>2>N>Q>R>T>t>>>>>>>>>>>>?p???????????@ @<@?@@@B@b@~@@@@@@@@@@@A1AMAPAQASAsAAAAAAAB8B;BB^BBBBBBBCC"C#C%CEC_C{C~CCCCCCCCCCD:D=D>D@D`DxDDDDDDDDDDDE,EHEKELENEnEEEEEEEEFFFF>FpFFFFFFFFFFFG/GKGNGOGQGqGGGGGGGH,H/H0H2HRHHHHHHHI"I%I&I(IHIIIIIII J&J)J*J,JLJJJJJJJK/K2K3K5KUKKKKKKK#L?LBLCLELeLLLLLLL*MFMIMJMLMlMMMMMMMN#N&N'N)NINdNNNNNNNNNNN O/OKONOOOQOqOOOOOOOP,P/P0P2PRPsPPPPPPP Q QQQ0QGQcQfQgQiQQQQQQQQR1R4R5R7RWRRRRRRRR SSSS1SKSgSjSkSmSSSSSSSST7T:T;T=T]ToTTTTTTTTTTTU.UJUMUNUPUpUUUUUUUV+V.V/V1VQViVVVVVVVVVVVW2WNWQWRWTWtWWWWWWWWXXXX'XJXfXiXjXlXXXXXXXX&YBYEYFYHYhYYYYYYYYYYYYZ=ZYZ\Z]Z_ZZZZZZZZZ[ [ [ [,[;[W[Z[[[][}[[[[[[\2\N\R\S\U\u\\\\\\\]-]1]2]4]T]v]]]]]]]^^^^9^M^i^m^n^p^^^^^^^_:_V_Z_[_]_}_______`8`<`=`?`_`s```````aaaa9auaaaaaaaabbb#b_b{bbbbbbbbbbbc"c&c'c)cIcscccccccdddd ZІ(    '+ 3  s"*?n  c $X99?"`'+4  |%vn  C "`Px 4  PG 4  P hn  C "`  ZB  S DI!4  I!#n  C "` &% TB  C DxTB  C DG4  Pn  C "`P6 TB  C D  n  C "`. n  C "`k n  C "` n  C "`. X  T  # .  TB B C D P TB  C D . TB  C D ZB  S DQn  C "`#z  TB B C D_P_ZB  S DTB  C DT  #  4  E`n  C "`6[M 4  |)n  C "`bqX ZB  S DTB  C DTB  C DTB  #  ^%T TB  C DhZB  S D #TB B C D # #ZB  S D. n  C "` n  C "`ay T  #   4   "n  C "`|@!" TB  C D n  C "`4 TB  C Da4  E!P%n  C "`Ej"% TB  C D !ZB  S D# ##ZB  S D # ##n  C "`a!" n  C "`-  n  C "`!# n  C "`#6z` 4   m n  C "`L a  TB  C D_TB  C D n  C "`  G n  C "`p r  T  # . v? TB B C D G GTB  C D G . 4  y! Fn  C "`  ZB  S D*  n  C "` `V                           ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q s t u v w x y z { | } ~  n  C "` *  4  i" $n  C "`y" $ TB B C D #E#TB  C D H i"4  Pyn  C "` [ n  C "`l  ZB  S Du"TB  C Du"u"TB  C Dyn  C "`k  n  C "`  TB  #  `k! TB  C D ? , * 3  s"*?n  c $X99?"`*4  en  C "`1[ 4  9; 4  9d  n  C "`   n  C "`F  ZB  S D! &" TB  C D: d n  C "`T #  n  C "`  T  #   TB B C D|9}TB  C D|TB  C D ZB  S D9n  C "` Sc| TB  C Dn  C "`L u TB  # 2$( T  # 9 TB  C Dn  C "`9 ZB  S D&TB  C D&&n  C "`B! n  C "`(* TB  C D  TB  # ~ ~4  9 TB  C DZB  S D2$n  C }"` g }n  C |"`T  |n  C {"` {&   () 3  s"*?n  c $X99?"` ()T  #    T  # wu T  # w TB  # ,# TB  C D uTB   C DTB   C DT   # F * 4   F Wn   C  "`[z TB B C DwTB B C Dwn  C "`X+ n  C "`dt n  C "` I n  C "` < 4  !$n  C "`h' TB  C D!n  C "`Xu+ n  C "`  3m&,74  3  s"*? `   c $X99?3m&,74T   # c'!0* T   # k-2 T   # +-!2 T   # #$-s+2 TB  B C DK0*-TB   C D 0* -TB   C DC0*'- 3m&,74  3  s"*? `   c $X99?3m&,74T   # c'!0* T   # k-2 T   # +-!2 T   # #$-s+2 TB  B C DK0*-TB   C D 0* -TB   C DC0*'-  _+  ! 3  s"*? ` "  c $X99?_+ T #  # z# qH  zT $  # y$ J u  yT %  # x% u a xTB &  # w& (i wTB '  C D J TB (  C DTB )  C DaT *  # v*  @N v4 +  Z@n ,  C u, "`u  uTB - B C DCTB . B C DCn /  C t/ "`' tn 0  C s0 "`Z! sn 1  C r1 "`  rn 2  C q2 "`6+ q4 3  %(Vn 4  C p4 "`#y* pTB 5  C D#%#n 6  C o6 "`J ' on 7  C n7 "`R# n 3m&,74 8 3  s"*? ` 9  c $X99?3m&,74T :  # : c'!0* T ;  # ; k-2 T <  # < +-!2 T =  # = #$-s+2 TB > B C DK0*-TB ?  C D 0* -TB @  C DC0*'- 3m&:74 A 3  s"*? ` B  c $X99?3m&:74T C  # C c'!0* T D  # D k-2 T E  # E )-12 T F  # F 2-:2 TB G B C DK0*-T H  # H -C2 T I  # I { -'2 TB J B C D0* -TB K  C DC0*#$-TB L  C DC0*--TB M  C DC0*k6- 3m&,74 N 3  s"*?` O  c $X99?3m&,74T P  # P c'!0* T Q  # Q k-2 T R  # R +-!2 T S  # S #$-s+2 TB T B C DK0*-TB U  C D 0* -TB V  C DC0*'- 3m&,74 W 3  s"*?` X  c $X99?3m&,74T Y  # Y c'!0* T Z  # Z k-2 T [  # [ +-!2 T \  # \ #$-s+2 TB ] B C DK0*-TB ^  C D 0* -TB _  C DC0*'- 3m&,74 ` 3  s"*?` a  c $X99?3m&,74T b  # b c'!0* T c  # c -2 T d  # d #$-s+2 TB e B C DK0*-TB f  C DC0*'- 3m&,74 g 3  s"*?` h  c $X99?3m&,74T i  # i c'!0* T j  # j -2 T k  # k c-!2 T l  # l #$-s+2 TB m B C DK0*-TB n  C D 0* -TB o  C DC0*'- 3m&,74 p 3  s"*?` q  c $X99?3m&,74T r  # r c'!0* T s  # s -2 T t  # t c-!2 T u  # u #$-s+2 TB v B C DK0*-TB w  C D 0* -TB x  C DC0*'- xS((  3  s"*?n   c $X99?"`xS((4   |%vn   C m "`Px m4   P in   C l "`P lZB   S D#4   I!6#n   C k "`I!& kTB   C DxTB   C DG4   Pn   C j "`P6 jTB   C D  n   C i "` in   C h "`k  hn   C g "` gn   C f "`. W  fTB   C DhZB   S D_J!an   C e "`6X` e4   PG n   C d "`P  dTB   # c I!%{ c4   Pn   C b "`#&Zz bZB   S DPI!Qn   C a "`&WQ aTB   C D7TB   # ` #7. `n   C _ "`y _TB  B C D P 4   EG n   C ^ "`#.  ^n   C ] "`. X  ]T   # \ E h \TB   # [ Ey [TB   C D  TB   C Dhn   C Z "`V Gp  ZZB   S DHITB   C DH/TB   # Y |/  Y4   !TB   C Dn   C X "`Zd% XTB  B C D*  E 4   En   C W "`En WTB  B C D*  + Hn   C V "``H VZB   S D* HEHTB   # U  /N! UTB   C D/n   C T "`q TTB   C D##n   C S "`Gp  S *  3  s"*?n   c $QX?"`*4   en   C R "`1[ R4   9d  4   9n   C Q "`vB  Qn   C P "`9 I  PTB   C D: d n   C O "`T #  On   C N "`SB!| Nn   C M "`  MTB   C Dn   C L "`L u LTB   # K 2$ (L  KT   # J 98  JTB   C Dn   C I "`9S<  In   C H "`(- Hn   C G "`vD GTB   C D  TB   # F  \ FZB   S D|&|TB   C D&|& ZB   S D" 2$" 4   Pn   C E "` E4   kon   C D "` R DTB   C D**n   C C "`k Cn   C B "`Sw BTB   C D: TB   # A : o  ATB   C D9TB   C Dkz  0A i? ?3"`B S  ?H 0(   HFeFF@o~ YA^{P0*T!gt )q6t%;!Z#tp tg t` tW tN tA Pt8 t t t! !gt '2t ;!Z#t{ _Toc506864867 _Toc165626304 _Ref525097868 _Toc165626305 _Toc112836550 _Toc112826272 _Toc113075250 _Toc165626306 _Toc165626307 _Toc165626308 _Hlt165626529 _Toc165626309 _Toc165626310 _Toc1403318 _Toc165626311 _Toc165626312 _Toc165626313 _Toc165626314 _Toc165626315 _Toc165626316 _Toc165626317 _Hlt97436656 _Hlt97436657 _Hlt97443219 _Hlt99422033 _Hlt99422034 _Toc165626318 _Ref140935774 _Toc165626319 _Toc165626320 OLE_LINK3 OLE_LINK4 _Toc165626321 _Toc165626322 _Toc20156277 _Toc165626323 _Toc165626325 _Toc165626326 _Toc165626329 _Toc165626330 _Toc165626331 _Toc165626332 _Toc165626334 _Toc165626335 _Toc165626336 _Toc165626337 _Toc165626349 _Toc165626360 _Toc165626361 _Toc99787969 _Toc99956882 _Toc165626362 _Ref161828896 _Toc165626363 _Toc165626364 _Toc157593753 _Toc165626365 _Ref157419914 _Toc165626366 _Toc138694360 _Ref135731088 _Toc138694356 _Toc52008003 _Toc73354123 _Toc86658204 _Toc99787971 _Toc138694334 _Toc165626367 _Toc165626368 _Toc165626369 _Toc165626370 _Toc138694335 _Toc165626371 _Toc112836556 _Toc112826278 _Toc113075256 _Toc165626372 _Ref161823626 _Toc165626373 _Toc138694349 _Toc165626374 _Toc138694341 _Toc165626375 _Toc137360897 _Toc137360898 _Toc137029569 _Toc137029570 _Toc137029571 _Toc137029574 _Toc137029576 _Toc138694338 _Ref140934911 _Ref140934918 _Toc165626376 _Toc138694339 _Ref161824338 _Toc165626377 _Toc138694340 _Toc165626378 _Toc165626379 _Toc165626380 _Toc165626381 _Toc165626382 _Toc165626383 _Toc165626384 _Toc165626385 _Toc137029593 _Toc137029594 _Toc137029598 _Toc138694342 _Ref114888535 _Toc138694358 _Toc124764818 _Ref112768033 _Ref112768048 _Toc112836578 _Toc112826296 _Toc113075280 _Toc165626386 _Toc165626387 _Toc165626388 _Toc165626389 _Toc165626390 _Toc165626391 _Toc165626392 _Toc165626393 _Toc165626394 _Toc99787986 _Toc112836557 _Toc112826279 _Toc113075257 _Toc165626395 _Toc165626396 _Toc151286655 _Toc165626397 _Toc151286656 _Toc165626398 _Toc151286657 _Toc165626399 _Toc151286658 _Toc165626400 _Toc151286659 _Ref162001275 _Toc165626401 _Toc165626402 _Toc138694352 _Toc165626403 _Ref114885203 _Toc165626404 _Toc124764819 _Toc165626405 _Toc165626406 _Toc165626407 _Toc165626408 _Toc124764820 _Toc165626409 _Toc124764823 _Toc165626410 _Toc165626411 _Toc165626412 _Toc165626413 _Ref140935081 _Ref140935092 _Ref140935634 _Ref140935649 _Ref161823893 _Toc165626414 _Toc165626415 _Toc165626416 _Toc165626417 _Ref162000445 _Toc165626418 _Toc165626419 _Toc165626420 _Toc165626421 _Toc165626422 _Toc165626423 _Toc165626424 _Toc165626425 _Toc165626426 _Toc165626427 _Toc165626428 _Toc165626429 _Toc165626430 _Toc165626431 _Toc165626432 _Toc165626433 _Toc165626434 _Toc146530421 _Toc165626435 _Toc165626436 _Toc165626437 _Toc165626438 _Toc146530426 _Toc124907471 _Toc165626439 _1198566184 _1200564070 _1213604974 _1238199276 _Toc165626440 _Toc165626441 _Toc165626442 _Ref161836873 _Toc165626443 _Ref118173721 _Toc138694355 _Toc165626444 _Toc165626445 _Toc130873625 _Toc140549597 _Toc165626446 _Toc130873626 _Toc140549598 _Toc165626447 OLE_LINK5 OLE_LINK6 _Toc130873627 _Toc140549599 _Toc165626448 _Toc130873628 _Toc140549600 _Toc165626449 _Toc130873629 _Toc140549601 _Toc165626450 _Toc130873631 _Toc140549603 _Toc165626451 _Toc130873632 _Toc140549604 _Toc165626452 _Toc130873633 _Toc140549605 _Toc165626453 _Toc130873634 _Toc140549606 _Toc165626454 _Toc130873639 _Toc140549611 _Toc165626455 _Toc130873640 _Toc140549612 _Ref140946684 _Ref140946689 _Toc165626456w11w0w11w1w11w2w11w3w11w4w11w5w11w6 _Toc130873642 _Toc140549614 _Toc165626457 _Toc130873643 _Toc140549615 _Toc165626458 _Toc130873644 _Toc140549616 _Toc165626459 _Toc130873645 _Toc140549617 _Toc165626460 _Toc112836593 _Toc112826311 _Toc113075295 _Toc130873646 _Toc140549618 _Toc165626461 _Toc130873647 _Toc140549619 _Ref157416759 _Toc165626462 _Toc130873648 _Toc140549621 _Ref140936368 _Ref140936382 _Toc165626463 _Toc165626464 _Toc165626465 _Toc165626466 _Toc165626467 _Toc165626468 _Toc165626469 _Toc165626470 _Toc165626471 _Toc165626472 _Toc146530415 _Toc165626473 _Toc165626474 _Toc165626475 _Toc165626476 _Toc165626477 _Toc165626478 _Toc165626479 _Toc132009033 _Toc165626480 _Toc132009034 _Toc165626481 _Toc165626482 _Toc165626483 _Ref140941751 _Ref140941755 _Toc165626484 _Ref161820525 _Toc165626485 _Toc165626486 _Toc165626487 OLE_LINK1 OLE_LINK2 _Toc526008660 _Toc165626488 _Toc526008661 _Toc165626489 _Toc165626490 _Toc165626491 _Ref112771445 _Ref112771450 _Toc112836595 _Toc112826313 _Toc113075297 _Toc99787993 _Toc112836588 _Toc112826306 _Toc113075290 _Ref140945505 _Ref140945508 _Toc165626492 _Toc165626493 _Toc146530422 _Toc165626494 _Toc146530423 _Toc165626495 _Toc165626496 _Toc165626497 _Toc165626498 _Toc165626499 _Toc165626500 _Toc165626501 _Toc165626502 _Toc165626503 _Toc165626504 _Toc165626505 _Toc165626506 _Toc146530424 _Toc165626507 _Toc165626508 _Ref132167367 _Toc165626509 _Ref118192943 _Toc165626510 _Ref118187625 _Toc165626511 _Ref118190359 _Toc165626512 _Ref118187693 _Toc165626513 _Ref118187867 _Toc165626514 _Ref118195813 _Toc165626515 _Toc165626516 _Toc165626517 _Toc165626518 _Toc165626519 _Toc165626520 _Toc165626521 _Toc165626522 _Toc165626523 _Toc165626524 _Toc165626525 _Toc146530419 _Toc165626526 _Toc146530416 _Toc165626527 _Toc146530417 _Toc165626528//KKKK:i}#kqqДVЬЬЬdzppppppppppppp6a0=KKBBBB           j!! &&b-L24444444444444679;<=:DEOHOHOHOHOHMBQBQZZaa;f?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`aijkmnopqlrstuvwxyz{|}~@@@@      !"#$%&'()*+,-./012345678:9;<DEFGH=>?@ABCIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuwxyz.77[[[[Iq~#kq(ĉŒ(֠֠cѣѣ(RRгpppppppppppp@223No Vdvvjj           @!!2&&-u24444444444466666679;<=UDEpHpHpHpHpHMXQXQ.Z.Z-a-aVfVf%i%i%in7v7vߒ]j,lɥ"%IS%+0:B$DHL+QBS`TtUVzX[_@`hgggokokokoklgwxzzzzzzz{{LLL~~~$$$"""ppp   ɲɲʲcccccdddddddUUUoooxi 90R v '**\5828EFFnHnHLLNQRRR U UXR]]]__c&e&evglllllllrrrrrrLsksǑr&ݫgg;;]]'( $F$F$+++--Q v  U agfC D P5  Z ׳ ԰ U b 4b  # A  z# # \#   G#  *# # #  ;# # M# # *G c ੲ . #  ~ a aȰ _G # -  G G XI ! ! Q3 ! ]3 ! ! ! 3  / /  YN N   O O %P P P P ; ʰ nΰ  z   4 6   R S   S ?l  ff fiff/ Nfx f fx  'fffSffFfff]fl ffC# F9 fV# x 4bgVy !y # bgy S , ] giogg5g_ }g  VT    l U U + U  " x<  V  u? A # gg%#  ] ]e \ 8 $ <# # F#  g# ͛# \' j J8 ` Ȱ T T Y V d\ c\ = =dz}&G !04;&<&<<@EF8HMOS!\ppפWWYH1)Co~U(5yw%?'!)q,,i01 3[77>DJUNiXkya)v)t@S`Rǟ@BͶ5u =UUs+aaW  >%&&F-..1b;?LkgqRsw|s  {p`%,2  !"#$%&(',)*+.-/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdfeghijklmnopqrstuvwxyz{|}~άϳ&N] (!04J;5<5<<.@zFFKHM0OSD\p q![ok "#$-8r2Opd}%\'&)|,,n01W3y7F8>$D.KNyXlygʐ.{F`fݟW.iɲ߶8oh['?rs* Q\&&&).//1g;$?Lugr]s.x|"N=&,2()FFLL++)2*2S3F4O4q4w4s666666666666666"797D7H7[7777%8/838F8G8Q8~88888888::;;;;;;;;;;<<<<#<+<><G<H<Q<x>>>>??@?A]AwAAA4B8BCD F!HHKLOPPZPePlPwPyPPPPcQhQQQRR[RaRRTTUbYnYMZRZWZ\ZZZ[ [`[d[[[[[2\9\\\\\ ]]?]F]R^]^T_W_^`g```a#a;a@ajaoaaadeeeefffffffhhohhhhhkkkkkkppqqqqqqqq@rGr`rjrrrfsksEtWtkunuhypyyyzzzzzzzzb|l|}}078? _mۃÄȄτMN҈ۈpxѐڐ ϓؓڗ  !57HVa !mt} d*/Ԩo̪jïϯڱ`eײ apմߴеx~Xeø̸»ֽ޽uzNTCCDDEEFFGGHHIIJJKKLLMMNN\\aabbeeffjjkk||}}0011445599::ksv""##''((0?OUUVVYYZZqqrrvvww    ##$$7788LLMM^^__q11226677;;<<Rmnnoorrssvvww#+-7<TUUVVYYZZ^^__rrssvvwwzz{{~~%//0033448899KKLLnnoow| %%&&99::HHIILLMMQQRReeffzz{{ #$$%%//00=@AABBTTUUbeffggqqrr    &)**++8;<<==JMNNOOYYZZgjkklly|}}~~    *-..//<?@@AAKKNQisuM[LL%(3N*2s666666666666666H8O888: ;>>2@H@!H4H#WDW3ZAZhcwciiejkjlls1sttkuu{ |-1$(&=к\`bdfik{}/1358#&VXZpruw  "$68KM]0257:oqsuw #VXZ]_qsuwy{}02479Jo$&8:GIKMPRdfy{%.gpOX AJQ Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon ParkerzC:\Documents and Settings\simon.parker\Application Data\Microsoft\Word\AutoRecovery save of specification_19_annotated.asd Simon Parker)C:\dfdl-wg\specification_19_annotated.doc Simon Parker)C:\dfdl-wg\specification_19_annotated.docL|<~I}#H~OGjFԁnb?.6z>*=d<jONh ;B6Tb4TrqW=U/  uu ,8 .`4T+v0xⲬ4 BM %  >zFst u!888M"/Hf k&lzi+,S*LQO.^LT_Q /Ȳ1 06nu6k>* 8mT9vcu9b J_<ĂO&?2b.2A^2D!gWD6(UEtl'EFJ<5PF> Un;RJw0XV~[ Z'[&+cH] CD^PGD_ް(9_s_pesH=at5Ea<|,gW3c^\?ev8#MhW:iM:kKmL(pqx&r־tnM/ w~(hw0MK/$y< Gy"@8kzCtt6|.T)~@*^`.^`.88^8`.^`. ^`OJQJo( ^`OJQJo( 88^8`OJQJo( ^`OJQJo(hh^h`. hh^h`OJQJo(*h 88^8`hH. ^`hH.  L ^ `LhH.   ^ `hH. xx^x`hH. HLH^H`LhH. ^`hH. ^`hH. L^`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJo(hHhpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH^`8OJQJTXo(hH^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH ^`hH. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h HH^H`hH.h ^`hH.h L^`LhH.h   ^ `hH.h ^`hH.h XLX^X`LhH.h ((^(`hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.^`CJOJQJo(^`CJOJQJo(opp^p`CJOJQJo(@ @ ^@ `CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(^`CJOJQJo(PP^P`CJOJQJo(h P^`PhHh @@^@`hH.h 0^`0hH..h ``^``hH... h ^`hH .... h ^`hH ..... h ^`hH ...... h `^``hH....... h 00^0`hH........h^`8OJQJTXo(hHh&^`8CJOJQJTXaJo(hHhpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h ^`o(hH.h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJQJo(hH h^`OJQJo(hHh^`OJQJo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJPJQJ^Jo(-h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJPJQJ^Jo(-h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJPJQJ^Jo(-h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH 88^8`o(hH ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. ^`hH. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH. 88^8`o(hH ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`o(hH.h ^`o(hH.hpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh  ^ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh| | ^| `OJQJo(hHhLL^L`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJPJQJ^Jo(-h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHhhh^h`8OJQJTXo(hHh88^8`8OJQJTXo(hHh^`OJQJo(hHh  ^ `OJQJo(hHh  ^ `OJQJ^Jo(hHohxx^x`OJQJo(hHhHH^H`OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hH^`OJPJQJ^Jo(-^`OJQJ^Jo(hHopp^p`OJQJo(hH@ @ ^@ `OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHoPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJPJQJ^Jo(-h^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh HH^H`hH)h ^`hH.h L^`LhH.h   ^ `hH.h ^`hH.h XLX^X`LhH.h ((^(`hH.h ^`hH.h L^`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHh ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hHL~}|_>z WuL]EN 06u b1J_<WD &rW:iM"T+tt6|i+,0xH=ab4Gy k&(pqU/4 _Q /* 8)~[K/$y8#Mh2Acu9cH]^2D\?eu6kz8 M:k<5PCD^W3cKm(9_MI(UEO&?D_~(hwMb @ OJQJo(" ^^                   z"*       0l#                                                               $:/                                                                                                                    "                                    "                           "                          zlBC                                                                                         "        d.         "                                                               "                                                                                                                    Qƾô       r                  @ @ @ @/BhilI\|} "?JKO]y [ f g k y [fgkyYdeiw )lwx| !%3z $T_`dr,78efs+,3_`JR[RcRdReRnRvRwRRRRRSS#S$S6S>SFSGS_SiSqSrSSSSSSSSSSSSSSSTT~hhhhhhhhhhhhhhhhZlllll5mGmmm{~‡JKLNr=E؉/SUVXȋrstv^ijn "[c IQďƏǏˏʐ̐͐ϐ-015]yܑݒޒߒ  ';ERfpq !',2789?EJOU|}~"(hijov{ 34_ekq!"#).39RWXY^dj345:?DIbgh)+,",,,,%-&-D-".#.>EEFFFF8F}F~FFFGGGGGGGG1H2Hu$>LXYa ()= !,;<CVWcKLh  ͞Ξ՞QR]M[ghzΡϡܡǣȣգDE%3?@YMN_#1=>Qʫ01SummaryInformation(DocumentSummaryInformation8 CCompObjj$ @ L X dpx ssMichael J. Beckerleichich Normal.dotB Simon Parkercke4moMicrosoft Word 9.0@@zA:@@83cu  FMicrosoft Word Document MSWordDocWord.Document.89q  28_Toc16562647822_Toc1656264772,_Toc1656264762&_Toc1656264752 _Toc1656264742_Toc1656264732_Toc1656264722_Toc1656264712_Toc1656264702_Toc1656264692_Toc1656264682_Toc1656264672_Toc1656264662_Toc1656264652_Toc1656264642_Toc1656264632_Toc1656264622_Toc1656264612_Toc1656264602_Toc1656264592_Toc1656264582_Toc1656264572_Toc1656264562_Toc1656264552_Toc1656264542_Toc1656264532_Toc1656264522_Toc1656264512_Toc1656264502_Toc1656264492_Toc1656264482~_Toc1656264472x_Toc1656264462r_Toc1656264452l_Toc1656264442f_Toc1656264432`_Toc1656264422Z_Toc1656264412T_Toc1656264402N_Toc1656264392H_Toc1656264382B_Toc1656264372<_Toc16562643626_Toc16562643520_Toc1656264342*_Toc1656264332$_Toc1656264322_Toc1656264312_Toc1656264302_Toc1656264292 _Toc1656264282՜.+,D՜.+,H px  Open Grid Forumna?  Title_Toc165626479_Toc1656264272_Toc1656264262_Toc1656264252_Toc1656264242_Toc1656264232_Toc1656264222_Toc1656264212_Toc1656264202_Toc1656264192_Toc1656264182_Toc1656264172_Toc1656264162_Toc1656264152_Toc1656264142_Toc1656264132_Toc1656264122_Toc1656264112_Toc1656264102_Toc1656264092_Toc1656264082_Toc1656264072_Toc1656264062_Toc1656264052|_Toc1656264042v_Toc1656264032p_Toc1656264022j_Toc1656264012d_Toc1656264005^_Toc1656263995X_Toc1656263985R_Toc1656263975L_Toc1656263965F_Toc1656263955@_Toc1656263945:_Toc16562639354_Toc1656263925._Toc1656263915(_Toc1656263905"_Toc1656263895_Toc1656263885_Toc1656263875_Toc1656263865 _Toc1656263855_Toc1656263845_Toc1656263835_Toc1656263825_Toc1656263815_Toc1656263805_Toc1656263795_Toc1656263785_Toc1656263775_Toc1656263765_Toc1656263755_Toc1656263745_Toc1656263735_Toc1656263725_Toc1656263715_Toc1656263705_Toc1656263695_Toc1656263685_Toc1656263675_Toc1656263665_Toc1656263655_Toc1656263645_Toc1656263635_Toc1656263625z_Toc1656263615t_Toc1656263235n_Toc1656263225h_Toc1656263215b_Toc1656263205\_Toc1656263195V_Toc1656263185P_Toc1656263175J_Toc1656263165D_Toc1656263155>_Toc16562631458_Toc16562631352_Toc1656263125,_Toc1656263115&_Toc1656263105 _Toc1656263095_Toc1656263085_Toc1656263075_Toc1656263065_Toc1656263055_Toc165626304Nhttp://www.ogf.org/dfdl/ɬʬج®ЯѯMNḛͰ@NZ[e˲ٲ ǻ׼tu"0<=LSTKL`(&'2rs>?Ide!-.8MNW_`qqrw ao{|VWs*+E"#,*`aukly~$j,./UUUUUUUU-V.V8VLVPVQVVV%W&WnWWWWW X-X.XBXXXXl4pPvYwxxxxxxxxxxxxxxxxxxxxxxxxyy,yHymyyyyyyyyyyyyyyyyyyyyyyyyyyyyzz zzz$z%z&z'z(z)z3z9zEzQzRzSzTzjz~zzzzzzzzzzzzzzzzzzzzzzz{{ {{{{{{{"{/{;{G{H{I{e{{{{{{{{{{{{{{{{{{{{{{{{{{{|||||B|f|s|x|~||||||||||||||||||}}ެ  }~Q@ ,t; ,"{LHIKLMPP@PLP@PPPRP@Unknown Simon ParkerGz Times New Roman5Symbol3& z Arial="HelvArialG5  hMS Mincho-3 fg;WingdingsO1CourierCourier New?5 z Courier NewI& ??Arial Unicode MSWTms RmnTimes New Roman;" Helvetica3TimesCFComic Sans MS5& zaTahoma7&  Verdana"1hfHfϋfcuaOÑ0d?2+ 2qHP Michael J. Beckerle Simon ParkerRoot Entry FS@BData  7BWordDocumentJ ObjectPool033                             ! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q s t u v w x y z { | } ~         !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^`abcdefghijklmnopqrstuvwxyz{|}~       !"#$%&'()*+,-./0123456789< ?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~;:՜.+,D՜.+,H px  Open Grid Forumna?  Title_Toc16562647928_Toc16562647822_Toc1656264772,_Toc1656264762&_Toc1656264752 _Toc1656264742_Toc1656264732_Toc1656264722_Toc1656264712_Toc1656264702_Toc1656264692_Toc1656264682_Toc1656264672_Toc1656264662_Toc1656264652_Toc1656264642_Toc1656264632_Toc1656264622_Toc1656264612_Toc1656264602_Toc1656264592_Toc1656264582_Toc1656264572_Toc1656264562_Toc1656264552_Toc1656264542_Toc1656264532_Toc1656264522_Toc1656264512_Toc1656264502_Toc1656264492_Toc1656264482~_Toc1656264472x_Toc1656264462r_Toc1656264452l_Toc1656264442f_Toc1656264432`_Toc1656264422Z_Toc1656264412T_Toc1656264402N_Toc1656264392H_Toc1656264382B_Toc1656264372<_Toc16562643626_Toc16562643520_Toc1656264342*_Toc1656264332$_Toc1656264322_Toc1656264312_Toc1656264302_Toc1656264292 _Toc1656264282_Toc1656264272_Toc1656264262_Toc1656264252_Toc1656264242_Toc1656264232_Toc1656264222_Toc1656264212_Toc1656264202_Toc1656264192_Toc1656264182_Toc1656264172_Toc1656264162_Toc1656264152_Toc1656264142_Toc1656264132_Toc1656264122_Toc1656264112_Toc1656264102_Toc1656264092_Toc1656264082_Toc1656264072_Toc1656264062_Toc1656264052|_Toc1656264042v_Toc1656264032p_Toc1656264022j_Toc1656264012d_Toc1656264005^_Toc1656263995X_Toc1656263985R_Toc1656263975L_Toc1656263965F_Toc1656263955@_Toc1656263945:_Toc16562639354_Toc1656263925._Toc1656263915(_Toc1656263905"_Toc1656263895_Toc1656263885_Toc1656263875_Toc1656263865 _Toc1656263855_Toc1656263845_Toc1656263835_Toc1656263825_Toc1656263815_Toc1656263805_Toc1656263795_Toc1656263785_Toc1656263775_Toc1656263765_Toc1656263755_Toc1656263745_Toc1656263735_Toc1656263725_Toc1656263715_Toc1656263705_Toc1656263695_Toc1656263685_Toc1656263675_Toc1656263665_Toc1656263655_Toc1656263645_Toc1656263635_Toc1656263625z_Toc1656263615t_Toc1656263235n_Toc1656263225h_Toc1656263215b_Toc1656263205\_Toc1656263195V_Toc1656263185P_Toc1656263175J_Toc1656263165D_Toc1656263155>_Toc16562631458_Toc16562631352_Toc1656263125,_Toc1656263115&_Toc1656263105 _Toc1656263095_Toc1656263085_Toc1656263075_Toc1656263065_Toc1656263055_Toc165626304Nhttp://www.ogf.org/dfdl/SummaryInformation(DocumentSummaryInformation8 CCompObjj