Re: format requirements inconsistency


Hi Armijn,
Thanks for working through the spec, and finding the typo. ;)
All updates and corrections much appreciated.

In terms of the requirements, as more technical folk have started participating, that has been a growing request. You're right, its possible to do both, but it is suboptimal in some cases. If we can get tools and the support infrastructure created in an open source project, to demonstrate we can relax the human readable form requirement, and accomplish the readability goal, we can revist this requirement. Key is getting some prototype tools in place. Do you have bandwidth to help out with the tool creation? ;) Gary O'Neal's pretty printer is a good step in this direction.

The RDF call that Bill S. is hosting is where this is getting actively discussed. So we don't spam the legal and business folk on the maillist, we're thinking of setting a separate spdx technical maillist up as well so we can discuss the specifics a bit more. When its set up, we'll announce, and anyone interested is welcome to subscribe and contribute to the tools development and format decisions.


--- On Wed, 9/15/10, Armijn Hemel <armijn@...> wrote:

From: Armijn Hemel <armijn@...>
Subject: format requirements inconsistency
To: "spdx@..." <spdx@...>
Date: Wednesday, September 15, 2010, 4:51 PM
hi all,

I read the specs and saw:

1.6. Format Requirements:
      1.6.1. Must be in a human readable
      1.6.2. Must be in a syntax that a
software tool can read and

In my experience these two are not mutually exclusive, but
they don't go
well together without making sacrifices to either one, or

Please drop one, preferably the human readable form, since
that one can
be derived from the machine readable format with some
templating engine
or stylesheets. Dropping it also makes automated checking
and comparing
of SPDX files a lot easier.

Also, 1.5.2 has a tpyo ('and' should be 'an')





Spdx mailing list

Join to automatically receive all group messages.