1. OMG Mailing List
  2. Specification Common Elements (SSCE) 1.0 Finalization Task Force mailing list

Open Issues

  • Issues not resolved
  • Name: sce-ftf
  • Issues Count: 46

Issues Summary

Key Issue Reported Fixed Disposition Status
SCE-119 Refences to non-existing specifications SCE 1.0b1 open
SCE-121 Element not replaced with BaseElement in Table 17 SCE 1.0b1 open
SCE-96 More work for backwards compatibility needed SCE 1.0b1 open
SCE-117 Frequently changing Namespace URIs cause market fragmentation SCE 1.0b1 open
SCE-109 XSD Chapter Outdated with incorrect text. SDMN 1.0b1 open
SCE-107 Annotation class provides no value and conflicts with downstream languages SDMN 1.0b1 open
SCE-105 tag attribute is a string list in MM but just a string in XSD SCE 1.0b1 open
SCE-103 Some SCE Elements are concrete instead of abstract SDMN 1.0b1 open
SCE-101 importType Property description obsolete and too restrictive SDMN 1.0b1 open
SCE-99 XSD copied the wrong extension elements from BPMN and lacks the important ones SCE 1.0b1 open
SCE-92 Acknowledgements for SCE 1.0 contributors needed SCE 1.0b1 open
SCE-91 Copyright section needs update SCE 1.0b1 open
SCE-90 Using "SCE" as a prefix for class names is unnecessary SCE 1.0b1 open
SCE-115 Small inconsistencies between DI MM and XSD SCE 1.0b1 open
SCE-113 Label should not have a redundant text attribute SCE 1.0b1 open
SCE-111 modelElement is not optional SCE 1.0b1 open
SCE-85 Exporter information is located in the wrong class SCE 1.0b1 open
SCE-53 SCEDI cannot be directly re-used as-is SDMN 1.0b1 open
SCE-27 There are editorial issues in the Specification SCE 1.0b1 open
SCE-3 SCE Metamodel Relationships do not have labels SCE 1.0b1 open
SCE-37 Not enough need for vocabulary mechanisms in SCE SCE 1.0b1 open
SCE-67 expressionLanguage and typeLanguage are not optional SCE 1.0b1 open
SCE-63 The pattern of naming association role names in the metamodel is redundant SCE 1.0b1 open
SCE-62 How can other Expressions languages be used? SCE 1.0b1 open
SCE-48 Unclear scope of identifiers and use of "human" SCE 1.0a1 open
SCE-47 Inconsistent capitalization in humanID and aliasID compared to id SCE 1.0a1 open
SCE-46 Fundamental problem - cannot represent the properties/characteristics of an Element PPMN 1.0b1 open
SCE-44 SCE vocabularies should reuse MVF SCE 1.0a1 open
SCE-40 SCE is not backwards compatible with the original BPM+ specs SCE 1.0b1 open
SCE-36 The description of Import in the Spec needs updating SCE 1.0b1 open
SCE-35 Incorrect Mapping from Metamodel to XSD SCE 1.0a1 open
SCE-34 wrong type of element in XSD for ModelArtifact -- should be a ref SCE 1.0b1 open
SCE-33 suggest KnownColor be renamed tKnownColor SCE 1.0b1 open
SCE-32 suggest AlignmentKind be renamed 'tAlignmentKind' SCE 1.0b1 open
SCE-31 Consider renaming rgb to tRGB SCE 1.0b1 open
SCE-25 Change RelationshipKinds from a Vocabulary to a UML Enumeration SCE 1.0b1 open
SCE-23 Add Mapping of SCE Term functions to MVF in Spec SCE 1.0b1 open
SCE-22 SCE Relationship Kinds Should Cover All BPM+ Relationships SCE 1.0b1 open
SCE-2 Common attributes expressionLanguage and typeLanguage are missing SCE 1.0b1 open
SCE-45 SemanticReference::conceptNamespace oddly named SCE 1.0a1 open
SCE-42 Move definition of instance elements to PMN SCE 1.0b1 open
SCE-28 Figure 11 Annotations Metamodel is incorrect SCE 1.0b1 open
SCE-6 Add Notations for Relationship Kinds in SCE SCE 1.0b1 open
SCE-1 Adjust the structural elements of SCE such that they are backwards compatible with BPMN, CMMN, and DMN. SCE 1.0b1 open
BACM11-18 BACM Turtle File should use https rather than http BACM 1.0b2 open
SCE-4 Add Labels for all SDMN Metamodel Relationships SCE 1.0b1 open

