ddialliance / ddimodel Goto Github PK

Set up Issue submission templates: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

Set up PR submission template: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository

In DDI L 3.3 the r:ManagedMissingValuesRepresentation object can be used to add, at the value domain level of the instantiated variable, sentinel values such as: "out of scope", "doesn't say", "not concerned" etc. Would it be possible to add this object to the represented variable as well?
Would it be possible to add this object to the represented variable as well?

Should match https://github.com/ddialliance/ddi-l_3/blob/master/license.txt

19 occurrences of elements which extended a basic reference were not transferred in original input to 4.0. This was noted during the TC review but was not corrected. The attached file lists all instances. These are described in detail on the comparison spreadsheet at https://ddi-alliance.atlassian.net/wiki/spaces/DDI4/pages/3048439811/DDI-L+4.0+BETA+-+Review+Information#%5BmediaInline%5D

See sheet RED-extended reference

ListOfMissingExtendedReference_from_3-3.txt

Check for accurate capture of xs:simpleType enumerations and accurate output in serializations where appropriate

• Decide where the Zip packages and the web pages get uploaded
• Set up github secrets with the auth information
• In the action script, if the repository is not the ddialliance one, do not publish
  • This is so forks of the repository do not attempt to upload
• Upload the sphinx build and Zip packages to a subfolder of the web space
  • For non-tagged commits and pull requests, use the commit hash as the directory
  • For tagged commits, use the tag as the directory name
• Add an index entry to the index page
• When a pull request is merged or closed, delete that commit's directory

Several pieces are amiss in the ContentType documentation in 4.0:

• the intro doc needs to be reworked (e.g. it still refer to the xml:lang attribute)
• there is no inline documentation for the xml:lang substitute that is the MultilingualStringValue element

Also, for this last element, the type documentation - langString - could be completed with references to what is a langString and some syntax examples.

If this material is not already in the making, i can try to provide something (with a proper PR).

Add CITATION.cff file

ClassificationLevel is an item type and property name, redefinition in some outputs - ClassificationLevel (element) is a complex type and shows correctly, classificationLevel (originally attribute of type=”CategoryRelationCodeType” an internal enumeration of ("Nominal" | "Ordinal" | "Interval" | "Ratio" | "Continuous")) causes name conflict. Rename what was originally and attribute to classificationLevelCode.

ConditionalResultType -
ContributorType
ControlConstructType
ControlConstructGroupType
GridAttachmentType
DateType
QualityStatementType
QuestionGridType
RepresentedVariableType
SummaryStatisticType
TargetObjectType
TargetRepresentationType

Uploaded v3.0, v3.1, v3.2 and v3.3 to:
https://github.com/ddialliance/ddimodel/releases

Added basic description and links to ddialliance.org

One thing we might want to solve is the source code downloads:

we could solve these by checking in the old xsd:s for 3.x a 3.x branch and do releases from there.

Any thoughts or suggestions?

Add description for properties:

• URN
• Agency
• ID
• Version

https://github.com/ddialliance/ddimodel/blob/master/CompositeTypes/IdentifiableType/IdentifiableType.csv

• Include a suffix in the file names
  • If the commit is tagged, use the tag name (e.g., ddi-lifecycle-v4.0.zip)
  • If not tagged, use the date and/or commit hash (e.g., ddi-lifecycle-20231201.zip)
• Include a readme.txt at the top level of the zip
• Include a license.txt at the top level of the zip
• Include a PDF of the documentation
• Include HTML documentation
  • File based, not dirhtml from sphinx
• For the ddi-lifecycle package, don't make it a zip.
  • Zip the HTML docs if necessary, to limit the file count for performance

The documentation and UML models proved to be very useful in design and architecture discussions where digging thru XSDs is not practical. In the process I found a few issues:

