Your assumption on the crossRefs being an industry standard is correct. It
originates in a W3C RDF vocabulary. Where feasible, we try to use the same
terms as W3C to make it easy for people and tools to interpret the terms we
come up with.
I agree with your proposal on the SPDX element proposal of SPDXLicenseDocument.
It raises a really good point as to the scope of the XML document. I makes
sense to me to allow these document to represent licenses other than listed
licenses. There are a few issues we would need to tackle, however. The
license ID’s would need to be unique. We could use some kind of namespace to
represent the listed licenses and allow for uniquely identifiable other
licenses. We’ve solved this with the SPDX documents, so perhaps we could use a
similar solution. We could add an element “LicenseNamespace” which would be a
URI. For the listed licenses, it could simply be “spdx.org/licenses”. What do
others on the tech team think? We could add it to the topics for our next
meeting Tuesday at 10 Pacific if there is time after our discussion of the
I don’t have a strong opinion on the other items, but I would be happy to
facilitate any discussions to close on them in an upcoming tech call or a joint
From: Brad Edmondson [mailto:brad.edmond...@gmail.com]
Sent: Wednesday, October 12, 2016 11:13 AM
To: Gary O'Neall
Cc: spdx-t...@lists.spdx.org; SPDX Legal
Subject: Re: First pass of License XML terms completed by Tech Team
I've gone through the linked document and made some comments, though I would
ask the Tech Team to bear in mind I have some programming experience but none
in the task of defining specs. With that said, these are my abbreviated
SPDX element: I agree this should be changed as it's too vague, but I think I
would prefer "SDPXLicense" for a single license and "SPDXLicenseDocument" (or
something similar, maybe "SPDXLicenseCollection") representing a collection of
SDPXLicense elements. I think "ListedLicense" is too tied to the current
problem, and would be awkward for tools operating on single licenses later on.
CrossRefs: No objection or really any comment per se. It might just help to
confirm that (as I assume) this comes from some other spec the Tech Team is
familiar with, or is industry-standard and we/I just don't know it.
Avoiding collision with HTML: Much appreciated; this was super confusing (to
me, at least) starting out on the XML conversion project.
<b> or <bullet>: This does have a matching purpose and so should probably be
kept (as the Tech Team concluded)
<paragraph>: I'm sensitive to the goal of avoiding the collision with HTML, but
this seems a bit cumbersome, and like it could affect the human-readability of
the XML. If you look at the GH repo there are <p> tags all over the place. Do
we need to have so many <p> tags, or is there some other way we can keep the
files somewhat readable?
alt/name/match: I'm relatively new to SPDX, so I can't say I even begin to
understand the difference among these three elements. But if we need them and
tech is happy with leaving them as-is, I'm happy even in my ignorance. :-)
<br> / newline: I have been removing these from the XML licenses I inspect in
the GH repo, and I would propose removing it from the spec (replacing them with
<p> or <paragraph> tags where they appear).
Should we add <header> or <sectionTitle> element? I'm wondering if we should
have something to denote section headers/titles analogous to <h1>, <h2>, etc.
in HTML. Note that I have been wrapping these in <p> tags as we import licenses
in XML, e.g. here
Gary and the rest of the Tech Team, thanks for all your good work, and I look
forward to keeping up the momentum on this project, both on the spec side and
on the XML-import side.
Brad Edmondson, Esq.
512-673-8782 | brad.edmond...@gmail.com
On Tue, Oct 11, 2016 at 2:27 PM, <g...@sourceauditor.com> wrote:
Greetings tech and legal teams,
In the technical workgroup, we just completed a first pass review of all of the
terms and attributes proposed by Kris and the legal team.
The details can be found in the google doc:
The comments column represents the discussion in the tech team and includes any
proposed changes. I added a column to include the proposed new name for the
element or attribute.
A couple of discussions I would like to highlight for the legal team.
We are proposing changing the names for many of the formatting element names.
We decided that some of the formatting tags have semantics – such as ignoring
bullets. These should be included in the RDF form of the license. Some of the
formatting tags are strictly formatting – such as br. These will not be
included in the RDF, but will be used to generate the HTML.
We also felt that we should use terms more human readable and different from
the HTML tags – e.g. newline instead of br. There were two reasons:
· more human readable for those not familiar with HTML
· they do represent 2 different problem spaces and should use distinct
We also spent some time discussing the syn element. We all agreed that we
should include a dictionary in XML form that would contain all of the synonyms
documented in the license matching guidelines. We has some concerns on
including a syn element in the license XML files themselves. In particular, we
were concerned that new synonyms could be introduced in the license text that
would be different from the matching guidelines. We concluded that we may want
to push this to a release 2 since it requires more discussion.
Please let us know if there is any concerns about the proposed terms and
Source Auditor Inc.
Spdx-legal mailing list
Spdx-legal mailing list