Issues Descriptions

Refences to non-existing specifications

  • Key: SCE-119
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    For context, SCE contains references to KPMN & PPMN as standards that had planed to use SCE. However, the KPMN Finalization Task Force decided not to finish their specification and did not submit an FTF report. As a result, KPMN is not a viable specification for SCE to reference. PPMN has yet to be finalized and although its Finalization Task Force is active, it is not far enough along to be sure that it will pass all checks & votes in time and be adopted.

  • Reported: SCE 1.0b1 — Fri, 22 Mar 2024 21:01 GMT
  • Updated: Mon, 1 Apr 2024 18:37 GMT

Element not replaced with BaseElement in Table 17

  • Key: SCE-121
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The resolution of SCE-96, which replaced Element with BaseElement, has not been applied in Table 17 "ElementRelationship Attributes and/or Associations" in the types and descriptions of sourceRef and targetRef.

  • Reported: SCE 1.0b1 — Mon, 1 Apr 2024 17:21 GMT
  • Updated: Mon, 1 Apr 2024 18:37 GMT

More work for backwards compatibility needed


Frequently changing Namespace URIs cause market fragmentation

  • Key: SCE-117
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    Based on experience with DMN, frequently changing namespace URIs, i.e. with every minor revision, cause market fragmentation across supported specification versions, as it cannot be assumed that all vendors update to the latest version of the spec at the same time, if at all.

    This forces users to do unnecessary version migrations or their models would not be opened by a tool as invalid or outdated.

    Revisions by an RTF only have a mandate to fix bugs and should therefore only add a limited amount of new language elements. Thus only a small percentage of models created using the new spec version actually use new features. So the majority of models could still be opened and edited in older tools if it weren't for the namespace to completely prevent that.

  • Reported: SCE 1.0b1 — Mon, 5 Feb 2024 23:57 GMT
  • Updated: Sat, 10 Feb 2024 01:21 GMT

XSD Chapter Outdated with incorrect text.

  • Key: SCE-109
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    XSD Chapter Outdated with incorrect text that was copied from the DMN specification.

  • Reported: SDMN 1.0b1 — Wed, 31 Jan 2024 23:42 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT

Annotation class provides no value and conflicts with downstream languages

  • Key: SCE-107
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Annotation class, an abstract class, is no longer necessary since Documentation and Category are no longer subclassing it. With only Attachment subclassing Annotation, it provides no value. It also adds additional structural overhead that is not needed. Further, using the name "Annotation" conflicts with downstream language PPMN that want to use it for an unrelated language element.

  • Reported: SDMN 1.0b1 — Wed, 31 Jan 2024 17:52 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT
  • Attachments:

tag attribute is a string list in MM but just a string in XSD


Some SCE Elements are concrete instead of abstract


importType Property description obsolete and too restrictive

  • Key: SCE-101
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The description of the import element was copied from BPMN and contains information that are not appropriate to SCE, which is an infrastructure specification and not specific to any modeling language.
    Note that this text was updated by SCE-36, but the update was not comprehensive enough

  • Reported: SDMN 1.0b1 — Mon, 29 Jan 2024 20:29 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT

XSD copied the wrong extension elements from BPMN and lacks the important ones

  • Key: SCE-99
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    SCE copied extension classes from BPMN that were meant for extensibility of the metamodel and are explicitly declared to not show in the XML schema because the XML already has built-in extension mechanisms. That's what the X in XML stands for

    The XSD is missing the extensionElements container that BPMN, CMMN & DMN are using to store XML extension elements in a way that schema validation is not ambigious.

    The SCE XSD even includes the statements that BPMN made about these classes, e.g.:

    ExtensionDefinition: This type is not applicable when the XML schema interchange is used, since XSD Complex Types already satisfy this requirement.

    ExtensionAttributeDefinition/ExtensionAttributeValue: This type is not applicable when the XML schema interchange is used; since the XSD mechanisms for supporting "AnyAttribute" and "Any" type already satisfy this requirement.

    extensionDefinitionRef/extensionAttributeValueRef: This association is not applicable when the XML schema interchange is used, since the XSD mechanisms for supporting anyAttribute and any element already satisfy this requirement.

    BPMN had the classes ExtensionDefinition, ExtensionAttributeDefinition, ExtensionAttributeValue only in the UML metamodel but not in the XML schema. During the RFP phase, SCE had already removed the classes from its UML metamodel and specification text because UML also has built-in extension mechanisms. However, it seems like they were automatically generated into the XML schema and are still in there.

    In addition, the XSD also contains Adornment types that are based on the extension type, which should have not been in the XSD.

  • Reported: SCE 1.0b1 — Fri, 26 Jan 2024 21:56 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT

Acknowledgements for SCE 1.0 contributors needed

  • Key: SCE-92
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The acknowledgement section contains the information from the RFP, but not the FTF

  • Reported: SCE 1.0b1 — Mon, 15 Jan 2024 18:36 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT

Copyright section needs update

  • Key: SCE-91
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The copyright section contains the RFP version copyrights, but not the FTF ones.

  • Reported: SCE 1.0b1 — Mon, 15 Jan 2024 18:34 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT

Using "SCE" as a prefix for class names is unnecessary


Small inconsistencies between DI MM and XSD

  • Key: SCE-115
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The following names differ between Diagram Interchange MM and XSD:

    • SCEDI::Diagram.sharedStyleRef
    • SCEDI::Diagram.localStyle
    • SCEDI::DiagramElement.sharedStyleRef
    • SCEDI::DiagramElement.localStyle
    • SCEDI::Style.labelHorizontalAlignement
  • Reported: SCE 1.0b1 — Fri, 2 Feb 2024 20:38 GMT
  • Updated: Fri, 9 Feb 2024 01:16 GMT
  • Attachments:

Label should not have a redundant text attribute

  • Key: SCE-113
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The attribute text of the class Label should not have been copied from DMN because it is not a "Common Element", i.e., it doesn't exist in BPMN & CMMN. Also it doesn't conform to the design principle of Diagram Interchange to avoid redundancy.

  • Reported: SCE 1.0b1 — Fri, 2 Feb 2024 16:27 GMT
  • Updated: Fri, 9 Feb 2024 01:15 GMT
  • Attachments:

modelElement is not optional


Exporter information is located in the wrong class


SCEDI cannot be directly re-used as-is




Not enough need for vocabulary mechanisms in SCE

  • Key: SCE-37
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    As part of finalizing an minimum viable product for SCE, remove the vocabulary mechanism. There has been much discussion about the topic and the necessity for the capability has been questioned.
    In any case, the current mechanism doesn't work, especially which the proposed change to Semantic Reference.
    We may need to include some sort of extendible enumeration capability at some point. This will be handled in conjunction with review of BKPMN, PPMN, PMN, and SDMN enumeration requirements.

  • Reported: SCE 1.0b1 — Sat, 28 Jan 2023 00:12 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

expressionLanguage and typeLanguage are not optional

  • Key: SCE-67
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    SCE-52 introduced default values expressionLanguage and typeLanguage but did not set the cardinality to [0..1] in metamodel and spec text. In the XSD they are already optional. This is also needed for backwards compatibility to existing specs.

  • Reported: SCE 1.0b1 — Sat, 23 Dec 2023 23:31 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT
  • Attachments:

The pattern of naming association role names in the metamodel is redundant


How can other Expressions languages be used?

  • Key: SCE-62
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    How can other Expressions languages (other than FEEL) be used?
    SCE itself doesn't provide ways of dealing with expressions other than defining the default languages. It will be updated by languages that use SCE and have Expressions. The expression itself will have an attribute to define (that is, override the default) language.
    This should be explained in SCE.

  • Reported: SCE 1.0b1 — Mon, 18 Dec 2023 18:51 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Unclear scope of identifiers and use of "human"

  • Key: SCE-48
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The documentation for id says "uniquely identify" but not the scope - within a single model, universally?
    And for humanID (sic) it's also vague: "the uniqueness of this identifier within a model or relative to some other context."

    The intended usage is unclear - calling it "human" does not seem helpful since it's presumably not for human consumption e.g. for display on a diagram?
    And "human" is also wrong if the model was generated by a tool, i.e. the "modeler" is not a human.

    Without further rules, or a compliance point, interoperability becomes unnecessarily hard.

  • Reported: SCE 1.0a1 — Tue, 18 Jul 2023 19:06 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Inconsistent capitalization in humanID and aliasID compared to id


Fundamental problem - cannot represent the properties/characteristics of an Element

  • Key: SCE-46
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ElementType seems to have no way to represent the properties of the type, and TypedElement seems to have no way to represent the values of any properties.
    All you can represent is ElementRelationships.
    8.1.3 says "entity-type “Thoroughbred Horse” that is used to specific the basic characteristics of thoroughbred horses." but there is nothing I can see that could represent those characteristics, nor their values for the Element Secretariat.

  • Reported: PPMN 1.0b1 — Tue, 18 Jul 2023 18:55 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

SCE vocabularies should reuse MVF

  • Key: SCE-44
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Though Vocabulary in SCE would correspond to Dictionary in MVF, since SemanticElement in SCE corresponds with MVFEntry in MVF.

  • Reported: SCE 1.0a1 — Mon, 17 Jul 2023 18:52 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

SCE is not backwards compatible with the original BPM+ specs


The description of Import in the Spec needs updating

  • Key: SCE-36
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Import section has some inaccuracies and should be refactored to be a very general mechanism as a foundation for the specs that use SCE. Further import constraints will have to be defined for each language.

  • Reported: SCE 1.0b1 — Fri, 27 Jan 2023 23:57 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Incorrect Mapping from Metamodel to XSD

  • Key: SCE-35
  • Status: open   Implementation work Blocked
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The current SCE XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
    To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.

  • Reported: SCE 1.0a1 — Tue, 17 Jan 2023 22:55 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT
  • Attachments:

wrong type of element in XSD for ModelArtifact -- should be a ref

  • Key: SCE-34
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    if this is to be the target of using substitutionGroup, then

    <xsd:element name="modelArtifact" type="sce:tModelArtifact" minOccurs="0" maxOccurs="unbounded">

    should be:

    <xsd:element ref="sce:ModelArtifact" minOccurs="0" maxOccurs="unbounded"/>

    the wrong type of element in XSD for ModelArtifact – should be a ref

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:47 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

suggest KnownColor be renamed tKnownColor

  • Key: SCE-33
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    all types should start with 't'

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:39 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

suggest AlignmentKind be renamed 'tAlignmentKind'

  • Key: SCE-32
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    all types should start with 't'

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:36 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Consider renaming rgb to tRGB

  • Key: SCE-31
  • Status: open  
  • Source: University of Utah ( Mr. Robert Lario)
  • Summary:

    I would suggest all acronyms be capitalized. All types start with 't'.

  • Reported: SCE 1.0b1 — Thu, 29 Dec 2022 03:33 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Change RelationshipKinds from a Vocabulary to a UML Enumeration

  • Key: SCE-25
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    RelationshipKinds should be well-known set of kinds. These kinds have semantic meaning and have notational impacts. Thus, they should be part of the normative spec through a standard enumeration (or perhaps sub-classes).

  • Reported: SCE 1.0b1 — Tue, 6 Sep 2022 15:37 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Add Mapping of SCE Term functions to MVF in Spec

  • Key: SCE-23
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The changes to the current SCEVocabulary models should be mapped to MVF.

  • Reported: SCE 1.0b1 — Tue, 30 Aug 2022 20:13 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

