license of new help files

classic Classic list List threaded Threaded
5 messages Options
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

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

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted
tagezi tagezi
Reply | Threaded
Open this post in threaded view
|

Re: license of new help files

Hi Regina,

В письме от 26 октября 2015 10:19:18 пользователь Regina Henschel написал:

> 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


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

Re: license of new help files

Hi Lera,

read answer below.

Lera schrieb:

> Hi Regina,
>
> В письме от 26 октября 2015 10:19:18 пользователь Regina Henschel написал:
>> 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

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted
jphilipz jphilipz
Reply | Threaded
Open this post in threaded view
|

Re: license of new help files

In reply to this post by tagezi
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

On 10/26/2015 03:20 PM, Lera wrote:

> Hi Regina,
>
> В письме от 26 октября 2015 10:19:18 пользователь Regina Henschel написал:
>> 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
>
>

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

Re: license of new help files

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:

> 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
>
> On 10/26/2015 03:20 PM, Lera wrote:
>> Hi Regina,
>>
>> В письме от 26 октября 2015 10:19:18 пользователь Regina Henschel
>> написал:
>>> 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
>>
>>
>


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted