Thanks Brad!
Excellent comments. 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 bake-off results. 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 tech/legal call. Thanks, Gary From: Brad Edmondson [mailto:brad.edmond...@gmail.com] Sent: Wednesday, October 12, 2016 11:13 AM To: Gary O'Neall Cc: spdx-tech@lists.spdx.org; SPDX Legal Subject: Re: First pass of License XML terms completed by Tech Team Thanks Gary, 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 comments: 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 <https://github.com/spdx/license-list-XML/commit/78a582e9d08dc723be8e77a38e3d8c32afe5f39c> . 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. Best, Brad -- 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: https://docs.google.com/document/d/1z9n44xLH2MxT576KS_AbTOBtecyl5cw6RsrrQHibQtg/edit 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 terms 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 attributes. Thanks, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: g...@sourceauditor.com _______________________________________________ Spdx-legal mailing list spdx-le...@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
_______________________________________________ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
