Re: [spdx-tech] SPDX 3.0

[Gary O'Neall]

Hi Benedicte,

 

Responses inline below.

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of 
Benedicte Presse
Sent: Wednesday, February 21, 2024 6:33 AM
To: spdx-tech@lists.spdx.org
Subject: [spdx-tech] SPDX 3.0

 

Hi all,

 

I read some informations about SPDX, and especially that the 3.0 SPDX model 
will soon be released (I saw that a release candidate has been publied).

Could you tell me when it will be delivered ?

[G.O.] We just released the RC2 version of the model.  This is the version we 
will be taking through the OMG standards process and we expect there will be 
some feedback requiring (hopefully minor) changes.  That being said, we would 
encourage anyone interested in SPDX 3.0 to start evaluating/using the RC2 
version.  This would help provide valuable feedback if you run into any issues. 
 Also note that we separate the model from the full spec.  The 3.0-RC2 version 
of the spec should be out very soon – within a week or so.  The spec will 
provide a more readable version of the model plus various supporting 
documentation.  We’ll send out a message on this distribution list once it is 
ready.

Will it be possible to migrate from 2.0 to 3.0 ? 

[G.O.] Yes – There is a draft document describing the migration from SPDX 2.X 
to SPDX 3.0: 
https://docs.google.com/document/d/1-olHRnX1CssUS67Psv_sAq9Vd-pc81HF8MM0hA7M0hg/edit#heading=h.uzojmh0kkl
 – I’m in the process of updating the document for the RC2 release.

 

Thank in advance for your answer,

Best regards,

Benedicte Presse





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5540): https://lists.spdx.org/g/Spdx-tech/message/5540
Mute This Topic: https://lists.spdx.org/mt/104489065/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0: When to use a property or relationship

[David Kemp]

As a general rule, properties are used when an element's content is known
at the time the element is created, while either references or
relationships are used when that content is expected to change over time.
For example, a hypothetical "Person" element would include immutable
properties of a specific person, but would not include a "child" property
because children can pop up later.  A Person element could include a parent
property because parents don't change, and/or a "parentOf" relationship
could be used to cover more dynamic possibilities like unknown or sealed
biological parents that could be discovered or unsealed after the child
instance is created.

So if I understand the example, Option A should work since the status of a
specific product with respect to a specific vulnerability should not
change.  And if it does change, a new VEX "urn:spdx.dev:vex-cve-2020-2849-2"
will be issued to supersede "-1".

But I'm not sure how "Our version of this package was modified" gets
translated to "We are not using this component" with a "product" property.
Are "we" creating a product that has the identical name, including version
number, as a package (urn:npmjs.com:elliptic-6.5.3)?  If so, how is the
unaffected package or product distinguished from the original/unmodified
baseline that presumably is affected by the vulnerablity?

v/r,
David



On Mon, Apr 17, 2023 at 11:18 AM Thomas Steenbergen 
wrote:

