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: [email protected] <[email protected]> On Behalf Of William 
Bartholomew
Sent: Tuesday, January 28, 2020 3:38 PM
To: David Kemp <[email protected]>
Cc: [email protected]
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 <[email protected] 
<mailto:[email protected]> > 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:version>SPDX-3.0</spdx:version>
Tag/Value SPDXVersion: SPDX-3.0
RDF      <specVersion>SPDX-3.0</specVersion>

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: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to