Thanks Bill for the reply.

Sorry - I sent out the wrong username - it's spdx@.... Give
that a try and let me know if you have any problems.

Gary

On Wed, 11 Aug 2010 15:12:29 -0400, Bill Schineller
<bschineller@...> wrote:

Thanks Gary - thrilled that you contributed our first tool.
Although I explicitly specified ssl/tls, port 21, and accepted
certificate, seems to be rejecting the password spdx1 for user spdx

re:"With respect to some of your earlier questions,
* License Names and Pretty Printing - I was only able to extract
the URL for the license (as a resource) from the SPDX document which
doesn't lead to a very pretty license name. Should we add a property
License Name? Should I parse the URL and only print out the tag (e.g.
after the #)?"

---> I'd like to go with parsing the URL and printing out the tag (after
the #).

We ought to have an RDF document on our site for each license, and the
License Name is a property of each license.

re: "Namespace and tags - I noticed in the example we have only one
namespace for SPDX and the tags used in the example did not match the

tags

in the specification in all cases - e.g. License in the file is tagged
FileLicense in the example. Do we want to have separate namespaces for
File, License, and Document? If not, do we want the tags to be unique
(e.g. FileLicense and PackageLicense)? Technically, the tags don't

need

to be unique, but it may aid in humans reading the RDF/XML file."

---> I think it's ok to adopt in the RDF the non-unique (shorter) tags

as

in the specification. On one of the calls, the vibe from the group was
for the shorter tags. (e.g. 'License', not 'FileLicense'). Unfortunately

I

never sent around a new example incorporating that feedback (by then the
zilb example was making the rounds). I think it is acceptable and

correct

to keep it in the same namespace.

- Bill

On 8/10/10 11:19 PM, "Gary O'Neall" <gary@...> wrote:

I uploaded the pretty printer java program to the source auditor ftp
server. It's a secure web server, so I apologize in advance if it's a

bit

inconvenient to download.

The ftp server is at ftp.sourceauditor.com <ftp://ftp.sourceauditor.com>

You need to use explicit tls/ssl over port 21. Logon with user spdx and
password spdx1

The file SPDXPretty.zip contains the files mentioned in the previous

email

(copied below).

Let me know if you need more information or if you have any problems.

Gary



From: package-facts-bounces@...
[mailto:package-facts-bounces@...] On Behalf Of Gary O'Neall
Sent: Sunday, August 08, 2010 11:32 PM
To: package-facts@...
Subject: Java Pretty Printer

I completed an "alpha" version of a Java based pretty printer. It's

10MB

in binary form with its dependencies. Is there a place on the Wiki I

can

upload this to? I tried to add it to a page as an attachment to a new
discussion page, but the .zip filetype was not allowed. Please advise

on

the best method to get this to the group.

Attached is a modified zlib example (see notes below on what items were
changed) and an example output.

Below is some information and discussion points related to the pretty
printer development:

I'm sure there are a few improvements to be made before calling this a
"release", but it does provide some formatting and works for the zlib
example. I would appreciate any feedback once you have access to the
application.

To run the application, make sure you have a JRE 1.6 installed (JRE
version 1.5 may work, but it untested). Unzip the files in your

favorite

directory. Execute the jar file with a single text parameter of a file
path for the SPDX RDF Document.

On windows, this would be "java -jar SPDXPretty.jar
examples\zlib-1.2.5.spdxv3.rdf (assuming you copied the attached example
file into the same directory as the .jar file and your cd'd to that
directory).

I made a few changes to the zlib example to bring it up to date to the
draft 20100731. It is in the zip file in the examples directory.

I run into a few questions/issues as I implemented this, outlined below:

* Namespace and tags - I noticed in the example we have only one
namespace for SPDX and the tags used in the example did not match the

tags

in the specification in all cases - e.g. License in the file is tagged
FileLicense in the example. Do we want to have separate namespaces for
File, License, and Document? If not, do we want the tags to be unique
(e.g. FileLicense and PackageLicense)? Technically, the tags don't

need

to be unique, but it may aid in humans reading the RDF/XML file.

* I changed the tags in the example to match the document in

cases

where they were still unique (e.g. ShortDescription -> ShortDesc)

* License Names and Pretty Printing - I was only able to extract
the URL for the license (as a resource) from the SPDX document which
doesn't lead to a very pretty license name. Should we add a property
License Name? Should I parse the URL and only print out the tag (e.g.
after the #)?

* Example use of hasFile - In the example, the object of the
hasFile predicate for the package subject all have the same URI. I

believe

these should be unique since they represent different file objects. I
changed the example to make these individual and unique.

* The disjunctive licenses are implemented but not tested.

* There has not been much testing (Unit or otherwise)


I would like to make the code available as an open source project. It

is

written using Jena (http://jena.sourceforge.net/) and contains a Java

class

which is a model basically wrapping a Jenna model of the RDF document.

It

would probably be useful for many of you who are writing tools.

I could post the code to SPDX, but I would rather maintain it in a
repository which supports svn. I'm thinking Google code may be a good
location. Open to suggestions.

As far a licenses, it's currently under a 3 clause BSD since it's GPL
compatible and simple. I'm open to other licenses, so let me know if

you

have a preference - we could even create a nice complex set of license
choices ;) Do keep in mind this is dependent on Jena which is licensed
under a 3 clause BSD and contains some Apache licensed code.

Appreciate any comments.

Best regards,

Gary O'Neall
Source Auditor Inc.







Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com