As long as there is a build process we can name them whatever we want; I was referring more to the structure of them (for example, in my initial proposal the 'bullet' tag was just an empty element, not retaining the initial value... but now I'm suggesting we instead retain the initial text. Same for the 'synonym' tag). Do you have specific items on your hit list? Any proposal about what to do with tags that may not exist in the spec?
Re: extra columns, sure. I can go through and extend the current data as appropriate, will try and work in some time to do that. Kris From: Gary O'Neall [mailto:[email protected]] Sent: Tuesday, March 01, 2016 12:47 To: Kris.re <[email protected]>; [email protected]; 'SPDX-legal' <[email protected]> Subject: RE: Updated templates Thanks Kris! Good progress on the formats and licenses (as well as some interesting findings on the existing license texts). Just a couple comments related to format. Input format: In order to do away with the spreadsheet, we'll need a few more tags to represent all of the columns (e.g. OSI approved, other web pages for the license, notes). Output format: I would propose the property names in the output format to be consistent with the spec for consistency. If we want the output XML format to be consistent with the input format, we may want to change the names of the properties on the input format to make the entire set of formats use consistent terms. Gary From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kris.re Sent: Monday, February 29, 2016 4:43 PM To: [email protected]<mailto:[email protected]>; 'SPDX-legal' Subject: Updated templates Hello folks. The results of my second pass at converting the license list can be found here: https://github.com/myndzi/license-list/tree/xml-test/src Notably, I was a lot more aggressive with what qualifies as optional text. The substantive body text of the licenses is no longer wrapped in any markup; instead, the entire license body is wrapped in the <body> tag, and the optional sections are nested inside. Optional sections should be taken to mean optional *for the purpose of matching*; they may contain text that is not optional for the purpose of actually utilizing the license. This was hard to decide on in a few cases with preamble sections, for example, and is probably not consistent in its treatment through every license. I ran into a few strange cases and marked many of them with the 'review' comment tag at the top of the file as before. I also noticed a few license templates that actually include multiple licenses concatenated together; I am uncertain how these should be dealt with, particularly with regards to copyright notices in the "second" license and so forth. In one case (open ssl, including the ssleay license text in whole) this may have been a requirement of the license for the library the software was based on, but at least one other case (I'm sorry: I don't remember specifically which one) it seemed more like things were just thrown together. I noticed that the PHP license includes a reference to the Zend framework, though there is a separate Zend license. There are a few times where the license text proper has been interrupted by an optional tag; that is to say, the meaningful text is not all one piece in every license. For the purposes of matching, this may be difficult to resolve - if you say that optional tags may be matched in an "all or nothing" manner, you will fail to match in cases where the interleaved "optional" text is in the form of a copyright notice which has been changed; marking these out as alt text may be the correct solution. I also updated the wiki: http://wiki.spdx.org/view/Legal_Team/Templatizing/tags-matching I've outlined the general structure of the XML files here, as well as revised my original proposal to make the master and matching formats almost identical. I edited the matching guidelines to identify the ones that would change, though I imagine the text I included could do to be revised. Applicable sections are 7 through 12. Please have a look if you're interested and share feedback. Kris
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
