After looking at the list from Nuno, as well as our discussions on this,
here's the revised proposal (leveraging the MIME types)
6.2.1 Purpose: This field provides information about the type of file
identified. This information can be determinative of license compliance
requirements. The options to populate this field are limited to:
(a) SOURCE if the file is human readable source code (.c, .html, etc.);
(b) BINARY if the file is a compiled object, target image or binary executable
(.o, .a, etc);
(c) ARCHIVE if the file represents an archive (.tar, .jar, etc.);
(d) APPLICATION if the file is associated with a specific application type
(MIME type of application/* ), which could include BINARY or ARCHIVE files;
(e) AUDIO if the file is associated with an audio file (MIME type of audio/* ,
ie. .mp3 );
(f) IMAGE if the file is assoicated with an picture image file (MIME type of
image/*, ie. .jpg, .gif );
(g) TEXT if the file is human readable text file (MIME type of text/*), which
could include SOURCE files.
(h) VIDEO if they file is associated with a video file type (MIME type of
video/*);
(i) OTHER if the file doesn't fit into the above categories (SPDXfiles,
generated artifacts, data files, etc.)
Since CRUFT is going to likely cause confusion, its been gouped back into the
OTHER category.
Does this seem a reasonable breakdown?
Kate
On Tuesday, June 3, 2014 1:54 PM, "[email protected]" <[email protected]>
wrote:
Based on discussions from today's calls (unless someone chimes up on the list
;-)) we'll go with the following updates for the File Type fields. (note: its
an optional field)
6.2.1 Purpose: This field provides information about the type of file
identified. This information can be determinative of license compliance
requirements. The options to populate this field are limited to:
(a) SOURCE if the file is human readable source code (.c, .html, etc.);
(b) BINARY if the file is a compiled object, target image or binary executable
(.o, .a, etc);
(c) ARCHIVE if the file represents an archive (.tar, .jar, etc.);
(d) CRUFT if the file is a generated artifact of the build or repository it was
stored in (.svn,
.git, etc)
(e) PICTURE if the file contains a potentially copyrightable picture or image
(.jpeg, .png, etc.) or
(f) OTHER if the file doesn't fit into the above categories (SPDXfiles, audio,
data files, etc.)
When comparing to the usage_types inRelationship and Usage Types Document it
was agreed that there could be
multiple mappings, and we wouldn't constrain the usage type to be checked
against the file types at this point.
We also reviewed the relationship types, so unless anyone else has a strong
opinion, those will be the ones we'll be
documenting in 2.0.
Anyone have specific concerns? Corrections/updates to the notes I took? :-)
Thanks, Kate
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