• Quite a few cardinalities seem to be wrong in the documentation page, whereas they seem fine in the UML. For instance, in PhysicalStructureGroup, PhysicalStructureReference[PhysicalStructure] is 0..1 when it should be 0..*. Same with the self-reference PhysicalStructureGroupReference[PhysicalStructureGroup]. I noticed that happens in other groups as well, e.g. VariableGroup and PhysicalInstanceGroup.

• Shouldn't a PhysicalInstance have only one PhysicalStructure? I thought the UML cardinalities were right before, but in this case the documentation in the page seems to be right and the UML wrong. I'm not sure which cardinality to trust now.

• There are also some associations missing in the UML. For instance, VariableReference[Variable] in VariableScheme, RepresentedVariableReference[RepresentedVariable] in Variable, and ConceptualVariableReference[ConceptualVariable] in RepresentedVariable. I can't tell the reason why some associations appear and some others don't, given that the Sphinx diagrams I checked seemed to be correct.

• The Sphinx diagrams seem to have a weird way of representing self-references. Take VariableScheme, for instance: there is a VariableSchemeReference loop on the Properties box that doesn't make much sense to me, especially when there is a separate association to a VariableScheme oval as well. Why the loop in that unusual place? The same happens in all classes with self-references I checked, e.g. Variable, VariableGroup, PhysicalInstanceGroup, PhysicalStructureGroup. If there is any reason for that, it's not at all obvious.

Error: X needs to allow subtypes:

• Property 'BasedOnReference' in 'BasedOnObjectType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'ReviewObjectReference' in 'ApprovalReview' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'BasedOnReference' in 'BasedOnObjectType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'SourceItemReference' in 'ItemMapType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'TargetItemReference' in 'ItemMapType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'LocalObjectReference_Versionable' in 'LinkingMapType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'DepositoryObjectReference_Versionable' in 'LinkingMapType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'RelatedToReference_Versionable' in 'RelationshipType' uses datatype 'Versionable', which is abstract and does not allow subtypes
• Property 'ResourceObjectReference' in 'ResourceUsedType' uses datatype 'Versionable', which is abstract and does not allow subtypes

When we tried to use the json schema we got the following error:
Invalid schema: dereference error - SyntaxError: Error resolving $ref pointer "c:/Users/.../#/simpleType/nonNegativeInteger". Token "nonNegativeInteger" does not exist.

tried to find the type defintion for nonNegativeInteger but it does not seem to be in the json schema.

Add CONTRIBUTING.md file

In the prior XML schema of DDI Lifecycle, all properties were implicitly ordered within the XML.

In the new model, we must explicitly set the property to be Ordered if required. This was only done for Sequence so far, there are other properties that should have their Ordered set to true.

Should be included in the readme and the generated documentation.
In the sphinx documentation we could set the version to 4.0 and give it the name 4.0beta1 in release (or possibly both version & release as 4.0beta1):
https://www.sphinx-doc.org/en/master/usage/configuration.html

Can we prevent users from forking the master branch, ie only allow them to do so from a develop branch?

Generated C# code has some warnings on conditional statements for properties of datatype float and decimal.

Warnings:
warning CS0472: The result of the expression is always 'true' since a value of type 'decimal' is never equal to 'null' of type 'decimal?'
warning CS0472: The result of the expression is always 'true' since a value of type 'decimal' is never equal to 'null' of type 'float?'

Identification properties have been simplified to a set of required identifiers (URN, Agency, ID, and Version). Versionable and Maintainable are also collapsed as being redundant in a serialized structure. Other properties need review in order to determine which should be included in Identifiable and Versionable element types.

Identifiable are defined those needing identification for processing within a set of objects

Versionable are those intended for reuse

This is TC-239 https://ddi-alliance.atlassian.net/browse/TC-239?atlOrigin=eyJpIjoiZjRiMTk5N2EzMTBlNGJjMGJmY2U0MjE1OTU5YTIzNzEiLCJwIjoiaiJ9

If I'm not mistaken, In DDI L 3.3 it's not possible to attach an AnalysisUnit to a logical record in a physical instance. Is there a practical way of documenting the analysisUnit in an object higher than the variable level?