CIM Issues » CIM Joint Issues

What is the reason behind moving the type attribute outside the Document class? What was the reason of adding the DocumentKind enumeration in the Document class instead of leaving the type attribute as a free String? As you know, in Europe we are relying in our enumerations and therefore you are doing a restriction in the canonical CIM which for us is not acceptable.

ENTSO-E is totally against this change because we are using the type attribute in every market profile in Europe, which would imply modifying all of them. Although moving the type to attribute to the MarketDocument class does not have semantical implications, I foresee several troubles with the GUID consistency in the Enterprise Architect file which we really want to avoid.

Please leave the type attribute as it is. Thanks!

I support Alvaro's commons that it is important to understand the use case behind the proposed changes.
I am concern that we have "overloaded" cim:Document by having it to be a general class to all of the following classes:

- Agreement
- Analytic
- AssetGroup
- AssetModelCatalogueItem
- AuxiliaryAccount
- BankAccount
- BaseWork
- Bid
- BillDeterminant
- BusinessPlan
- ChargeType
- CongestionRevenueRight
- CustomerAccount
- CustomerBillingInfo
- EnergyTransaction
- ErpDocument
- Incident
- MarketDocument
- MarketFactors
- MarketSkill
- MarketStatment
- MerchantAccount
- MeterReadSchedule
- OperationRestriction
- OperationalTag
- Outage
- OutageOrder
- OutagePlan
- PassThroughBill
- PlannedOutageNotification
- PowerQualityPricing
- PricingStructure
- Procedure
- ProcedureDataSet
- SafetyDocument
- ServiceGuarantee
- Settlement
- Skill
- Specification
- StandardIndustryCode
- SwitchingOrder
- SwirtchingPlan
- SwitchingPlanRequest
- Tariff
- TariffProfile
- TimeSchedule
- TroubleOrder
- TroubleTicket
- WorkBillingInfo
- WorkDocument
- WorkOrder
- WorkRequest

I have a problem to see that all the added information is relevant for all the specialization of Document. If we agree to make update to cim:Document, we should consider to create a general class between IdentifiedObject and Document.

Current note on cim:Document:
"
Parent class for different groupings of information collected and managed as a part of a business process. It will frequently contain references to other objects, such as assets, people and power system resources.
"

Current note on cim:Incident:
"
Description of a problem in the field that may be reported in a trouble ticket or come from another source. It may have to do with an outage.
"

I am proposing to call this cim:Record with the following note:
"
Generalized class that represent the registration and manage records of different types. This class serves as a foundation for creating specific record instances across different contexts, providing a consistent structure for managing and tracking relevant information. It encapsulates essential information that is common for all specialisation of a record.
"

Relevant attribute are:
- created: DataTime
- lastModified : DataTime
- version: String
- recordStatus: recordStatusKind
- Editor > Editor
Approver -> Approver

Updated definition of cim:Document:
"
Generalized class that represent and managed the encapsulated of specialised document that refers to a digital or electronic record that contains information, often structured in a specific format. Document class serves as a blueprint for creating instances of documents, providing a standardized way to manage, organize, and manipulate a collection of one or more objects of different classes content within the application.
"

The definition of the cim:Document do depend of the inclusion of cim:Record.

From CIM Feature Proposal Mtg: 2/8/2024: This issue is described as "There is a desire to modify the Document class" please include in the issue the described use case requirements to justify a proposed change.