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-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal
>
>
_______________________________________________
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Reply via email to