> Hi all,
>
> In April 12th Defects meeting we were discussing changing the security
> profile
> 
> to be better able to support VEX use cases.
>
> We ran into the reoccurring issue of when to use a property and when to
> use a relationship, included some examples below.
> Know we discuss this in a recent tech call. Do we have any written
> guidance/design principles? Can we discuss this further tomorrow?
>
> Below an excerpt of SPDX 3.0 Vulnerability example as currently found on
> GitHub, issue we found is that changing any VEX property would require
> publishing the whole vulnerability which is not ideal. Idea is to move VEX
> and maybe other categorization into their own elements so SPDX creator can
> update just the categorization and timestamp for each categorization
> creation using SPDX 3.0 Element's creationInfo.
>
> "@type": "Vulnerability",
> "@id": "urn:spdx.dev:cve-2020-2849",
> "summary": "Use of a Broken or Risky Cryptographic Algorithm",
> "description": "The npm package `elliptic` before version 6.5.4 are
> vulnerable to Cryptographic Issues via the secp256k1 implementation in
> elliptic/ec/key.js. There is no check to confirm that the public key point
> passed into the derive function actually exists on the secp256k1 curve.
> This results in the potential for the private key used in this
> implementation to be revealed after a number of ECDH operations are
> performed.",
> "modified": "2021-03-08T16:02:43Z",
> "published": "2021-03-08T16:06:50Z",
> "categorizations": [
>   {
> "@type": "VexNotAffectedVulnerabilityCategorization ",
> "@id": "urn:spdx.dev:vex-cve-2020-2849",
> "status": "notAffected",
> "impact": "Our version of this package was modified and does not
> include code affected by cve-2020-2849.",
> "justification": "vulnerabileCodeNotPresent",
> "source": "https://vex-system...;,
>   }
> ],
> {
>"@type": "Relationship",
>"relationshipType": "advisory",
>"to": "urn:spdx.dev:vex-cve-2020-2849",
>"from": ["urn:npmjs.com:elliptic-6.5.3", "urn:npmjs.com:
> elliptic-6.5.3-subcomponent-1"]
> },
>
>
> Option A: Only use properties to link a VEX to other SPDX elements - easy
> for VEX publishers and readers as everything is in 1element
>   {
> "@type": "VexNotAffectedVulnerabilityCategorization",
> "@id": "urn:spdx.dev:vex-cve-2020-2849-1",
> "status": "notAffected",
> "impact": "We are not using this component",
> "justification": "componentNotPresent",
> "source": "https://vex-system...;,
> "elements": {
>   "product": ["urn:npmjs.com:elliptic-6.5.3"],
>   "packages": ["urn:npmjs.com:elliptic-6.5.3", "urn:npmjs.com:
> elliptic-6.5.3-subcomponent-1"],
>   "files": ["urn:npmjs.com:elliptic-6.5.3-subcomponent-files-1"],
>   "snippets": ["urn:npmjs.com:
> elliptic-6.5.3-subcomponent-snippet-1"],
>   "vulnerabilities": [ "urn:spdx.dev:cve-2020-2849" ]
> }
>
> Option B: Specific property for vulnerability as VEX is always connected
> to one or more vulnerabilities, using relationships for linking to packages
> / "products", files, snippets as they may change.
>
> {
>   "@type": "VexNotAffectedVulnerabilityCategorization ",
>   "@id": "urn:spdx.dev:vex-cve-2020-2849",
>   "status": "notAffected",
>   "impact": "Our version of this package was modified and does not include
> code affected by cve-2020-2849.",
>   "justification": "vulnerabileCodeNotPresent",
>   "source": 

Re: [spdx-tech] SPDX 3.0 Minimal Serialization

[Gary O'Neall]

Good point Steve – Subject change.

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Steve 
Kilbane
Sent: Friday, June 24, 2022 12:13 AM
To: 'SPDX Technical Mailing List' 
Subject: Re: [spdx-tech] No SPDX tech meeting this week

 

Hi all,

 

Might I suggest a change of subject line before this goes too far? I’m just 
thinking of the poor souls in the future grepping through the archives.

 

steve

 

From: Spdx-tech@lists.spdx.org   
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of Gary 
O'Neall
Sent: 23 June 2022 22:33
To: 'David Kemp' mailto:dk1...@gmail.com> >; 'SPDX Technical 
Mailing List' mailto:Spdx-tech@lists.spdx.org> >
Subject: Re: [spdx-tech] No SPDX tech meeting this week

 


[External]

 

Hi David,

 

Definitely got me thinking about the serializations.

 

A couple of thoughts:

*   Adding a prefix of “@” almost creates a JSON-LD serialization format 
since JSON-LD includes the concept of types and ID’s.  I need to think about it 
some more, but we may just want to use JSON-LD as the “unoptimized” format.
*   Currently in JSON, we distinguish the type at the list level (e.g. 
separate packages array, files array, relationships array, etc.).  This 
approach is closer to what many implementations expect.

 

I still like the approach have the logical model having separate data types (or 
“structs”) for collections of properties we want to “optimize” in the 
serialization.

 

Cheers,
Gary

 

From: Spdx-tech@lists.spdx.org   
mailto:Spdx-tech@lists.spdx.org> > On Behalf Of 
David Kemp
Sent: Thursday, June 23, 2022 11:50 AM
To: SPDX Technical Mailing List mailto:Spdx-tech@lists.spdx.org> >
Subject: Re: [spdx-tech] No SPDX tech meeting this week

 

SPDX v3 Document and Transfer Unit

 

The SPDX v3 model https://github.com/spdx/spdx-3-model/blob/main/model.png 

  now shows Collection as not being an Element.  This highlights the main 
difference between v2 and v3: v2 defines the structure of a document while v3 
follows the 3T SBOM approach of defining the elements in a graph. V2 defines 
serialized data directly, while v3 defines Element content prior to 
serialization.

In v3:
1) Everything is an Element
2) An Element is metadata about something (a file, a package, an identity), not 
the content of the thing described by the metadata
3) A file containing serialized data is a thing.  An Element describing a file 
containing serialized data is metadata about that file.

So the difference between Document as the structure of serialized data and 
Document as metadata about that file (an Element) is critical.  The name of the 
type labeled Document in the model depends on whether that type defines 
serialized data or Element metadata about a file.

In any case, the addition of serialized Examples to the model is very helpful; 
examples are unambiguously serialized data  The simplest way to serialize 
Elements is without any optimization, just a list of independent elements 
without regard to their types or relationships.

A Minimal Example would be a list of zero elements: [ ]
A Minimal useful example would be a list of one element: [ {element1} ]
A larger example would be a list of multiple serialized elements [ {element1}, 
{element2}, {element3} ]

So the minimum useful example would have a list of one element with type 
Person, not Document.  Unoptimized, it would be:

[

  {

"type": "Person",

"id": "urn:spdx.dev:iamwillbar",

"specVersion": "3.0",
"created": "2022-05-02T20:28:00.000Z",

"profile": ["core"],

"dataLicense": "CC0-1.0",

"createdBy": "urn:spdx.dev:iamwillbar"

  }

]

 

An unoptimized example with five elements would be a list of five objects, each 
with the same seven required properties.  Any optimizations applied to the 
serialized data, such as factoring out common element properties and id 
namespace prefixes, makes the transfer unit smaller but does not change the 
elements contained in the transfer unit or the values of those elements.

{
  "namespaces": {"": "urn:spdx.dev 

 :"}, 
  "defaults": {
"specVersion": "3.0",
"created": "2022-05-02T20:28:00.000Z",
"profile": ["core"],
"dataLicense": "CC0-1.0",
"createdBy": "iamwillbar"
  },
  "elements": [

{

  "type": "Person",

  "id": "iamwillbar",

}

  ]

}


This example optimized transfer unit is structured so that additional elements 
can be added efficiently.  But it is NOT an element itself; it is the 
serialized data of a collection, not metadata about a collection.  It does not 
have a type in JSON because JSON does not have types ("type" is 

Re: [spdx-tech] SPDX 3.0 draft spec?

[Gary O'Neall]

Hi Rose,

 

No - that version of the SPDX spec has not been updated.

 

The most up to date version 3 information is the model in the tech team
minutes  . 

 

We have a separate repo SPDX-3-Model 
which looks like it is also in need of an update.  It is, however, much more
current than the SPDX spec 3.0 github pages.  Perhaps we should remove the
SPDX 3.0 Github pages or refer them to a more current version.

 

Maybe a good topic for today's tech team call.

 

Regards,

Gary

 

 

 

From: Spdx-tech@lists.spdx.org  On Behalf Of Rose
Judge
Sent: Monday, May 2, 2022 12:22 PM
To: Spdx-tech@lists.spdx.org
Subject: [spdx-tech] SPDX 3.0 draft spec?

 

Hello SPDX,

 

Is the spec page for 3.0 up to date here
 ? I have a colleague trying to
prepare for adding SPDX 3.0 support and from what I can tell the 3.0 draft
spec page is mostly identical to 2.2  .

 

They've also looked at the current 3.0 vulnerability PR
  and an older 3.0
vulnerability profile SBOM from snyk
  and it
doesn't seem to line up with the 3.0 draft spec.

 

Does anyone have any more info about this or know where I could find a more
up to date 3.0 draft spec?

 

Thank you!

-Rose





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4486): https://lists.spdx.org/g/Spdx-tech/message/4486
Mute This Topic: https://lists.spdx.org/mt/90843684/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Base Model Diagram

[Steve Winslow]

Hi William, thanks for this and for all the work here. I've stared at this
for a bit and I don't have any particular comments offhand. All looks good
as far as I'm concerned.

One question I did have: I note the "FromFile" association between Package
and File. Are you thinking that this would replace the existing
PackageFileName property -- so that instead of giving just a file name, it
would be represented by an SPDX identifier for the actual File? That makes
sense to me, just wondering if that was your intent here.

Thanks!
Steve

On Wed, Jul 22, 2020 at 8:24 PM William Bartholomew 
wrote:

> As promised here is a diagram of the current SPDX 3.0 Base design. Couple
> of things to note:
>
> 1. This is a logical not physical diagram, when this is serialized in
> different formats (Tag, RDF, YAML, JSON, etc.) the property names may be
> different.
>
> 2. There are two types of arrows, ones with an empty head are inheritance
> so the class at the tail end inherits all the properties of the class at
> the arrow end, ones with a filled head are associations so these would be a
> property on the class at the tail end.
>
> We can discuss in more detail at the next tech team meeting but feel free
> to send feedback on or off list prior to then.
>
> Thanks,
>
> William Bartholomew
>
> 
>
>

-- 
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swins...@linuxfoundation.org

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3897): https://lists.spdx.org/g/Spdx-tech/message/3897
Mute This Topic: https://lists.spdx.org/mt/75737274/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[Gary O'Neall]

Hi Dave,

 

Echoing William’s response, we are working towards having consistent names 
across the different formats.  I’m actively working on tooling to support the 
different representation, so I’m (sometime painfully) aware of the 
inconsistencies.

 

The 2.2 work is constrained to be backwards compatible, so we may not be able 
to resolve all of the inconsistencies but we are making some progress.

 

Here’s some additional detail:

 

Issue related to the upper/lower case: 
https://github.com/spdx/spdx-spec/issues/95 

Issue for the different specVersion/spdxVersion property names: 
https://github.com/spdx/spdx-spec/issues/143

 

Gary

 

From: Spdx-tech@lists.spdx.org  On Behalf Of William 
Bartholomew
Sent: Tuesday, January 28, 2020 3:38 PM
To: David Kemp 
Cc: Spdx-tech@lists.spdx.org
Subject: Re: [spdx-tech] SPDX 3.0 Specification Structure

 

Hi Dave,

 

Yes, there is an effort to resolve as many format consistency issues as 
possible and some of this has already be done in 2.2. Not all of those changes 
have been applied to the 3.0 branch yet. Over the next week I plan to get those 
changes ported over and it would be great to review for consistency at that 
point.

 

William Bartholomew





On Jan 28, 2020, at 3:28 PM, David Kemp mailto:dk1...@gmail.com> > wrote:



Would it be possible to use consistent names for each data format?   
Maintaining a dictionary mapping different names for the same data item makes 
it unnecessarily difficult to translate from one format to another.

For example, in section 2.1.3 Document Metadata:

YAML  spdxVersion: SPDX-3.0
JSON "spdxVersion": "SPDX-3.0"
XML  SPDX-3.0
Tag/Value SPDXVersion: SPDX-3.0
RDF  SPDX-3.0

what is the reason for choosing different capitalization for Tag/Value than in 
JSON/YAML?  And is there a reason for picking a different name entirely 
(specVersion) for RDF?

It should be simpler to define a single name/key for each data item in all SPDX 
profiles, with a consistent rule that specifies how to represent keys in each 
data format?  In other words, each profile would define an abstract SPDX 
information model, and encoding rules convert any SPDX instance into a data 
document in a particular format.

The success criteria for such an approach include reducing the complexity of 
writing, validating, using, and comparing for equality a single SPDX instance 
in all supported formats.


Dave Kemp







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3826): https://lists.spdx.org/g/Spdx-tech/message/3826
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[William Bartholomew]

Hi Dave,

Yes, there is an effort to resolve as many format consistency issues as 
possible and some of this has already be done in 2.2. Not all of those changes 
have been applied to the 3.0 branch yet. Over the next week I plan to get those 
changes ported over and it would be great to review for consistency at that 
point.

William Bartholomew
> On Jan 28, 2020, at 3:28 PM, David Kemp  wrote:
> 
> 
> Would it be possible to use consistent names for each data format?   
> Maintaining a dictionary mapping different names for the same data item makes 
> it unnecessarily difficult to translate from one format to another.
> 
> For example, in section 2.1.3 Document Metadata:
> 
> YAML  spdxVersion: SPDX-3.0
> JSON "spdxVersion": "SPDX-3.0"
> XML  SPDX-3.0
> Tag/Value SPDXVersion: SPDX-3.0
> RDF  SPDX-3.0
> 
> what is the reason for choosing different capitalization for Tag/Value than 
> in JSON/YAML?  And is there a reason for picking a different name entirely 
> (specVersion) for RDF?
> 
> It should be simpler to define a single name/key for each data item in all 
> SPDX profiles, with a consistent rule that specifies how to represent keys in 
> each data format?  In other words, each profile would define an abstract SPDX 
> information model, and encoding rules convert any SPDX instance into a data 
> document in a particular format.
> 
> The success criteria for such an approach include reducing the complexity of 
> writing, validating, using, and comparing for equality a single SPDX instance 
> in all supported formats.
> 
> Dave Kemp
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3825): https://lists.spdx.org/g/Spdx-tech/message/3825
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[David Kemp]

Would it be possible to use consistent names for each data format?
 Maintaining a dictionary mapping different names for the same data item
makes it unnecessarily difficult to translate from one format to another.

For example, in section 2.1.3 Document Metadata:

YAML  spdxVersion: SPDX-3.0
JSON "spdxVersion": "SPDX-3.0"
XML  SPDX-3.0
Tag/Value SPDXVersion: SPDX-3.0
RDF  SPDX-3.0

what is the reason for choosing different capitalization for Tag/Value than
in JSON/YAML?  And is there a reason for picking a different name entirely
(specVersion) for RDF?

It should be simpler to define a single name/key for each data item in all
SPDX profiles, with a consistent rule that specifies how to represent keys
in each data format?  In other words, each profile would define an abstract
SPDX information model, and encoding rules convert any SPDX instance into a
data document in a particular format.

The success criteria for such an approach include reducing the complexity
of writing, validating, using, and comparing for equality a single SPDX
instance in all supported formats.

Dave Kemp

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3824): https://lists.spdx.org/g/Spdx-tech/message/3824
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[William Bartholomew]

Thanks for the feedback. Yes I agree numbering should be applied to all 
levels, I'll probably save that until later so we're not having to 
constantly update it as we iterate on the specification. Or, more 
likely, I'll write a tool to add or update the numbering :).


On 1/22/20 2:27 PM, Steve Winslow wrote:
+1 -- I like the look and formatting of this, I think it lays things 
out very cleanly. Thanks William!


Minor comment, looking at the Base Profile example: I expect it'll be 
useful to ensure that each of the metadata elements (e.g. SPDX 
Version, etc.) has its own outline sub-number, for ease of reference.


On Wed, Jan 22, 2020 at 3:15 PM Kate Stewart 
mailto:kstew...@linuxfoundation.org>> 
wrote:


Hi William,
    Like the way you're structuring the section and the look of
it.  :-)

Kate

On Wed, Jan 22, 2020 at 12:10 PM William Bartholomew
mailto:iamwill...@github.com>> wrote:

Ignore the content, a lot of it needs to be updated based on
the text in
2.2 and ongoing 3.0 discussions but this is an example of how the
specification could be restructured based on profiles:

https://iamwillbar.github.io/spdx-spec/2-base-profile/

>

https://iamwillbar.github.io/spdx-spec/3-licensing-profile/

>


Please let me know if you have any feedback, good or bad :)

William Bartholomew









--
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swins...@linuxfoundation.org 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3822): https://lists.spdx.org/g/Spdx-tech/message/3822
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[Steve Winslow]

+1 -- I like the look and formatting of this, I think it lays things out
very cleanly. Thanks William!

Minor comment, looking at the Base Profile example: I expect it'll be
useful to ensure that each of the metadata elements (e.g. SPDX Version,
etc.) has its own outline sub-number, for ease of reference.

On Wed, Jan 22, 2020 at 3:15 PM Kate Stewart 
wrote:

> Hi William,
> Like the way you're structuring the section and the look of it.  :-)
>
> Kate
>
> On Wed, Jan 22, 2020 at 12:10 PM William Bartholomew <
> iamwill...@github.com> wrote:
>
>> Ignore the content, a lot of it needs to be updated based on the text in
>> 2.2 and ongoing 3.0 discussions but this is an example of how the
>> specification could be restructured based on profiles:
>>
>> https://iamwillbar.github.io/spdx-spec/2-base-profile/
>> 
>>
>> https://iamwillbar.github.io/spdx-spec/3-licensing-profile/
>> 
>>
>>
>> Please let me know if you have any feedback, good or bad :)
>>
>> William Bartholomew
>>
>>
>>
>>
>> 
>
>

-- 
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swins...@linuxfoundation.org

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3821): https://lists.spdx.org/g/Spdx-tech/message/3821
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[Kate Stewart]

Hi William,
Like the way you're structuring the section and the look of it.  :-)

Kate

On Wed, Jan 22, 2020 at 12:10 PM William Bartholomew 
wrote:

> Ignore the content, a lot of it needs to be updated based on the text in
> 2.2 and ongoing 3.0 discussions but this is an example of how the
> specification could be restructured based on profiles:
>
> https://iamwillbar.github.io/spdx-spec/2-base-profile/
> 
>
> https://iamwillbar.github.io/spdx-spec/3-licensing-profile/
> 
>
>
> Please let me know if you have any feedback, good or bad :)
>
> William Bartholomew
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3820): https://lists.spdx.org/g/Spdx-tech/message/3820
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[Kate Stewart]

On Wed, Jan 22, 2020 at 1:49 PM Jeremiah C. Foster 
wrote:

> On Wed, 2020-01-22 at 12:10 -0600, William Bartholomew wrote:
> > Ignore the content, a lot of it needs to be updated based on the text
> > in
> > 2.2 and ongoing 3.0 discussions but this is an example of how the
> > specification could be restructured based on profiles:
> >
> > https://iamwillbar.github.io/spdx-spec/2-base-profile/
> > 
> >
> > https://iamwillbar.github.io/spdx-spec/3-licensing-profile/
> > 
> >
> >
> > Please let me know if you have any feedback, good or bad :)
>
> YAML? JSON? Yay! \0/
>

Both will be supported in 2.2,   debugging/refining in progress.

:-)   kate

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3819): https://lists.spdx.org/g/Spdx-tech/message/3819
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [spdx-tech] SPDX 3.0 Specification Structure

[Jeremiah C. Foster]

On Wed, 2020-01-22 at 12:10 -0600, William Bartholomew wrote:
> Ignore the content, a lot of it needs to be updated based on the text
> in
> 2.2 and ongoing 3.0 discussions but this is an example of how the
> specification could be restructured based on profiles:
>
> https://iamwillbar.github.io/spdx-spec/2-base-profile/
> 
>
> https://iamwillbar.github.io/spdx-spec/3-licensing-profile/
> 
>
>
> Please let me know if you have any feedback, good or bad :)

YAML? JSON? Yay! \0/

Jeremiah



This e-mail and any attachment(s) are intended only for the recipient(s) named 
above and others who have been specifically authorized to receive them. They 
may contain confidential information. If you are not the intended recipient, 
please do not read this email or its attachment(s). Furthermore, you are hereby 
notified that any dissemination, distribution or copying of this e-mail and any 
attachment(s) is strictly prohibited. If you have received this e-mail in 
error, please immediately notify the sender by replying to this e-mail and then 
delete this e-mail and any attachment(s) or copies thereof from your system. 
Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3818): https://lists.spdx.org/g/Spdx-tech/message/3818
Mute This Topic: https://lists.spdx.org/mt/69985465/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-