"keyref" attribute names changed to "ref"! This is the pattern used in xml-schema itself and more commonly found. The "key" in keyref is unneccary technical, we do not want to refer to a key but to an object (and we use the key value to accomplish that).
DateMandatoryYearType and DateType removed from schema.
DateMandatoryYearType was a complex data structure (derived from the otherwise unused DateType) similar to the variant-date used in ABCD and other collection models.It allowed to leave unknown parts of the date empty (day, month, year) and provided for verbal dates ("summer 1920", "around 1990").
In the last SDD beta versions it was only used for PublicationDate of the current project version (ProjectDefinition/Version). Since we now have InitiationDate/LastRevisionDate in the RevisionData, detailed information about the the project can be found there.
(Note: Another place where DateType was expected to be used was in the PublicationResourceConnector, but since the format provided by external services is difficult to know, an unconstrained text for data will probably be a better solution.)
Revisiondata changed to RevisionData (uppercase D). Other ...Data elements used so far are uppercase as well. See also Trash.SDDResolvedTopicMetaDataAsTypeOrModelGroup.
Further, I have now added two optional attributes FirstEditDate and LastEditDate. These are intended to support statistics who was active on the project in the last period. This should be helpful to produce overview statistics in collaborative projects that encourage participation (it still is NOT thought to be a continous track of activity).
(AgentRef is only used in the context of creators/editors of objects (the project itself, characters, descriptions, etc.). If we use agents for other purposes we may have to change the type name -- but not the element names...).
In Character/Numerical/StatisticalMeasures: FormatString renamed to FormatPattern, redefined to use identical pattern as xsl, typed including a regular expression facet. Problem: xsl has no internationalization, this has to be achieved separately! Advantage: in Character/Numerical/StatisticalMeasures internationalization (audience specific representations) is rather inappropriate, was originally not planned to be audience specific. This makes more sense to provide centrally, rather than defining the number format for each audience in each character! However, the general format is well in the character: tree height or spore diameter will usually be presented with different number of decimals.
Typing of Values in CharacterData and NatLangDescrData revised (no changes in example documents required). Value in Natural language descriptions can now enclose Text with the value in formatted in the original language.
Terminology/StatisticalMeasures: Type derivation error, StatisticalMeasure was derived from CharacterStateData_BaseType. This affected only the NaturalLanguage Report Wording (which was single and needs to be around the value instead), fixed.
Question: should there be a format string at the generic definition as well? Perhaps to be used as template?