Gary> Hi Daniel,
Gary> After thinking about this, I tend to agree that it is more
straightforward
Gary> to use the beginOptional and endOptional tags. This would allow for more
Gary> straightforward embedding of variable rules within optional text. To
Gary> simplify the parsing, I would like to restrict the level and type of
Gary> nesting. Proposal:
Yes, and it also makes it simpler to add big sections of optinal text
(like the appendices/addenda/etc).
Gary> - Optional text can embed variable rules
agreed.
Gary> - variable rules cannot embed optional text
So then we don't need the type=required|optional tag in a variable rule,
now we can just wrap it in an beginOptional/endOptional.
Gary> - variable rules cannot embed other variable rules
I totally agree.
Gary> One modification to the rules and optional tag syntax - on one of the
calls
Gary> we discussed changing the special characters to '<<' and '>>' from '{{'
and
Gary> '}}' since we are not technically using the Mustache syntax. If it is OK
Gary> with you, let's change to the << >> special characters.
I agree too. Let us use << >> instead of {{ }}
One more suggestion, now we have:
- rules (to match variable sections
- beginOptional/endOptional
I feel it would be good to make sure the first token of a <<...>> is the
type of rule. I suggest this:
<<beginOptional;name=uniqueNameInLicense>>
<<endOptional>>
<<var;name=uniqueNameInLicense;...
so the first token is a type of rule. The second is the name
(endOptional does not nened one), and the rest is as required... for
example, this is the bsd2:
<<beginOptional;name=copyrightSection>>
Copyright (c) <<var;name=copyright;original= <year>
<owner>;match=.+;example=John Doe>>
All rights reserved.
<<endOptional>
Gary> All - let us know if you disagree with the proposed syntax changes for
Gary> optional text. Since we would like to implement this by LinuxConn, we'll
Gary> need feedback by end of day Monday.
Gary> Thanks,
Gary> Gary
Gary> -----Original Message-----
Gary> From: .dmg [mailto:[email protected]] On Behalf Of D M German
Gary> Sent: Friday, September 06, 2013 5:40 PM
Gary> To: [email protected]; [email protected]
Gary> Cc: [email protected]; [email protected]
Gary> Subject: optional sections in license
Gary> Hi Gary, Jilayne, rest of the SPDX technical and legal teams.
Gary> I have been thinking about the optional sections of licenses. I think it
is
Gary> not worth it to create a template rule to match optional sections of
known
Gary> text
Gary> Template rules were supposed to be intended for sections that are
expected
Gary> to vary, not simply sections that can be omitted. I just feel it
Gary> over-complicates things.
Gary> What do you think about specifying variable sections with some sort of
begin
Gary> and end marker, and indicate that they optional sections of a template
Gary> cannot be embedded into another one (to avoid recursion).
Gary> For example, something like this (the name will uniquely identify the
Gary> section).
Gary> {{beginOptional;name=anyUniqueName}}
Gary> Text that is optional, including some template rules (for variable
sections
Gary> in the optional text)
Gary> {{endOptional}
Gary> For example, the BSD-2 is currently specified as follows:
Gary> {{original=Copyright (c) <year> <owner>\nAll rights
Gary> reserved.;match=Copyright \(c\) .+All rights
Gary> reserved.;name=copyrigh;type=optional;example=Copyright (C) 2013 John
Gary> Doe\nAll rights reserved.}}
Gary> but I think it makes more sense to specify it like this:
Gary> {{beginOptional;name=copyrightStatement}}
Gary> Copyright (c) {{original=<year>
Gary> <owner>.;match=.+;name=copyright;type=optional;example=2013 John Doe}}
All
Gary> rights reserved.
Gary> {{endOptional}
Gary> what do you think?
Gary> --dmg
Gary> --
Gary> Daniel M. German "I see no good reason why the
views given in this volume
should shock the religious
Charles Darwin -> feelings of anyone."
Gary> http://turingmachine.org/
Gary> http://silvernegative.com/
Gary> dmg (at) uvic (dot) ca
Gary> replace (at) with @ and (dot) with .
--
Daniel M. German "El pasado es una engañosa utopía
y nada fue tan grato o tan terrible
Germán Dehesa -> como lo recordamos en el presente."
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