SCE Relationship Kinds Should Cover All BPM+ Relationships

  • Key: SCE-22
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Basically all lines between model elements in all the BPM+ models (BPMN, CMMN, DMN, SDMN, BKPMN, Parties, and PPMN) should be (theoretically maybe) derived from one of the SCE Relationship Kinds.
    And if we define the basic notation for each of these relationships, then all subsequent models will provide consistent relationship notations.

  • Reported: SCE 1.0b1 — Mon, 8 Aug 2022 20:20 GMT
  • Updated: Tue, 23 Jan 2024 00:38 GMT

Common attributes expressionLanguage and typeLanguage are missing

  • Key: SCE-2
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    They are optional properties and can be used by multiple languages, including the original BPM+ languages.

  • Reported: SCE 1.0b1 — Tue, 5 Jul 2022 21:45 GMT
  • Updated: Thu, 11 Jan 2024 11:27 GMT
  • Attachments:

SemanticReference::conceptNamespace oddly named

  • Key: SCE-45
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Name is odd if it's meant to represent a specific version. For example OWL uses versionIRI for this.

  • Reported: SCE 1.0a1 — Mon, 17 Jul 2023 18:56 GMT
  • Updated: Thu, 11 Jan 2024 00:50 GMT

Move definition of instance elements to PMN

  • Key: SCE-42
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The inclusion of instance elements for modeling and exchange is limited in BPM+ to PMN and PPMN (which is dependent on PMN). It is not currently considered to be a generic enough feature to be included in SCE, since most BPM+ languages do not need it.
    Thus, in the interest in creating an MVP SCE, it is suggested here that the instance definition elements be removed in SCE and placed in PMN where it is first needed.
    This issue was identified through issue SCE-40, which deals with making SCE backwards compatible to the original BPM+ languages. However, there are other elements besides the SCEIntances package that need to be moved, such as TypedElement.
    The proposal for this issue will be layered upon (dependent on) the resolution for SCE-40.

  • Reported: SCE 1.0b1 — Wed, 22 Mar 2023 16:11 GMT
  • Updated: Thu, 11 Jan 2024 00:50 GMT

Figure 11 Annotations Metamodel is incorrect

  • Key: SCE-28
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 11 Annotations shows the older version of SCEElement. Original version did not have a "root" element. One was added in another issue with then made this figure incorrect. This issue was caused by that change.

  • Reported: SCE 1.0b1 — Fri, 7 Oct 2022 17:25 GMT
  • Updated: Thu, 11 Jan 2024 00:50 GMT
  • Attachments:

Add Notations for Relationship Kinds in SCE

  • Key: SCE-6
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This will ensure that all downstream languages will use the same notation if they have connectors based on the RelationshipKinds.

  • Reported: SCE 1.0b1 — Wed, 27 Jul 2022 22:27 GMT
  • Updated: Thu, 11 Jan 2024 00:50 GMT

Adjust the structural elements of SCE such that they are backwards compatible with BPMN, CMMN, and DMN.

  • Key: SCE-1
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This will probably affect the packaging structures more than anything.
    If done properly, it may be possible for current BPM+ vendors to overlay those models on top of SCE.
    Mr. Falko Menge has already done some testing of the BPMN schema utilizing SCE. There are some breakages that may be fixed through SCE adjustments.
    We may need to reconsider the PPMN requirements for Instance packages as part of SCE (and move to PPMN directly).

  • Reported: SCE 1.0b1 — Tue, 5 Jul 2022 21:41 GMT
  • Updated: Thu, 11 Jan 2024 00:50 GMT

BACM Turtle File should use https rather than http

  • Key: BACM11-18
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The turtle file currently uses the old, insecure http protocol and per SMSC policy must use https.

    The resolution to this issue mainly impacts the machine-readable turtle file and should not impact the specification document aside from any place where the URI for the turtle file is mentioned.

  • Reported: BACM 1.0b2 — Thu, 21 Dec 2023 18:31 GMT
  • Updated: Thu, 21 Dec 2023 20:28 GMT

Add Labels for all SDMN Metamodel Relationships

  • Key: SCE-4
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    to be MOF compliance

  • Reported: SCE 1.0b1 — Mon, 18 Jul 2022 19:47 GMT
  • Updated: Thu, 2 Feb 2023 01:00 GMT