Should we allow formatting in the alt and optional elements #393
Comments
|
On Fri, Feb 24, 2017 at 07:32:33PM -0800, goneall wrote:
I would assume we should disallow nested optional and alt elements
(e.g. "<optional> this is an <optional> really </optional> optional
text </optional>")
As I understand it, the purpose of <optional> is to allow a license to
match whether or not it contains the optional content. If there are
multiple flavors of the optional content, you'd need either nested
<optional> elements or a series of <optional> elements:
<optional>flavor A</optional>
<optional>flavor B</optional>
<optional>flavor</optional>
Personally I'd rather allow nesting:
<optional>flavor<optional> <alt name="flavor" match="A|B">A</alt></optional></optional>
because with longer optional/alternative text it allows us to avoid
repeating shared content.
|
|
@goneall I can say that we have a fair number of licenses with significant portions of text marked optional, so I'd think that we'd need to be able to include formatting tags within <optional> blocks to be able to display that in a readable way. I have no opinion on nesting <optional> or <alt> tags within each other. |
|
Agree on the nesting of the formatting. We'll need to update the schema for this. I'm thinking that we do not nest and - I haven't seen this in practice and it would really complicate the schema. @wking Your proposal is quite reasonable, however, we have already standardized on the current approach for the text files. I would like to keep the basic format between the template text and HTML structurally similar. If we were to change the structure of both, it would involve a revision of the spec. I would suggest we go with the current approach for now and consider alternative formats in future revisions of the spec. We would also want to take into account backwards compatibility since these formats have been encoded in license text outside of the XML. |
|
On Wed, Mar 22, 2017 at 10:35:30AM -0700, goneall wrote:
I would suggest we go with the current approach for now and consider
alternative formats in future revisions of the spec.
I was just trying to demonstrate where nesting alt/optional would be
useful, and not trying to propose an alternate format. I agree that
nesting alt/optional makes the schema and license definitions more
complicated, although as I tried to show in my example, sometimes that
increased complication can help avoid redundancy in the license
definition. However, allowing nesting alt/optional is a
backwards-compatible change, so we can always forbid nesting for now
and allow it later on if we change our minds.
We would also want to take into account backwards compatibility
since these formats have been encoded in license text outside of the
XML.
I don't see a backwards compatibility issue with *adding* nesting for
alt/optional. All existing licenses won't use nested alt/optional,
and they'll still be valid whether nesting alt/optional becomes legal
or not.
I'm not clear on the “these formats have been encoded in license text
outside of the XML” wrinkle. Are there non-XML formats where nesting
alt/optional wouldn't be possible? Either way, I guess we can address
this if/when we decide to pick nesting alt/optional back up.
|
|
I added nested formatting for the alt and optional fields in the schema and implemented support in the spdx-tools. |
By differentiating between formattedAltText..., which may contain <alt> and <optional>, and formattedFixedText..., which may not. The optionalType is using formattedAltTextGroup, because nesting variable content inside an optional element can be useful [1,2]. The <alt> element, on the other hand, specifies all the variable options in its match attribute, so there's no need for nesting variable elements inside the alt body. [1]: spdx#393 [2]: spdx#462
By differentiating between formattedAltText..., which may contain <alt> and <optional>, and formattedFixedText..., which may not. The optionalType is using formattedAltTextGroup, because nesting variable content inside an optional element can be useful [1,2]. The <alt> element, on the other hand, specifies all the variable options in its match attribute, so there's no need for nesting variable elements inside the alt body. Also require fixed text for <notes>, since those aren't templates. And drop the unused notesType, since they're vanilla formatted text. We almost certainly want to drop titleText and copyrightText fro the formatted*TextGroup choices, but I'm leaving that for [3]. [1]: spdx#393 [2]: spdx#462 [3]: spdx#452
Question: Should we allow paragraphs, bullets, lists inside the optional and alt elements? I would assume we should disallow nested optional and alt elements (e.g. " this is an really optional text ")
Note that the current schema definition only uses simple text for optional and alt.
The text was updated successfully, but these errors were encountered: