OpenC2's approach to the problem is "formats".  Just like a real number can
be formatted with variable precision in decimal or scientific notation,
strings in various formats represent a single IEEE 754 number in the model.
The model says property x is a number, but the format says it is
represented as 1234.678 or 0.123E+04.  If those were treated as strings
they would be completely different values, not the same value.

Similarly, an IPv6 network address has two components: ipv6-address and
prefix-length (https://datatracker.ietf.org/doc/html/rfc4291#section-2.3).
The model defines type IPv6-Net with two properties: a 128 bit value and an
integer, but they are formatted as a single string with slash separator,
e.g., 2001:0DB8::CD30:0:0:0:0/60.

There is no concept of an "IP network string" property plus separate
subproperties, the only things in the OpenC2 model are the single type
with two properties and a format.

I'm sure there is a way forward somewhere that doesn't turn into a kludge.
We've had formats since I started programming in FORTRAN IV.

Dave


On Wed, Aug 4, 2021 at 3:27 PM Gary O'Neall <[email protected]> wrote:

> Hi David,
>
>
> Just saw your reply after sending mine – sounds like we’re thinking
> similar approaches.
>
>
>
> Good point on the LicenseRef’s.
>
>
>
> We have a problem today in not being able to reference licenseRef’s
> external to the SPDX document within an expression.
>
>
>
> Gary
>
>
>
> *From:* [email protected] <[email protected]> *On Behalf Of
> *David Kemp
> *Sent:* Wednesday, August 4, 2021 11:28 AM
> *To:* Alexios Zavras <[email protected]>
> *Cc:* Sean Barnum <[email protected]>; SPDX-list <[email protected]
> >
> *Subject:* Re: [EXT] [spdx-tech] Element IDs
>
>
>
> SPDX 2.2 has license expressions, which represent multiple elements
> (license IDs and operators) in a single string.  If RDF is going to reason
> about license expressions, it must be able to know which license IDs and
> which operators are present.  We don't call license expressions
> "serialization" even though they define an equivalence between the AST and
> a string.
>
> Similarly, RDF must be able to reason about an Element's "namespace" and
> its "inNsid", not just some idString blob as a property value.  Standard
> ways of representing individual elements in compound strings are ABNF and
> regular expression named groups.  The model can call it an idString
> property, but it must also define the "virtual properties" within it in a
> manner that allows different serializations treat the virtual properties as
> real ones - every element has a "namespace" property and getter and setter
> methods for that property.
>
> Dave
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4154): https://lists.spdx.org/g/Spdx-tech/message/4154
Mute This Topic: https://lists.spdx.org/mt/84649986/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to