license of new help files

Hi all,

some contributors are not happy with ALv2 automatically included in the license for new help files, and it would by nice having a pure Mozilla license for new files. If we provide that, it will become necessary to keep the license, when the file is edited later on.

Currently the license is an xml-comment (<!-- license -->). That has the shortcoming that any xsl-transformation will loose it. Especially the helpauthoring tools looses any license information, when opening an .xhp file, and writes a default license including ALv2 when saving the file.

To keep the license, I suggest to introduce a new element "license" in the doctype. Having such element, the helpauthoring tool can write the Mozilla license into the element "license" for new files. If the tool detects an element "license" when opening a file, it can keep it. If the tool does not detect such element, then it can generate an element "license" and write the current mixed license as its content.

Does a tool exists, that automatically checks, that all files have got a license? Then it might be, that it would have to be adapted.

If such element should become required, a script is needed to move the license text from kind xml-comment to element content. Would that produce a request for translation?

What do you think about it?

Kind regards
Regina

Hi Regina,

some contributors are not happy with ALv2 automatically included in the
license for new help files, and it would by nice having a pure Mozilla
license for new files. If we provide that, it will become necessary to
keep the license, when the file is edited later on.

Currently the license is an xml-comment (<!-- license -->). That has the
shortcoming that any xsl-transformation will loose it. Especially the
helpauthoring tools looses any license information, when opening an .xhp
file, and writes a default license including ALv2 when saving the file.

To keep the license, I suggest to introduce a new element "license" in
the doctype. Having such element, the helpauthoring tool can write the
Mozilla license into the element "license" for new files. If the tool
detects an element "license" when opening a file, it can keep it. If the
tool does not detect such element, then it can generate an element
"license" and write the current mixed license as its content.

Does a tool exists, that automatically checks, that all files have got a
license? Then it might be, that it would have to be adapted.

If such element should become required, a script is needed to move the
license text from kind xml-comment to element content. Would that
produce a request for translation?

What do you think about it?

Can not we just do not touch the comments?
Or do we need to be sure to lock them in the <comment></comment> tag?

Best regards,
Lera

Hi Lera,

read answer below.

Lera schrieb:

Hi Regina,

some contributors are not happy with ALv2 automatically included in the
license for new help files, and it would by nice having a pure Mozilla
license for new files. If we provide that, it will become necessary to
keep the license, when the file is edited later on.

Currently the license is an xml-comment (<!-- license -->). That has the
shortcoming that any xsl-transformation will loose it. Especially the
helpauthoring tools looses any license information, when opening an .xhp
file, and writes a default license including ALv2 when saving the file.

To keep the license, I suggest to introduce a new element "license" in
the doctype. Having such element, the helpauthoring tool can write the
Mozilla license into the element "license" for new files. If the tool
detects an element "license" when opening a file, it can keep it. If the
tool does not detect such element, then it can generate an element
"license" and write the current mixed license as its content.

Does a tool exists, that automatically checks, that all files have got a
license? Then it might be, that it would have to be adapted.

If such element should become required, a script is needed to move the
license text from kind xml-comment to element content. Would that
produce a request for translation?

What do you think about it?

Can not we just do not touch the comments?

It is not possible to keep <!-- --> parts while applying a xsl-transformation. The parser simply skips those parts, so after the transformation you do not even know, that such a part has exist.

Or do we need to be sure to lock them in the <comment></comment> tag?

First I thought <comment></comment> would be sufficient. But it is not good in a theoretical view, because one should specify elements for a single, well defined purpose. From a practical view, one would need additional effort to distinguish a license from other annotation.

Kind regards
Regina

Hi Regina,

As the <meta> tag used to have child <history> tag, maybe we can include a <license> tag there which the help authoring tool write with new files and then the MPL license can be written to the header when that tag is seen.

  <meta>
    <topic id="textscalc0103070000xml">
      <title id="tit" xml-lang="en-US">Column &amp; Row Headers</title>
      <filename>/text/scalc/01/03070000.xhp</filename>
    </topic>
    <license>MPL</license>
  </meta>

Yousuf 'Jay' Philips

Hi Jay,

yes I have thought too to make it a child of the meta-element. Question is, whether we want to change all existing files and make the element mandantory, or we let existing files unchanged and make the element optional.

Besides that, follow-up changes in the helpauthoring tool needs to be discussed, in case we agree to introduce such element.

I'm waiting for a comment from Kendy, before actually start working (or not) on it.

Kind regards
Regina

Yousuf 'Jay' Philips schrieb: