EDIT: This was a change mode artifact of the software used. Which is not reproducable. I have the "historic" PDF at hand, but when requesting final view from word on the same file again, it now does not stumble and produces readable 6.1.2 et al. as intended by the editor.
Thus this issue is reclassified as trivial bug and closed.
Thanks Ralf for working this out!
The latest revision of [OData Core Part 3: CSDL, Version 4.0](https://www.oasis-open.org/committees/download.php/48835/odata-core-v4.0-wd01-part3-csdl-2013-04-12.doc) has some presumable mixed up text following 6.1.2 up to but excluding (with current numbering) 6.3 Property Facets.
6.1.2 The Type Attribute
A property MUST specify a value for the Type attribute. The value of this attribute determines the type for the value of the property on instances of the containing type.
6.2 The value of the type attribute MUST be of the form AnySingleTypeName
The QualifiedName of a primitive type, type definition, complex type, enumeration type, or entity type in scope.
AnyKeylessTypeName. The value of the type attribute MUST resolve to a complex type, enumeration type or primitive type, or a collection of complex, enumeration or primitive types.
By the way, one issue for the reader is, that a grep AnySingleTypeName *.xsd (with edm,edmx and metadata) gives no hit
as I reach section 19 Attribute Values, I find what looks a bit like the source of a copy, paste edit-later without the last step
(namely subsections 19.5 AnySingleTypeName and 19.6 AnyKeylessTypeName)
Context is the "The edm:Property Element". The example in 6.1 states (relevant part for "type"): '[...] Type="Collection(Edm.String)" [...]'.
The edm.xsd refers for Property element to TProperty, which in turn refers (for attributes) to TCommonPropertyAttributes:
<xs:attribute name="Name" type="edm:TSimpleIdentifier" use="required" />
<xs:attribute name="Type" type="edm:TAnyType" use="required" />
<xs:attribute name="Nullable" type="xs:boolean" default="true" use="optional" />
<xs:attribute name="DefaultValue" type="xs:string" use="optional" />
<xs:attributeGroup ref="edm:TFacetAttributes" />
<xs:attributeGroup ref="edm:TPropertyFacetAttributes" />
So, the value of the Type attribute MUST conform to TAnyType which in turn is defined in edm.xsd as:
<xs:union memberTypes="edm:TPrimitiveType edm:TAbstractType edm:TQualifiedName">
<!-- The below pattern represents the allowed identifiers in ECMA specification plus the '.' for namespace qualification and the Collection() wrapper -->
so, ok a union of A) edm:TPrimitiveType, B) edm:TAbstractType and C) edm:TQualifiedName with the restriction D) that it matches the pattern 'Collection...' (that accounts for the Collection() wrapper and ECMA allowed identifiers adding the dot for manespace qualification..
I suggest rewriting as in the proposal (plus/minus structural changes planned as of meeting#32 w.r.t. headings describing "element x [attribute y]".
If the deleted words make sense for implementers of servers or clients, I hereby kindly ask to fill them back in, but please help me as say, a first test candidate to distill some additional understanding from the ammendment and how this matches the schema.
Maybe also someone finds a more direct presentation of the phrase "The value of this attribute determines the type for the value of the property on instances of the containing type." which states, that the value (in the example 'Collection(Edm.String)' meaning Edm.String!) rules all instances of the element (a complex type thus) containing the property element to be of that type (in the eample Edm.String). Doesn't it?
Ahem anyone for a better wording?
Since Collection() must be part of that facet, why not: The inner part of the value between 'Collection(' and ')' of the attribute 'Type' indicates, that all members of the collection of the type containing the propert element MUST be of the type with name equal to this inner part. Not better, I know ...
Or maybe I miss the real point here?