Jack, Yes, I think it is worth to consider public accessibility of spdxdocs.
A component web service might help to search and provide meta data of a component such as spdxdocs uuids, versions, etc. e.g. http://spdx.org/components/ or provide http://spdx.org/spdxdocs/ as a human entrypoint to find or browse meta data and a dedicated machine interface via specific URL such as this: http://spdx.org/spdxdocs/id/ Whenever multiple SPDX docs from different vendors are available for the same package UUID, the web service can provide proper info to the client with a list of available SPDX docs. A SPDX consumer might then query this pattern: http://spdx.org/spdxdocs/id/[uuidv5 source package]_[UUIDv5 vendor domain] UUID v5 (SHA-1 hash) could be an option to store the SHA-1 checksum of a source package => would be very ease to use: create a UUIDv5 of source.tar.gz and get a spdxdoc ... Not part of the standard yet. or use a Download-URL which is defined by rfc4122, e.g. http://www.apache.org/dyn/closer.cgi?path=/thrift/0.9.1/thrift-0.9.1.tar.gz => e6e79469-4e7e-5bdc-8a03-b6b65fa0f609 http://spdx.org/spdxdocs/id/e6e79469-4e7e-5bdc-8a03-b6b65fa0f609 or use domain names which is also a standard option within rfc4122 UUID v3 (Random) can be used as a fallback for any other case Just some ideas, all the best! -roger PS: A Universally Unique IDentifier (UUID) URN Namespace http://tools.ietf.org/html/rfc4122 https://servicecore.info/tools/uuid-generator/ > -----Original Message----- > From: [email protected] [mailto:spdx-tech- > [email protected]] On Behalf Of Manbeck, Jack > Sent: Freitag, 4. April 2014 20:57 > To: Gary O'Neall; 'Bill Schineller'; 'Nuno Brito' > Cc: [email protected] > Subject: RE: proposed language for referencing element in one SPDX document > from another > > Another alternative is to just use a guid by itself as a URI - e.g.: > urn:uuid:3F2504E0-4F89-41D3-9A0C-0305E82C3301. Less readable, but unique. > > Agreed. I like the idea of having a human readable portion re > http://spdx.org/spdxdocs/3F2504E0-4F89-41D3-9A0C-0305E82C3301-spdx-tools-v1.2 > > I'm also wondering if we should switch and have the human readable portion > first, e.g. > http://spdx.org/spdxdocs/spdx-tools-v1.2-3F2504E0-4F89-41D3-9A0C-0305E82C3301 > > Note: spdx.org spdxdocs will not be accessible on the website. > Hmmm.. What if it were? I suppose there are lots of potential issues on that > but would it be interesting enough to consider? > > Jack > > -----Original Message----- > From: Gary O'Neall [mailto:[email protected]] > Sent: Friday, April 04, 2014 2:38 PM > To: 'Bill Schineller'; Manbeck, Jack; 'Nuno Brito' > Cc: [email protected] > Subject: RE: proposed language for referencing element in one SPDX document > from another > > Thanks Bill for pulling this together. > > Should we prescribe how the unique identifiers are built in the RDF document > to make it easier to translate between tag/value and RDF? > > If so, I added some proposed language inline below. > > There may also be a case where someone is producing an SPDX doc and they are > not part of an organization which has a unique namespace. I'm not sure if > this would really be an issue, but we could come up with a naming scheme for > that situation using spdx.org domain. For example: > > If the producing person is not part of an organization which has a unique > basename, the following basename can be use: > http://spdx.org/spdxdocs/[guid]-[packageVersionid] > where packageVersionid is a human readable name that describes the content of > the SPDX document and guid is a generated version 4 globally unique ID. > A new GUID would be generated for each document. Example: > http://spdx.org/spdxdocs/3F2504E0-4F89-41D3-9A0C-0305E82C3301-spdx-tools-v1. > 2 > Note: spdx.org spdx docs will not be accessible on the website. > > Another alternative is to just use a guid by itself as a URI - e.g.: > urn:uuid:3F2504E0-4F89-41D3-9A0C-0305E82C3301. Less readable, but unique. > > Gary > > > -----Original Message----- > > From: [email protected] [mailto:spdx-tech- > > [email protected]] On Behalf Of Bill Schineller > > Sent: Thursday, April 3, 2014 7:03 AM > > To: Manbeck, Jack; Nuno Brito > > Cc: [email protected] > > Subject: RE: proposed language for referencing element in one SPDX > > document from another > > > > Hi Nuno, Jack, all - > > > > I agree with Jack. How does the extra Note I added below sound? > > - Bill > > > > > > Producers of SPDX data are expected to 'own' a namespace for their > > organization. (e.g. 'http://acme.com/spdx') > > > > When releasing an SPDX document for external consumption, its basename > > must be unique within the namespace of the producing organization. > > (e.g. http://acme.com/spdx/mypackage-1-2.spdx where the organization > > will not distribute another modified file with same basename > > 'mypackage-1-2.spdx' ) > > > > [Note: Establishing a 'namespace of the producing organization' does > > not necessarily imply/require that SPDX documents get posted publicly > > on the internet. An organization could confidentially share SPDX > > documents it produces with partners. Regardless, the producing > > organization should uniquely identify itself as with a namespace it > > 'owns' (e.g. "http://acme.com/spdx";). > > SPDX documents it distributes (whether over the internet or in a > > folder of some archive/container transmitted privately) should have > > unique basenames within the namespace / realm of every SPDX document > > the producing organization has ever distributed. Inside each > > distributed SPDX document, the namespace of the producing organization > > will be part of the unique id of the 'SPDXDocument' element (e.g. the > > leading part of 'http://acme.com/spdx/mypackage-1-2.spdx'). The > > consumer of the SPDX document shouldn't expect that the document will > > be available at a publicly accessible URL > > 'http://acme.com/spdx/mypackage-1-2.spdx', and in the case that it is > > not, the consumer should keep a copy of the SPDX document it received > locally at a sensibly named location (e.g. > > '/myspdxcache/spdx/com/acme/mypackage-1-2.spdx). The SPDX spec does > > not prescribe how consumed SPDX docs are handled locally, so consumers > > should take care to keep docs they received in a location they can be > > found internally. > > ] > > > > > > [Note: if the organization subsequently releases an update to their > > SPDX analysis for same package, the updated document must carry a new, > > unique basename, e.g. 'mypackage-1-2-rev1.spdx'] > > > > [Note: best practice is to use the .spdx suffix on all SPDX documents, > > regardless of tag-value or RDF format] > > > > Additionally, an accompanying file with the SHA-1 hash of the file > > should sit alongside it, named the same, plus the extension .sha1 > > (e.g. 'http://acme.com/spdx/mypackage-1-2.spdx.sha1' The contents of > > the .sha1 file is a single line with the sha1 of the published .spdx > > file.) > > > > Within the SPDX document, each SPDXElement (including subclasses) > > shall be assigned a unique id (unique within the scope of the > > document.) > > For tag-value format, each field shall have an SPDXRef-[idString] with a > unique identifier for each element. > In RDF format, the unique id is the resource URI identified formed by the SPDX > document URI concatenated with #SPDXRef-[idSTring]. > > > [Note: for tag-value format, this means populating the field SPDXRef- > > [idString] with a unique identifier for each element. In RDF format, > > the unique id is the resource URI identifier.] > > > > > > > > > > ________________________________________ > > From: Manbeck, Jack [[email protected]] > > Sent: Thursday, April 03, 2014 9:13 AM > > To: Nuno Brito; Bill Schineller > > Cc: [email protected] > > Subject: RE: proposed language for referencing element in one SPDX > > document from another > > > > Hi Nuno, > > > > As far as I understand it using a company web address does not > > necessarily mean the document is available over the Internet. It's > > just a way to provide uniqueness. We are also looking at providing a > > default name space at spdx.org but that would require use of a UID in > > case someone did not have domain name. > > > > Jack > > > > > > -----Original Message----- > > From: [email protected] [mailto:spdx-tech- > > [email protected]] On Behalf Of Nuno Brito > > Sent: Thursday, April 03, 2014 8:18 AM > > To: Bill Schineller > > Cc: [email protected] > > Subject: Re: proposed language for referencing element in one SPDX > > document from another > > > > Hi Bill, > > > > The proposed approach is useful. I will try it out in practice. > > > > Just have one question in regards to: > > > When releasing an SPDX document for external consumption, its > > basename > > > must be unique within the namespace of the producing organization. > > > (e.g. http://acme.com/spdx/mypackage-1-2.spdx where the > > > organization will not publish another file with basename > > > 'mypackage-1-2.spdx' ) > > > > I have cases where the document is included on the distribution > > package but where the owners are not willing to make it available to > > public (just privately to selected companies). > > > > Meaning, a network location isn't possible as namespace. I'm currently > > referring to other SPDX documents within the folder structure as > > solution. > > > > To keep the URI scheme possible and reference documents within the > > folders, would something like this be possible? > > > > file:///./spdx/mypackage-1-2.spdx > > > > Or perhaps I misunderstood the intention of namespaces. My thanks in > > advance. > > > > > > With kind regards, > > Nuno Brito > > > > --- > > email: [email protected] > > phone: +49 615 146 03187 > > > > _______________________________________________ > > Spdx-tech mailing list > > [email protected] > > https://lists.spdx.org/mailman/listinfo/spdx-tech > > _______________________________________________ > > Spdx-tech mailing list > > [email protected] > > https://lists.spdx.org/mailman/listinfo/spdx-tech > > _______________________________________________ > Spdx-tech mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-tech _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
