OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [EXT] [cti-comment] clarification question: new SDO vs SCO types

Hi Mark,

For new objects defined with the extension mechanism in Section 7.3, the extension_type property MUST be present (from the extensions property description in Section 3.2). We can know what type of object it is by whether the value of this property is "new-sdo", "new-sco", or "new-sro".

That wouldn't work for custom SDOs or SCOs using the now-deprecated method of custom object types. So another way to discern the category of the object to infer it from what common required properties are present on it. Looking at the table of common properties at the end of Section 3.2, one could say that if an object's type property is not "bundle" and the created and modified properties are not present, then it is a SCO. This doesn't work for differentiating SDOs and SROs since the same common properties are optional and required for them. But one might assume that custom SDOs are more likely than custom SROs and treat all custom objects that don't use extensions and have both a created and a modified property as SDOs. I'm not sure there's a way to differentiate between old-style (deprecated) custom SDOs and SROs, unfortunately.

Chris Lenk

-----Original Message-----
From: cti-comment@lists.oasis-open.org <cti-comment@lists.oasis-open.org> On Behalf Of Mark Finlayson
Sent: Wednesday, March 31, 2021 9:27 AM
To: cti-comment@lists.oasis-open.org
Subject: [EXT] [cti-comment] clarification question: new SDO vs SCO types

Hi again,

I have one more clarification question that I am hoping someone can answer. In the specification there doesn't seem to be any property that distinguishes SDOs from SCOs, other than the "type" property (meaning, you have to know the type hierarchy to know that "location" is an SDO but "email-message" is an SCO).

How, then, does an implementer know if a newly defined type, provided by the extension mechanism, is an SDO or SCO? The answer may possible be: 
they don't.

While I can't see a big problem with not knowing this information for a particular object, I can see two minor possible problems: (1) the "consists-of" relationship can take as a a target "all STIX CSOs", so if you don't know which newly defined objects are CSOs you don't know which types are valid in this position. I may have missed analogous cases elsewhere in the specification. And, (2), there are semantic differences between the two classes and so implementations may wish to handle SDOs vs SCOs differently, and so not knowing if a newly defined type is one or the other would make different behaviors for SDOs for SCOs problematic.

Any insight you can give into this matter would be much appreciated. Best,


Mark A. Finlayson, Ph.D.
Eminent Scholar Chaired Associate Professor, FIU KFSCIS, Cognac Lab Interim Associate Director, FIU KFSCIS Edison Fellow for AI, USPTO
11200 SW 8th Street, CASE Room 362, Miami, FL 33199
+1.305.348.7988 (office); +1.617.515.0708 (mobile); markaf@fiu.edu

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]