# Exploring Relevant Artifacts of Release Notes:
The Practitioners’ Perspective

Sristy Sumana Nath  Computer Science, University of Saskatchewan
Saskatoon, Saskatchewan, Canada
<EMAIL_ADDRESS>Banani Roy  Computer Science, University of
Saskatchewan
Saskatoon, Saskatchewan, Canada
<EMAIL_ADDRESS>
###### Abstract

A software release note is one of the essential documents in the software
development life cycle. The software release contains a set of information,
e.g., bug fixes and security fixes. Release notes are used in different
phases, e.g., requirement engineering, software testing and release
management. Different types of practitioners (e.g., project managers and
clients) get benefited from the release notes to understand the overview of
the latest release. As a result, several studies have been done about release
notes production and usage in practice. However, two significant problems
(e.g., duplication and inconsistency in release notes contents) exist in
producing well-written & well-structured release notes and organizing
appropriate information regarding different targeted users’ needs. For that
reason, practitioners face difficulties in writing and reading the release
notes using existing tools. To mitigate these problems, we execute two
different studies in our paper. First, we execute an exploratory study by
analyzing 3,347 release notes of 21 GitHub repositories to understand the
documented contents of the release notes. As a result, we find relevant key
artifacts, e.g., issues (29%), pull-requests (32%), commits (19%), and common
vulnerabilities and exposures (CVE) issues (6%) in the release note contents.
Second, we conduct a survey study with 32 professionals to understand the key
information that is included in release notes regarding users’ roles. For
example, project managers are more interested in learning about new features
than less critical bug fixes. Our study can guide future research directions
to help practitioners produce the release notes with relevant content and
improve the documentation quality.

###### Index Terms:

Release notes, Exploratory study, Survey study, GitHub

##  I Introduction

Regular releases of software promise to improve product quality and high
customer satisfaction [12]. Release notes inform users about essential project
changes, e.g., bug fixes, feature enhancements, source code changes, from the
previous version to the latest version [13]. Practitioners (e.g., project
managers, developers and clients) use release notes in various software
development phases, e.g., requirements engineering, software programming,
debugging and testing phase [12, 5]. Several empirical studies have been done
to analyze the release note contents [7, 4, 13]. For example, Moreno et al.
[13] identify 17 types of changes that can be included in the release notes,
and Bi et al. [7] classify those changes into eight categories. Futhermore,
Abebe et al. [4] discover additional six different types of information in
release notes (described in Section II). Despite the existing studies, in
reality practitioners face difficulties in release note productions and usages
because of unclear contents with poor structural presentations. The documented
information in release notes is currently scattered and poorly organized, and
the information is described vaguely [7]. Consequently, release notes help
limited release note users in many cases. Therefore, identifying relevant
software artifacts and linking them with release notes can help to resolve
this issue [7].

The release management process consists of several activities from release
initiating to closing [9]. Different target users are involved in the release
process, and they are looking for different types of information regarding
their project roles [12] in release notes. Bi et al. [7] classify users into
two categories: (i) Release Note Producer and (ii) Release Note User.
Moreover, the authors cover significant discrepancies between release note
producers and users in perceiving release notes. For example, release note
producers focus on high-level changes and design decisions of development. In
contrast, release note users expect detailed descriptions of new features
compared to the previous release. Therefore, difficulties to use is another
problem of release notes usage. Because it is challenging to know the
requirements for the release notes concerning the target users, conducting a
survey study with practitioners can help understand the specific audiences’
needs.

Our study has two motives: (1) to investigate the relevant software artifacts
that can help to classify and structure the information in release notes; and
(2) to understand the target users’ requirements to tailor the release note
contents.

  * •

Exploratory Study: we extract and analyze 3,347 release notes of 21 GitHub
projects and then separate release notes’ contents (or sentences). We identify
different artifacts related to the contents and classify the artifacts into
three categories. The study design and result analysis are described in
Section III-B and Section IV-A respectively.

  * •

Survey Study: we gather practitioners’ opinions on release notes in practice
and receive responses from 32 participants. We classify these participants
into two categories: internal and external team members. The study design and
result analysis are described in Section III-C and Section IV-B respectively.

The key contributions of our study:

  * •

We extract the data from GitHub and develop a dataset for the contents of
release notes.

  * •

We identify essential software artifacts from the dataset those help to
produce well-structured release notes and classify the contents.

  * •

We analyze the response of the participants and summarize them, which can aid
tailoring release notes automatically for different stakeholders.

##  II  Background

###  II-A Release Note Contents

Different communities produce release notes according to their own guidelines,
and no common standards exist for writing release notes. In order to
understand the release note contents (see Table I), several empirical studies
have been done to investigate and categorize the documented information in
release notes. For example, Moreno et al. [13] manually inspected 990 release
notes to analyze and classify their content into 17 categories by focusing on
information at finer level granularity. Similarly, Bi et al. [7] classified
the documented information of release notes into eight main categories,
comparatively higher-level classification.

On the other hand, Abebe et al. [4] identify six different information, e.g.,
titles, system overview, resource requirements, installation, addressed issues
and caveat, that are included in release notes which contents are relatively
high-level. Authors mainly focus on software end-users’ perceptions of release
notes. Klepper et al. [12] identify some additional information, for example,
technical information and testing instructions, in the release notes. Our
study explores the different software artifacts relevant to the release note
contents.

TABLE I: The categories of the documented information in release notes Study |  Contents Category |  Percentage
---|---|---
Moreno et al. [13] |  Fixed Bugs |  90%
New Features |  46%
New Code Components |  43%
Modified Code Components |  40%
Modified Features |  26%
Refactoring Operations |  21%
Changes to Documentation |  20%
Upgraded Library Dep. |  16%
Deprecated Code Components |  10%
Deleted Code Components |  9%
Changes to Config. Files |  8%
Changes to Code Components Visibility |  7%
Changes to Test Suites |  7%
Known Issues |  6%
Replaced Code Components |  5%
Architectural Changes |  3%
Changes to Licenses |  2%
Bi et al. [7] |  Issues Fixed |  79.3%
New features |  55.1%
System internal changes |  25.1%
Non-functional requirements |  10.3%
Documentation update |  9.5%
Configuration |  2.8%
Required further actions |  2.1%
Refactoring and reuse |  1.9%

###  II-B Practitioners of Release Notes

Different role-based practitioners are involved in a software release process
[12]. Bi et al. [7] classify the stakeholders into two groups: release note
producers and users. Architects and team managers are mainly responsible for
producing release notes. Developers basically write release notes to reflect
internal code changes, whereas testers and operators use release notes to
perform their tasks. The purpose of release notes usages for different
stakeholders (e.g., developers and testers) regarding the phases are described
below:

  * •

In the pre-alpha phase, project managers and clients use the release notes to
discuss the project progress with new functionalities and significant issues.

  * •

The release notes of an alpha version are used both by developers and testers.
During this phase, developers first debug all the critical bugs found in a
pre-alpha phase. Then, the testers assess the functionality of the application
and compare the expected value with the final output value by utilizing the
release notes.

  * •

To test the system in the real environment, clients and end-users use the beta
version of the release notes.

  * •

Team managers release a stable version of the system and highlight activities
in the release notes of the RC version.

  * •

Before deploying the final version of product, the team members write the
release notes for the integrators (who are using a library in their code) and
end-users. Therefore, the release notes of the final version need to be
concise and properly understandable for the target audience.

However, the documented ineffective and unnecessary information creates
problems on the usage of release notes for the targeted audiences [7].
Therefore, our study investigates the valuable information of release notes
depending on the target users’ perceptions.

##  III Study Design

This section describes our research questions and study processes. Figure 1
represents the overview of this study.

###  III-A Research Questions

We address the following research questions:

RQ1: What software artifacts are important for preparing release notes? To
answer the research question, we conduct an exploratory study on 3,347 release
notes from 21 GitHub project repositories for understanding the release note
contents. Majority of the cases, we identify three crucial software artifacts,
e.g., commits, issues and pull-requests, from GitHub and one artifact, e.g.,
common vulnerabilities and exposures (CVE) issues, is extracted from external
sources. These valuable sources can help to prepare quality release notes.
Moreover, we find other key artifacts that can assist in maintaining well-
structured release notes.

RQ2: What types of release note contents may vary depending on the software
development role of practitioners? Everyone involved in a software development
project can be a practitioner of release notes., and the addressed contents of
the release notes can be modified depending on the users’ particular
information needs [12]. To understand the targeted users’ needs, we prepare an
online survey study and learn users’ opinions about release notes. This survey
study may help produce high-quality release notes and tailor the documented
release notes depending on users’ needs.

Figure 1: Overview of our study

###  III-B Study 1: Exploratory Study

One key goal of our study is to identify the relevant artifacts of release
notes (i.e., RQ1). Therefore, we targeted open-source projects and collected
release notes from GitHub-hosted projects.

####  III-B1 Data Collection

First, we collect release notes of open-source projects from GitHub. In this
step, we use search option of GitHub by sorting the most number of stars of
three-top languages, e.g., JavaScript, Java and Python, based on active
repositories [2]. To eliminate the trivial projects, we define following
criteria for a project selection from GitHub:

  * •

created: minimum of three years ago and is active

  * •

forks and stars: $\geq$ 1,000 times forks and $\geq$ 8,000 stars

  * •

contributors: $\geq$ 30 committers

  * •

total commit: $\geq$ 2,000

  * •

release notes: $\geq$ 30

  * •

total resolved issues: $\geq$ 500 issues

  * •

total pull-requests: $\geq$ 500 pull-requests

Then, we select total 21 projects, i.e., 8 JavaScript, 7 Java and 6 Python
projects, based on the number of stars. Among the projects, we did not
consider the non-engineering ones, e.g., iluwatar/java-design-patterns and
kdn251/interviews. Table II represents the detail information about the
selected repositories. After project selection, we extract the release notes
using the data extraction tool. Data is available on GitHub [1].

TABLE II: Dataset Overview SL. |  Repository |  Domain |  # Releases
---|---|---|---
1 |  vuejs/vue |  Web libraries and frameworks |  210
2 |  facebook/react |  Web libraries and frameworks |  96
3 |  twbs/bootstrap |  Web libraries and frameworks |  73
4 |  axios/axios |  Web libraries and frameworks |  32
5 |  nodejs/node |  System software |  252
6 |  mrdoob/three.js |  Web libraries and frameworks |  125
7 |  mui-org/material-ui |  Web libraries and frameworks |  322
8 |  chartjs/Chart.js |  Web libraries and frameworks |  81
9 |  spring-projects/spring-boot |  Software tools |  112
10 |  elastic/elasticsearch |  Web libraries and frameworks |  60
11 |  ReactiveX/RxJava |  System software |  225
12 |  google/guava |  Non-web libraries and frameworks |  34
13 |  PhilJay/MPAndroidChart |  Non-web libraries and frameworks |  44
14 |  redisson/redisson |  Non-web libraries and frameworks |  103
15 |  jenkinsci/jenkins |  System software |  128
16 |  tensorflow/tensorflow |  Software tools |  152
17 |  tiangolo/fastapi |  Non-web libraries and frameworks |  113
18 |  getsentry/sentry |  Non-web libraries and frameworks |  38
19 |  pandas-dev/pandas |  Non-web libraries and frameworks |  81
20 |  apache/airflow |  Software tools |  41
21 |  home-assistant/core |  Application software |  847
Figure 2: Artifacts of Release Notes

####  III-B2 Data Analysis

First, we filter out the empty release notes from the extracted data. Second,
we eliminate some information, e.g., contributors’ name, to analyze the
release note contents. Third, we split the sentences, i.e., contents, and
headings from release notes. For example, Fig. 2 represents a release note.
Here, Bug Fixes, Features are heading and the bullet listed information are
contents. Then, we extract the URLs from each sentences and maintain separate
column in the dataset for further analysis.

vuereactbootstrapaxiosnodethree.jsmaterial-uichart.jsspring-bootelasticsearchrxjavaguavampandriodchartredissonjenkinstensorflowairflowfastapisentrypandascore$0$$200$$400$$600$$800$$1{,}000$$1{,}200$$7$$32$$248$$9$$104$$55$$530$$18$$90$$5$$357$$4$$163$$3$$6$$405$$3$$205$$596$$23$$58$$90$$58$$300$$639$$589$$70$$93$$10$$55$$6$$25$$250$$123$$353$$180$$227$$79$$393$$449$$48$$300$$419$$171$$320$$55$$71$$105$$215$$52$$178$$517$$68$$30$$595$$568$$150$$41$$45$$25$$50$Contentscommits pull-requests issues CVEno links Figure 3: Release Note Contents Analysis TABLE III: Participants’ Data Category | Sub-Category | Participants | Total
---|---|---|---
Type | Internal User | 19 | 32
External User | 13
Experience | 1-3 years | 9 | 32
3-6 years | 16
More than 6 years | 7

###  III-C Study 2: Survey Study

The purpose of this survey study is to learn about effective information of
the release notes based on users’ opinion. In this survey, we recruit
participants who have minimum one year software development experience. In
particular, we choose the users who have knowledge in software release and
release notes. We adopt Non-Probabilistic Sampling methods, i.e., convenience
sampling and snowball sampling, to invite participants of our study. We
followed two steps to invite participants: (1) We sent email invitations to
200 contributors (only release note producers) of the selected GitHub projects
in our study and received 11 (5.5%) responses. In GitHub, one contributor
writes release notes in the specific release (marked as green color in Fig.
2). (2) We invited professionals, e.g., project managers, testers,
integrators, clients, within our social network and asked them to circulate
this invitation to other professionals using sampling methods. We get 21
responses by following this strategy.

We prepare set of questions to professionals about their role and experience
and their opinions about release notes. We design a survey study using Google
Form and asked participants about their roles and opinions in software
development. Firstly, participants select their specific role (e.g., project
manager, client) and write the number of years of experience in software
development process. Finally, they provide their responses of the questions
related to release notes, e.g., the content specification and structure of
release note and comment. We use the 4-point Likert Scale (based on
Importance) to understand the priority of the content of release notes based
on a user role. Moreover, Abebe et al. [4] identify three different structures
which are followed to prepare release notes, and we asked the participants to
provide their feedback on the suitable structure of release notes. To response
this question, participants select another 5-point Likert Scale (based on
Quality). We have received responses from total 32 participants. Our
questionnaires can be found on GitHub [1].

##  IV Result Analysis

We describe the results of the empirical study (to answer to RQ1) in Section
IV-A. The results of professionals’ opinions on release notes are shown in
Section IV-B (to answer RQ2).

###  IV-A RQ1: What software artifacts are important for preparing release
notes?

Several studies [14, 6, 7, 4, 15] analyze the release note production and
usage; however, the exploration study about release note contents and
identifying related software artifacts have not yet been investigated. To
investigate the relevant artifacts, we analyze the contents of our developed
dataset. We identify two types of information are important in the release
notes. One is heading of these contents, e.g., bug fixes and features. Second
is contents, i.e., list of resolved issues, e.g., v-slot: fix scoped slot
normalization combined with v-if (shown in Fig. 2). After pre-processing the
text, our dataset contains 37,152 release note contents. We mainly focus on
this study to find the relevant software artifacts with contents; therefore,
we preserve the heading for future work to classify the contents that can help
maintain the well-structured information in the release notes.

In the contents analysis step, we find some reference numbers along with URLs
that are incorporated with contents (see in Fig. 2). We identify four
different URLs pattern from the contents by extracting the URLs. Depending on
these patterns, we detect four different software artifacts that can help to
produce release notes. For example, issues, pull-requests, commits and CVE
(Common Vulnerabilities and Exposures) are linked with software release in
Fig. 2. For example,

  * •

Issues: /issues/issue_id

  * •

Pull-requests: /pull/pull_id

  * •

Commits: /commit/commit_id

  * •

CVE: /cvename.cgi?name=cve_id

Fig. 3 shows the comparison of these four type artifacts, and among them, the
bar chart represents pull-requests (32%) are the most important artifacts to
produce release notes. Interestingly, in 41% cases, the release note contents
are linked with multiple artifacts, e.g., issues, pull-requests and commits.
For example, the documented information of release notes is linked with
multiple artifacts (see in Fig. 3). To improve the usability of release notes
for practitioners, we need to consider the content selection approach from
these artifacts in future.

Additionally, we explore the linked commits, pull-requests and issues and
identify the labels of pull-requests and issues. For example, docs and v5 are
two labels of issues (see in Fig. 4). Cabot et al. [8] analyze the issue
labels and categorize them into four categories based on the usages, e.g.,
priority, versioning, workflow and architecture. Our analysis finds the text
similarity between content headings and issues/pull-requests label. The
contents come from the issues, pull-requests and commits (developers cannot
add labels in commit); therefore, we can use the labels to classify the
information in release notes. Table V represents the example.

Finally, based on the analysis of result of RQ1, we classify these artifacts
into three categories:

  * •

internal artifacts: pull-requests, issue, commit

  * •

external artifacts: CVE issues

  * •

other key artifacts: tags of issues/pull-request, milestones, change-log.md,
wiki

Moreover, around 14% cases, we do not find any related artifacts in the
release note contents. In future, we need to analysis manually to get some
more findings about release note contents.

Figure 4: Labels

###  IV-B RQ2: What types of release note contents may vary depending on the
software development role of practitioners?

Project managers21%Developers53%Testers26%

Integrators61.5%Clients38.5%

Figure 5: Ratio of User’s Participation TABLE IV: Survey Result Types of Content |  Practitioners’ Response (Likert Distributions & Avg. Score)
---|---
Project Managers | Developers | Testers | Integrators | Clients
Bug Fixes |  |  2.3 |  |  3.4 |  |  3.4 |  |  1.8 |  |  1.7
New Features |  |  3.4 |  |  3.4 |  |  3.1 |  |  3.2 |  |  3.4
Feature Enhancements |  |  3.3 |  |  3.3 |  |  3.1 |  |  3.0 |  |  3.4
Documentation Changes |  |  2.8 |  |  2.4 |  |  2.1 |  |  3.0 |  |  3.2
Internal Code Changes |  |  2.4 |  |  3.1 |  |  1.6 |  |  2.6 |  |  1.8
Architectural Changes |  |  3.0 |  |  2.9 |  |  1.7 |  |  1.3 |  |  1.9
Security Issues |  |  3.1 |  |  2.3 |  |  2.8 |  |  2.5 |  |  3.0
Performance Issues |  |  3.2 |  |  2.8 |  |  2.8 |  |  2.4 |  |  3.1
Dependency Changes |  |  2.7 |  |  3.2 |  |  1.7 |  |  3.2 |  |  2.5
Configuration Changes |  |  2.4 |  |  2.4 |  |  1.8 |  |  3.1 |  |  3.3
Tests |  |  3.2 |  |  2.4 |  |  3.3 |  |  2.4 |  |  3.1

We conduct a survey study with professionals and define a set of questions
about release notes contents and structure. In this study, we need expert
opinions, and for that reason, we encourage those participants who have at
least one year experience in software development. From the previous studies
[13, 7] (details in Table I), we can see that bug fixes and new features are
documented more in the release notes than the other types of contents. Our
survey study includes these content types and asks participants what contents
categories they are looking for along with the justifications. Table IV
presents the content categories and summary of survey results.

According to their opinion, software release notes can be customized that will
help for documenting for target users. Participants choose option of 4-Likert
Scale (not important, slightly important, moderately important, important). We
received the responses of 32 participants of five different role-based users.
The results of the online survey are summarised in Table IV. We have found the
following observations:

  * •

Bug fixes are essential content for developers and testers based on the avg.
score (i.e., 3.4). Besides, Project managers and clients mention they are
interested to know learn major or critical issues from the release notes
rather than the all bugs. However, list of all bugs is not helpful.

  * •

New features and feature enhancements are important content of release notes
for both internal users and external users (Avg. score of likert distributions
of Table IV).

  * •

Integrators and clients concern about the documentation changes, e.g.,
installation instructions and UI changes, in the software development.

  * •

The internal code changes include added/modified /deleted classes/methods in
the source code. Developers must document these changes in release notes
because it will help track changes, and new developers can benefit. Moreover,
integrators want to know the source code changes that can help them integrate
into their system.

  * •

Architecture provides fundamental structure of software development and
development teams follow the architectural process, e.g., model-view-
controller model, to build the software. Refactoring is one kind of
architectural changes; this process is restructuring the code without changing
the external behavior. Project managers and developers give priority to know
about architectural changes through the release notes.

  * •

Project managers and clients want to know the non-functional changes, e.g.,
security issues or performance improvements, about the software. Because these
changes help to improve the quality of software by solving some
vulnerabilities and optimization issues.

  * •

Dependency changes mean upgrade the APIs or libraries. This content essential
for developers and integrators because without updating the dependency changes
they cannot implement or use the updated version of the software.

  * •

Integrators and clients want to learn about the required configuration changes
(e.g., installation or hardware requirements) because without updating these
requirements they cannot use the latest release.

  * •

Testing information, e.g., test cases or suites, is useful content of release
notes for testers. Because the internal testers receive unstable versions and
can know which tasks to be tested or which to be ignored.

very poorpoorfairGoodExcellent$0$$5$$10$$15$#number of responseStyle 1Style
2Style 3 Figure 6: Response about the Structure of Release Notes

Additionally, we ask the participants about the suitable structure of release
notes, which is easy to read. The following three styles are observed in [4]:

  * •

Style 1: summarize or re-phrase the addressed issues in the current release

  * •

Style 2: list of selected issues that were addressed in the current release
(do not summarize issues)

  * •

Style 3: list of all addressed issues in the current release

Participants provide score according to the quality structure (very poor,
poor, fair, good, excellent) of release notes. We identified style 1, e.g.,
summary of related issues is more preferable (i.e., 14 and 6 users choose Good
and Excellent option, respectively) than the other two structures (see Fig.
6). Example of statements:

  * •

“Need to use few sentences with bullet points to let users know what’s new and
how to navigate these.”

  * •

“Major issues of the release are required to include in release notes;
however, sometimes technical contexts are made hard to read the release
notes.”

##  V Discussions

We discuss our results analysis findings and threat to validity in this
section.

###  V-A Release Notes Generation

We discuss few concerns about release notes generation.

Content Selection. The results of RQ1 show that release note contents are
linked with issues, pull requests, and commits. Generally, issues are created
first, and developers solve those issues through commits and pull requests.
Release notes of the latest version contain the resolved issues list from the
immediate previous release. However, we identify that the documented contents
can be different among issue titles, pull-request titles, and commit messages.
We represent one content from the release note of version 2.6 [3] of Vue
GitHub project.

  * •

Content: attrs: do not consider translate attribute as boolean

  * •

Commit message: attrs: do not consider translate attribute as boolean [10]

  * •

Issue title: isBooleanAttr for the HTML attribute ’translate’ [11]

  * •

Pull-request title: fix #11391: translate attribute had incorrectly the key as
it’s value [16]

The above example shows that the documented content comes from the commit
messages, and the titles of issue and pull-request are different. Content
selection is a crucial part of producing good-quality release notes. Different
automated release notes generation tools [14, 6] consider only issues and
generate text from source code changes. We encourage researchers could
consider the content selection from the relevant artifacts before developing
new tools.

TABLE V: Examples of Common Content Types Examples of headings |  Examples of labels
---|---
Fixed, Bug fixes |  bug, regression, type:bug, bug on dependency library
Breaking changes, Features |  feat:ssr, feature request, type:feat
Development, Added, Modified |  core, type:dev, type:chore
Docs, Documentation changes |  docs, type:documentation
Performance Improvements |  performance, type:performance
Dependency Changes, API Changes, Upgrades, Dependencies |  dependencies, type:dependency-upgrades

Content Classification & Structure. Bi et al. [7] encourage researchers to
identify other software artifacts which help to classify and structure the
information in release notes. We identify that the issues and pull-requests
labels can help to classify the release note contents. Table V represents the
similarity between contents’ headings and tags. Labels or tags can help to
classify the release note contents. Moreover, we identify another two
artifacts, e.g., milestones and wiki, from Three.js, redisson and jenkins
projects. Similarly, setting a milestone of upcoming releases can organize the
structure of documenting information of release notes.

Content Tailoring. There are no worldwide standards or guidelines for
documenting release notes [13, 7]. Furthermore, documenting all issues or
changes in release notes makes it too lengthy. Consequently, readers lose
interest in knowing the critical addressed issues in the current release [4].
Our second study finds that different practitioners look for different
information in the release notes. Therefore, automated techniques need to
integrate tailoring tools to customize the release note contents regarding
target users’ requirements.

###  V-B Issues of Existing Release Notes

TABLE VI: Problems of Existing Release Notes Language | Num. of Projects |  Duplication (%) |  Inconsistency (%)
---|---|---|---
JavaScript | 8 | 19 | 10
Java | 7 | 22 | 7
Python | 6 | 0 | 0

We identify two problems in the existing release notes in GitHub and that are
discussed as follows.

Figure 7: Content Duplication Figure 8: Inconsistency

Content Duplication. The first issue is same contents (or sentences) appear
double or triple times in a release note. Fig. 7 represents an example of
duplication problem and Table VI shows the duplication percentage in different
GitHub projects. We investigate the reason behind this issue, and identify
that issues are tagged by multiple labels, e.g., feature and css.
Surprisingly, we notice that the duplication issue has not appeared in Python
projects’ release notes. Therefore, we analyze the release notes of the python
projects and find that release note producers prepare release note contents
manually. For example, a content from the release note of version 1.3.0 of
Pandas is Performance improvement in DataFrame.corr() for method=kendall and
this content link with issue. However, the issue title is
DataFrame.corr(method=”kendall”) calculation is slow However, producing
release notes manually takes lengthy time around 2 to 4 hours [14]. In future,
we need to consider the duplication problems to prepare the release notes
using automated tools.

Inconsistency between Content Headings and Labels. The second problem is an
inconsistency between the contents’ headlines and tags. Our analysis
identifies the similarity between the contents’ headlines and tags. Table V
shows the examples of headings and issue tags. We can see that those issues
are labelled as bug, type:bug, usually those are listed under Bug Fixes or
Fixed headings. However, in some cases, we find inconsistency. Fig. 8
represents an example of inconsistency issue. For example, an issue is
labelled by improvement tag; however, this issue is written under Bug Fixes
heading in the release note. It is possible to eliminate the inconsistency
issue, while the automated release notes generation techniques will be
considered the labels to classify the contents.

###  V-C Threats to Validity

Internal validity- The content of release notes can be different based on the
project domains, e.g., application software and software tools. Our study
selects popular open-source projects’ repositories in GitHub based on the most
stars (i.e., more than 8,000 stars) and these projects belong to different
domains. We analyze the three top most popular languages’ projects, e.g.,
JavaScript, Java and Python, (details in Table II) based on the active
repositories to mitigate the internal threat. Moreover, we sort the projects
based on the total number of releases and mitigate those with less than 30
releases.

External validity- The total number of participants of this survey study is
may not be enough to understand the real-life scenarios about release notes
usage in software development practice. To mitigate this threat, on average,
our study participants have 3.5 years of experience in software development
and use version control systems, e.g., Git, to keep track of the changes in
the system.

##  VI Related Work

Empirical Studies. Many empirical studies have been done in prior works. Among
them, some studies investigate the documented information types in release
notes [7, 4, 13] (detailed discussion in Section II). Moreover, they
identified that the provided information could differ in major and minor
release notes from system to system. Klepper et al. [4] propose a technique
for manually tailoring release notes by a release manager while considering
three different kinds of stakeholders, e.g., users, customers and team members
in agile software development.

Tools and Techniques. Several studies aim to generate release notes
automatically or semi-automatically [14, 6, 15, 12]. A semi-automatic approach
proposed by Klepper et al. [12] for generating audience-specific release
notes. This approach used issue tracker, version control system and build
server as data sources for release notes generation and the release manager
tailored the contents for different target users. Moreno et al. [14] proposed
another tool (i.e., ARENA) for Java projects. This tool uses external tools,
e.g., change extractor, issue extractor, commits-issues linker and code change
summarizer, to generate the complete release notes. Ali et al. [6] follow a
similar approach to generate release notes for Node.js projects. Both are
language-specific tools. Contrary, Nath et al. [15] proposed a release notes
generation technique by applying text summarization techniques (i.e.,
TextRank) using related commits and pull-requests. This approach selects top-
ranked contents. Therefore, some important sentences might be missed to
generate automated release notes. From prior studies, we find that the proper
investigation is required to understand the input sources for the documented
contents of existing release notes. Therefore, we investigate more than 3,000
release note contents and structure from GitHub.

##  VII Conclusion

We conduct an exploratory study and a user survey study on the release note
contents to improve the quality of release notes production based on different
practitioners’ needs because, which are not explored in the existing studies.
Our first study identifies several artifacts, e.g., commits, issues and pull-
requests, from our empirical study which can be linked with release note
contents. In addition, we detect other key artifacts, e.g., tags and
milestones, that can assist in classifying and maintaining an exemplary
structure of the contents. Since different practitioners get benefits by using
release notes, it is essential to understand what information needs to be
included for different users. Keeping this in mind, we conduct a survey study
to understand users’ specific requirements. Moreover, we discuss our findings
of release note production and existing issues of the release note contents.
We are currently working on the three additional research questions to extend
our research: (i) What is the efficient way to generate release notes
automatically using the relevant artifacts?; (ii) How can we integrate user-
specific requirements to produce release notes?; and (iii) How to assess the
quality of release notes?

## Acknowledgment

This research is supported by the Natural Sciences and Engineering Research
Council of Canada (NSERC), and by two Canada First Research Excellence Fund
(CFREF) grants coordinated by the Global Institute for Food Security (GIFS)
and the Global Institute for Water Security (GIWS).

## References

  * [1] Dataset.  https://github.com/sristysumana/Human22.
  * [2] Githut.  https://githut.info.
  * [3] Vue v2.6.13.  https://github.com/vuejs/vue/releases/tag/v2.6.13.
  * [4] Surafel Lemma Abebe, Nasir Ali, and Ahmed E. Hassan.  An empirical study of software release notes.  Empirical Softw. Engg., 21(3):1107–1142, June 2016.
  * [5] Emad Aghajani, Csaba Nagy, Mario Linares-Vásquez, Laura Moreno, Gabriele Bavota, Michele Lanza, and David C. Shepherd.  Software documentation: The practitioners’ perspective.  In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, ICSE ’20, page 590–601, New York, NY, USA, 2020. Association for Computing Machinery.
  * [6] M. Ali, A. Aftab, and W. H. Buttt.  Automatic release notes generation.  In 2020 IEEE 11th International Conference on Software Engineering and Service Science (ICSESS), pages 76–81, 2020.
  * [7] T. Bi, X. Xia, D. Lo, J. Grundy, and T. Zimmermann.  An empirical study of release note production and usage in practice.  IEEE Transactions on Software Engineering, pages 1–1, 2020.
  * [8] Jordi Cabot, Javier Luis Cánovas Izquierdo, Valerio Cosentino, and Belén Rolandi.  Exploring the use of labels to categorize issues in open-source software projects.  In 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), pages 550–554, 2015.
  * [9] Simon Cleveland and Timothy J. Ellis.  Orchestrating end-user perspectives in the software release process: An integrated release management framework.  Adv. Hum. Comput. Interact., 2014:805307:1–805307:15, 2014.
  * [10] Vue Commit.  Commit message.  https://github.com/vuejs/vue/commit/cd57393fd3e2c169d450607bc4f03652d106bcc2.
  * [11] Vue Issue.  Issue title.  https://github.com/vuejs/vue/issues/11391.
  * [12] Sebastian Klepper, Stephan Krusche, and Bernd Brügge.  Semi-automatic generation of audience-specific release notes.  In CSED@ICSE, 2016.
  * [13] Laura Moreno, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, Andrian Marcus, and Gerardo Canfora.  Automatic generation of release notes.  In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, FSE 2014, page 484–495, New York, NY, USA, 2014. Association for Computing Machinery.
  * [14] Laura Moreno, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, Andrian Marcus, and Gerardo Canfora.  Arena: An approach for the automated generation of release notes.  IEEE Transactions on Software Engineering, 43:106–127, 2017.
  * [15] Sristy Sumana Nath and Banani Roy.  Towards automatically generating release notes using extractive summarization technique.  In Proceedings of the 33rd International Conference on Software Engineering & Knowledge Engineering, (SEKE), pages 241–248, 2021.
  * [16] Vue Pull-request.  Pull-request title.  https://github.com/vuejs/vue/pull/11392.


the type

$\displaystyle|\partial_{\xi^{\prime}}^{\beta}V_{x,k,z}(\xi^{\prime})|\lesssim
2^{C_{\beta}\varepsilon k}2^{-k/2-(n-1)k/2-k|\beta|},$ (4.58)

when $|\xi^{\prime}|\sim 2^{k},$ then, we have the kernel estimate

$\|\smallint e^{2\pi i[\Phi_{\tau}(x,\xi^{\prime})-\xi^{\prime}\cdot
z]}V_{x,k,z}(\xi^{\prime})\eta_{k}(\xi^{\prime})d\xi^{\prime}\|_{L^{1}(\mathbb{R}^{n}_{x})}\lesssim
2^{C\varepsilon k}2^{-k/2}.$ (4.59)

So, note that for the validity of (4.55) we have used Lemma 4.13 applied to
$V_{x,k,z}(\xi^{\prime}):=W^{0}_{x,k,z}(\xi^{\prime})-W_{x,k,z}(\xi^{\prime}).$
The proof of the $L^{1}$-boundedness of $E$ is complete.

###### Proof of the main Theorem 3.1.

With the notation in Subsection 4.1 the operator $T$ has been decomposed into
its degenerate and non-degenerate components, $T_{\textnormal{deg}}$ and
$T_{\textnormal{non-deg}},$ respectively. In Subsection 4.2 in Proposition 4.4
we have proved that the degenerate operator $T_{\textnormal{deg}}$ is bounded
on $L^{1}.$ As for the non-degenerate operator $T_{\textnormal{non-deg}},$ we
have constructed in Subsubsection 4.3.1 a Fourier integral operator $A,$ which
is an average operator, of the same order that $T$ and a pseudo-differential
operator $S$ of order zero. We have proved, that the factorisation approach
introduced in Tao [45] also operates in our case, namely, that $A$ is bounded
on $L^{1},$ (see Proposition 4.9) $S$ is of weak (1,1) type in view of the
standard Calderón-Zygmund theory, and that the error operator
$E=T_{\textnormal{nondeg}}-SA$ is bounded on $L^{1},$ see Subsection 4.4.
Since $T=T_{\textnormal{deg}}+SA+E,$ then $T$ is of weak (1,1) type. The proof
of Theorem 3.1 is complete. ∎

##  5\. Final remarks

###  5.1. Applications

In order to illustrate the applications of Theorem 3.1 to a priori estimates
for the Cauchy problem with complex characteristics we consider the case where
the associated operator is a classical pseudo-differential operator of order
one. Let us introduce some required notation. Let $(X,g)$ be a compact
Riemmanian manifold of dimension $n$ and let us consider $T>0.$ Denote by
$\Delta_{g}$ the positive Laplacian associated to the metric $g.$ Denote the
space $L^{1}_{s}(X)$ defined by the norm

$\|f\|_{L^{1}_{s}(X)}=\|(1+\Delta_{g})^{\frac{s}{2}}f\|_{L^{1}(X)}.$

We also consider the weak $L^{1}_{s}$-space defined by the seminorm

$\|f\|_{L^{1,\infty}_{s}(X)}=\|(1+\Delta_{g})^{\frac{s}{2}}f\|_{L^{1,\infty}(X)},$

and by $L^{1,\infty}_{s,\textnormal{loc}}(X),$ its local version, namely the
family of functions $g$ such that for any compactly supported function
$\phi\in C^{\infty}_{0}(X),$ $[(1+\Delta_{g})^{\frac{s}{2}}g]\phi\in
L^{1,\infty}(X).$

Denote $\partial_{t}$ the partial derivative with respect to the time variable
$t\in[0,T],$ and let $D_{t}=-i\partial_{t}.$ Let us consider the Cauchy
problem for a first-order classical pseudo-differential operator $A,$

$\begin{cases}D_{t}v-Av=0,&(t,x)\in[0,T]\times X,\\\ v(0,x)=f(x).&\end{cases}$
(5.1)

We assume that its principal symbol
$a(t,x,\xi),\,(t,x,\xi)\in[0,T]\times(T^{*}X\setminus\\{0\\}),$ has non-
negative imaginary part, namely, $a$ satisfies

$\textnormal{Im}[a(t,x,\xi)]>0,\,|\xi|\neq 0.$

The solution operator $U(t)$ of (5.1) can be realised as a Fourier integral
operator of order zero with a global complex phase function of positive type,
see [38, Page 117] and also Laptev, Safarov and Vassiliev [28] for details.
Applying (essentially) Theorem 3.1 to the operator

$(1+\Delta_{g})^{\frac{s}{2}}U(t)(1+\Delta_{g})^{-\frac{n-1}{4}-\frac{s}{2}}$

of order $-(n-1)/2,$ we have that for any compactly supported initial datum
$f\in L^{1}_{s+\frac{n-1}{2}}(X)$, and for a fixed time $t\in[0,T],$ the
solution $v$ of the Cauchy problem (5.1) satisfies $v(t,\cdot)\in
L^{1,\infty}_{s,\textnormal{loc}}(X).$ This analysis proves the following
consequence of Theorem 3.1.

######  Corollary 5.1.

Let $s\in\mathbb{R},$ and let $f\in L^{1}_{s+\frac{n-1}{2}}(X)$ be compactly
supported. Then, for a fixed $t\in[0,T]$, the solution $v$ of the Cauchy
problem (5.1) satisfies $v(t,\cdot)\in L^{1,\infty}_{s,\textnormal{loc}}(X).$

###### Proof.

We write $v(x,t)=U(t)f(x),$ namely, the solution $v$ of (5.1) in terms of the
solution operator $U(t).$ Since $f\in L^{1}_{s+\frac{n-1}{2}}(X),$ we have
that

$(1+\Delta_{g})^{\frac{n-1}{4}+\frac{s}{2}}f\in L^{1}(X).$

We can use the factorisation

$\displaystyle(1+\Delta_{g})^{\frac{s}{2}}v=(1+\Delta_{g})^{\frac{s}{2}}U(t)(1+\Delta_{g})^{-\frac{n-1}{4}-\frac{s}{2}}(1+\Delta_{g})^{\frac{n-1}{4}+\frac{s}{2}}f,$

and the fact that
$(1+\Delta_{g})^{\frac{s}{2}}U(t)(1+\Delta_{g})^{-\frac{n-1}{4}-\frac{s}{2}}$
is a Fourier integral operator with complex phase of order $-(n-1)/2$333See
[38, Page 117] and also Laptev, Safarov and Vassiliev [28] for details. to
prove that $v(t,\cdot)\in L^{1,\infty}_{s,\textnormal{loc}}(X).$ Indeed, if
$\\{\phi_{i}\\}_{i=1}^{N}$ denotes a partition of unity subordinated to a
finite open covering $\\{O_{i}\\}_{i=1}^{N}$ of the compact manifold $X,$ then
$\sum_{i=1}^{N}\phi_{i}=1,$ and $\textnormal{supp}[\phi_{i}]\subset O_{i}.$ We
can assume that the covering $\\{O_{i}\\}_{i=1}^{N}$ is an atlas for the
manifold $X,$ and then each $O_{i}$ is diffeomorphic to an Euclidean open set
$\tilde{O}_{i}\subset\mathbb{R}^{n},$ $n=\dim(X).$ Note that
$(1+\Delta_{g})^{\frac{s}{2}}U(t)(1+\Delta_{g})^{-\frac{n-1}{4}-\frac{s}{2}}M_{\phi_{i}}$
is a Fourier integral operator of order $-(n-1)/2$ that can be microlocalised
to a Fourier integral operator whose symbol is compactly supported in the
spatial variable. Here, $M_{\phi_{i}}g=\phi_{i}g$ denotes the multiplication
operator by the function $\phi_{i}.$ Then, Theorem 3.1 imply that for any
$\psi\in C^{\infty}_{0}(X),$ we have that

$\displaystyle\|\psi(1+\Delta_{g})^{\frac{s}{2}}v\|_{L^{1,\infty}(X)}$
$\displaystyle=\|\psi(1+\Delta_{g})^{\frac{s}{2}}U(t)(1+\Delta_{g})^{-\frac{n-1}{4}-\frac{s}{2}}(1+\Delta_{g})^{\frac{n-1}{4}+\frac{s}{2}}f\|_{L^{1,\infty}(X)}$
$\displaystyle\lesssim_{N}\sum_{i=1}^{N}\|\psi(1+\Delta_{g})^{\frac{s}{2}}U(t)(1+\Delta_{g})^{-\frac{n-1}{4}-\frac{s}{2}}M_{\phi_{i}}(1+\Delta_{g})^{\frac{n-1}{4}+\frac{s}{2}}f\|_{L^{1,\infty}(X)}$
$\displaystyle\leq
C_{\psi,N}\|(1+\Delta_{g})^{\frac{n-1}{4}+\frac{s}{2}}f\|_{L^{1}(X)}\lesssim_{\phi,N}\|f\|_{L^{1}_{s+\frac{n-1}{2}}(X)},$

which proves Corollary 5.1. ∎

We also observe that a similar analysis can be adapted to investigate the
mapping properties of the parametrix of other first-order complex partial
differential operators, see e.g. [38, Page 120] for a problem that appears
naturally in the study of the oblique derivative problem. This was observed
e.g. by Melin and Sjöstrand in [29]. For other applications of the theory of
Fourier integral operators with complex phases to a priori estimates for the
Cauchy problem with complex characteristics we refer to Trèves [46, Chapter
XI] and to [38, Chapter 5].

###  5.2. Conclusions and bibliographical discussion

In this work we have analysed the weak (1,1) boundedness of Fourier integral
operators with complex-valued phase functions. As in the setting of real-
valued phase functions regarding the weak (1,1) boundedness due to Tao in
[45], our estimate is local in the sense that we have considered the symbol
$a$ to be compactly supported in the $x$-variable, following the previous
approaches, see Seeger, Sogge and Stein [43], Beals [3], and the monograph of
the second author about the mapping properties of Fourier integral operators
with complex phases [38]. Among other things, the sharpness of the order
$-(n-1)/2$ for the weak (1,1) inequality of elliptic Fourier integral
operators has been discussed by the authors in [9], and we also refer to [37]
for the sharpness of Seeger-Sogge-Stein orders regarding the
$L^{p}$-boundeness of these operators.

There has been in the last decades a wide interest in the analysis of the
global continuity properties for Fourier integral operators. This problem can
be traced back to the work of Asada and Fujiwara [2] and of Peral [34] and
Miyachi [32]. We refer to [39], [40] and [12, 13] for global properties on
$L^{p}$-spaces. As for global criteria for Fourier integral operators on
Hörmander classes removing the calculus condition $\delta<\rho,$ and allowing
the ranges $0\leq\delta<1$ and $0<\rho\leq 1,$ we refer the reader to Dos
Santos Ferreira and Staubach [14], Kenig and Staubach [27] and the works of
Staubach and his collaborators [25, 26, 35, 36]. We also refer to the seminal
work of Álvarez and Hounie [1] for the boundedness of pseudo-differential
operators without the condition $\delta<\rho,$ which was the starting point
for the aforementioned results in the setting of Fourier integral operators.
For the global parametrization of Lagrangian distributions we refer the reader
to Laptev, Safarov, and Vassiliev [28] and to [38]. We also refer to the work
[10] for the global definition of Fourier integral operators on compact Lie
groups in terms of the group Fourier transform.

The theory of Fourier integral operators with complex phases was developed by
Melin and Sjöstrand in [29] motivated by the problem of the construction of
parametrices for operators of principal type with non-real principal symbols,
see for instance [30]. The singularities of the Bergman kernel can be also
approximated in terms of asymptotic expansions of certain Fourier integral
operators with complex-valued functions, see Boutet de Monvel and Sjöstrand
[7]. For a systematic analysis of the Bergman kernel we refer to Fefferman
[18, 19].

There has been also wide activity concerning the smoothing estimates for
Fourier integral operators after the proof of Bourgain and Demeter [6] of the
decoupling conjecture. The smoothing effect for Fourier integral operators was
conjectured by Sogge in [44]. It will be difficult to review the literature
about this problem here, but in what follows we share some works in this
direction. Indeed, we refer the reader to Bourgain [5], Minicozzi and Sogge
[31], Guth, Wang and Zhang [21], Beltran, Hickman and Sogge [4], to Gao, Liu,
Miao, and Xi [20] and references therein for details.

Conflict of interests statement - Data Availability Statements The authors
state that there is no conflict of interest. Data sharing does not apply to
this article as no datasets were generated or analysed during the current
study.

###  5.3. Acknowledgement

The authors thank Terence Tao for suggesting the factorisation approach used
in this manuscript.

## References

  * [1] Álvarez, J. Hounie, J. Estimates for the kernel and continuity properties of pseudo-differential operators. Ark. Mat. 28(1), 1–22, (1990).
  * [2] Asada, K. Fujiwara, D. On some oscillatory integral transformations in $L^{2}(\mathbb{R}^{n}).$ Japan. J. Math. (N.S.) 4(2), 299–361, (1978).
  * [3] Beals, R. M. $L^{p}$ boundedness of Fourier integral operators. Mem. Amer. Math. Soc. 38, no. 264, viii+57 pp, (1982).
  * [4] Beltran, D. Hickman, J. Sogge, C. D. Variable coefficient Wolff-type inequalities and sharp local smoothing estimates for wave equations on manifolds, Anal. PDE, 13(2), 403–433, (2020).
  * [5] Bourgain, J. $L^{p}$-estimates for oscillatory integrals in several variables, Geom. Funct. Anal. 1(4), 321–374, (1991).
  * [6] Bourgain, J. Demeter, C. The proof of the $l^{2}$ decoupling conjecture, Ann. of Math. (2) 182:1, 351–389, (2015).
  * [7] Boutet de Monvel, L. Sjöstrand, J. Sur la singularité des noyaux de Bergman et de Szego. (French) Journées: Équations aux Dérivées Partielles de Rennes (1975), pp. 123–164, Astérisque, No. 34–35, Soc. Math. France, Paris, 1976.
  * [8] Calderón, A. P., Zygmund, A. On the existence of certain singular integrals. Acta Math., 88, 85–139 (1952).
  * [9] Cardona, D., Ruzhansky, M. Sharpness of Seeger-Sogge-Stein orders for the weak (1,1) boundedness of Fourier integral operators., Arch. Math. 119, 189–198, (2022).
  * [10] Cardona, D., Ruzhansky, M. Subelliptic pseudo-differential operators and Fourier integral operators on compact Lie groups, to appear in MSJ Memoirs, Math. Soc. Japan, Tokyo, 180 Pages.
  * [11] Cordero, E. Nicola, F. Rodino, L. Boundedness of Fourier integral operators on $\mathscr{F}L^{p}$ spaces. Trans. Amer. Math. Soc. 361(11), 6049–6071, (2009).
  * [12] Coriasco, S. Ruzhansky, M. Global $L^{p}$ continuity of Fourier integral operators. Trans. Amer. Math. Soc. 366(5), 2575–2596, (2014).
  * [13] Coriasco, S. Johansson, K. Toft, J. Global wave-front properties for Fourier integral operators and hyperbolic problems. J. Fourier Anal. Appl. 22(2), 85–333, (2016).
  * [14] Dos Santos Ferreira, D. Staubach, W. Global and local regularity of Fourier integral operators on weighted and unweighted spaces, Mem. Amer. Math. Soc., 229 (2014), no. 1074, xiv+65 pp.
  * [15] Duistermaat, J. J., Hörmander, L.  Fourier integral operators. II.  Acta Math., 128(3-4), 183–269, (1972).
  * [16] Èskin, G. I. Degenerate elliptic pseudodifferential equations of principal type. (Russian) Mat. Sb. (N.S.) 82(124), 585–628, (1970).
  * [17] Fefferman, C. Stein, E. M. $H^{p}$ spaces of several variables. Acta Math., 129, 137–193, (1972).
  * [18] Fefferman, C. The Bergman kernel and biholomorphic mappings of pseudoconvex domains, Invent. Math. 26, 1–65, (1974).
  * [19] Fefferman, C. L. Monge-Ampère equations, the Bergman kernel, and geometry of pseudoconvex domains. Ann. of Math. 103(2), 395–416, (1976).
  * [20] Gao, C. Liu, B. Miao, C. Xi, Y. Square function estimates and local smoothing for Fourier integral operators. Proc. Lond. Math. Soc. (3), 126(6), 1923–1960, (2023).
  * [21] Guth, L. Wang, H. Zhang, R. A sharp square function estimate for the cone in $\mathbb{R}^{3}$, Ann. of Math. 192(2), 551–581, (2020).
  * [22] Hörmander, L. Lecture notes at the Nordic Summer School of Mathematics, 1969.
  * [23] Hörmander, L. The analysis of the linear partial differential operators, Vol. III-IV. Springer-Verlag, (1985).
  * [24] Hörmander, L.  $L^{2}$ estimates for Fourier integral operators with complex phase.  Ark. Mat., 21, 283–307, (1983).
  * [25] Israelsson, A. Rodríguez-López, S. Staubach, W. Local and global estimates for hyperbolic equations in Besov-Lipschitz and Triebel-Lizorkin spaces. Anal. PDE, 14(1), 1–44, (2021).
  * [26] Israelsson, A. Mattsson, T. Staubach, W. Boundedness of Fourier integral operators on classical function spaces. J. Funct. Anal. 285(5), Paper No. 110018, 64 pp, (2023).
  * [27] Kenig, C. Staubach, W. $\Psi$-pseudodifferential operators and estimates for maximal oscillatory integrals. Studia Math. 183(3), 249–258, (2007).
  * [28] Laptev, A. Safarov, Y. Vassiliev, D. On global representation of Lagrangian distributions and solutions of hyperbolic equations, Comm. Pure Appl. Math., 47(11), 1411–1456, (1994).
  * [29] Melin, A., Sjöstrand, J. Fourier integral operators with complex-valued phase functions. In: Chazarain, J. (eds) Fourier Integral Operators and Partial Differential Equations. Lecture Notes in Mathematics, vol 459. Springer, Berlin, Heidelberg, (1975).
  * [30] Melin, A., Sjöstrand, J. Fourier integral operators with complex phase functions and parametrix for an interior boundary value problem, Commun. Partial. Differ. Equ., 1(4), 313–400, (1976).
  * [31] Minicozzi, W. P. Sogge, C. Negative results for Nikodym maximal functions and related oscillatory integrals in curved space, Math. Res. Lett. 4:2-3, 221–237, (1997).
  * [32] Miyachi, A. On some estimates for the wave operator in and $L^{p}$ and $H^{p},$ J. Fac. Sci. Univ. Tokyo Sect. IA Math., 27, 331–354, (1980).
  * [33] Nirenberg, L., A proof of the Malgrange preparation theorem. Proc. Liverpool Singularities Symp. I, Dept. pure Math. Univ. Liverpool 1969–1970, 97–105, (1971).
  * [34] Peral, J. C. $L^{p}$ estimates for the wave equation. J. Funct Anal. 36(1), 114–145, (1980).
  * [35] Rodríguez-López, S. Rule, D. Staubach, W. On the boundedness of certain bilinear oscillatory integral operators. Trans. Amer. Math. Soc. 367(10), 6971–6995, (2015).
  * [36] Rodríguez-López, S. Rule, D. Staubach, W. A Seeger-Sogge-Stein theorem for bilinear Fourier integral operators. Adv. Math. 264, 1–54, (2014).
  * [37] Ruzhansky, M.  On the sharpness of Seeger-Sogge-Stein orders.  Hokkaido Math. J., 28(2), 357–362, (1999).
  * [38] Ruzhansky, M.  Regularity theory of Fourier integral operators with complex phases and singularities of affine fibrations, volume 131 of CWI Tract.  Stichting Mathematisch Centrum, Centrum voor Wiskunde en Informatica, Amsterdam, 2001.
  * [39] Ruzhansky, M. Sugimoto, M. Global L2-boundedness theorems for a class of Fourier integral operators. Commun. Partial. Differ. Equ., 31(4-6), 547–569, (2006).
  * [40] Ruzhansky, M. Sugimoto, M. Weighted Sobolev L2 estimates for a class of Fourier integral operators. Math. Nachr. 284(13), 1715–1738, (2011).
  * [41] Stein, E. M. Topics in harmonic analysis related to the Littlewood-Paley theory, Vol. 63 of Annals of Mathematics Studies, Princeton University Press, 1970.
  * [42] Stein, E. M., Harmonic analysis: real-variable methods, orthogonality, and oscillatory integrals, Princeton Mathematical Series, 43, Princeton University Press, Princeton, NJ, 1993, xiv+695.
  * [43] Seeger, A. Sogge, C. D, Stein, E. M.  Regularity properties of Fourier integral operators.  Ann. of Math., 134(2), 231–251, (1991).
  * [44] Sogge, C. D. Propagation of singularities and maximal functions in the plane, Invent. Math. 104(2), 349–376, (1991).
  * [45] Tao, T. The weak-type (1,1) of Fourier integral operators of order $-(n-1)/2.$ J. Aust. Math. Soc. 76(1), 1–21, (2004).
  * [46] Trèves, F. Introduction to pseudodifferential and Fourier integral operators. Vol. 2. Fourier integral operators. University Series in Mathematics. Plenum Press, New York-London, 1980. xiv+301–649+xi pp.
  * [47] Wolff, T. Lectures on harmonic analysis. With a foreword by Charles Fefferman and preface by Izabella Łaba, Edited by Łaba and Carol Shubin. University Lecture Series, 29, Amer. Math. Soc., Providence, RI, 2003.


# On the equivalence of the BMO-norm of divergence-free vector fields and norm
of related paracommutators

M. N. Demchenko111St. Petersburg Department of V. A. Steklov Institute of
Mathematics of the Russian Academy of Sciences, 27 Fontanka, St. Petersburg,
Russia. E-mail<EMAIL_ADDRESS>
The research was supported by the RFBR grant 20-01-00627-a.

###### Abstract

We establish an estimate of the BMO-norm of a divergence-free vector field in
${\mathbb{R}}^{3}$ in terms of the operator norm of an associated
paracommutator. The latter is essentially a $\Psi$DO, whose symbol depends
linearly on the vector field. Together with the result of P. Auscher and M.
Taylor concerning the converse estimate, this provides an equivalent norm in
the space of divergence-free fields from BMO.

Keywords: BMO, paracommutators, divergence-free fields.

##  1 Introduction

Let $I$ be a singular integral operator of convolution type bounded in
$L_{2}({\mathbb{R}}^{d})$. Its compositions $Iu$ and $uI$ with a pointwise
multiplier $u\in L_{\infty}({\mathbb{R}}^{d})$, and therefore, the commutator

$I_{u}=[u,I],$ (1)

are bounded in $L_{2}({\mathbb{R}}^{d})$ as well, and the corresponding
operator norm can trivially be estimated in terms of $\|u\|_{L_{\infty}}$. As
is well known from harmonic analysis, under some additional assumptions on
$I$, the commutator $I_{u}$ can be estimated as follows [1]:

$\|I_{u}\|\leqslant C\|u\|_{\rm BMO},$ (2)

where $C$ depends only on $d$, $I$ (we recall the definition of the space BMO
and some of its properties in sec. 3). This fact was generalized to a certain
class of paradifferential operators $I_{u}$ (paracommutators), which depend on
the coefficient $u$ in a more general way, than it is prescribed by (1). In
particular, this is true for the operators studied in the present paper, which
have the following form. Consider the Weyl’s decomposition for vector-
functions in ${\mathbb{R}}^{3}$ [2, Theorems 1.1, 2.1]:

$L_{2}({\mathbb{R}}^{3};{\mathbb{C}}^{3})=G\oplus J,$

where the subspaces $G$ and $J$ are defined as follows

$\displaystyle G=\overline{G_{0}}^{L_{2}},\quad
G_{0}=\\{\partial\varphi\,|\,\varphi\in C_{0}^{\infty}({\mathbb{R}}^{3})\\},$
$\displaystyle J=\overline{\\{u\in
C_{0}^{\infty}({\mathbb{R}}^{3};{\mathbb{C}}^{3})\,|\,{\rm
div}u=0\\}}^{L_{2}}.$

To a vector-function $u\in L_{2,\,\rm
loc}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, we associate a linear operator
$I_{u}:G_{0}\to G$ acting on $f\in G_{0}$ as follows

$I_{u}f=P(u\times f),$ (3)

where $\times$ is the vector product, $P$ is the orthogonal projection on $G$
acting in $L_{2}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$. Observe that $u\times
f\in L_{2}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, which means that $I_{u}f$ is
well-defined. The operator $I_{u}$ assumes a continuation to a bounded
operator in $G$, provided that the norm $\|I_{u}\|$ is finite, the latter
being defined by

$\|I_{u}\|=\sup_{f\in
G_{0}\setminus\\{0\\}}\frac{\|I_{u}f\|_{L_{2}}}{\|f\|_{L_{2}}}.$

(Note also that if $\|I_{u}\|<\infty$ and $u$ is a real-valued vector-
function, then $I_{u}$ is a bounded skew-symmetric operator, i.e.
$I_{u}^{*}=-I_{u}$.) The operator $I_{u}$ satisfies estimate (2), if $u\in{\rm
BMO}$ [3], [4, chap. 3, sec. 8].

The present paper concerns the converse of estimate (2) for the operators of
the form (3):

$\|u\|_{\rm BMO}\leqslant C\|I_{u}\|.$ (4)

Such estimates are known in the case when a linear mapping $u\mapsto I_{u}$
satisfies a certain nondegeneracy condition (see [5] and the literature cited
therein). In particular, for the commutator (1), this result was established
in [6]. To our knowledge, none of the previous results applies when $I_{u}$ is
defined by relation (3). In fact, such a relation of the field $u$ and the
operator $I_{u}$ is degenerate, which is demonstrated by

######  Theorem 1.

Let $u\in L_{2,\,\rm loc}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$ satisfy the
relation ${\rm curl}\,u=0$. Then $I_{u}=0$.

This simple (as it will be seen from the proof) fact indicates that estimate
(4) can be valid only under some additional assumptions on $u$. Sufficient
conditions are given by

######  Theorem 2.

Let $u\in L_{2,\,\rm loc}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$ satisfy the
condition

$\int_{{\mathbb{R}}^{3}}\frac{|u(x)|}{1+|x|^{4}}\,dx<\infty,$ (5)

the relation ${\rm div}u=0$, and $\|I_{u}\|<\infty$. Then $u$ belongs to BMO
and satisfies estimate (4).

It should be stressed that the condition $u\in L_{2,\,\rm
loc}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$ concerning local behavior of $u$ and
condition (5) concerning behavior of $u$ at the infinity, which both occur in
Theorem 2, are not too restrictive in the sense that they are satisfied by any
$u$ from BMO. Thus in view of estimate (2) for the operators of the form (3)
and Theorem 2, we obtain

######  Corollary 1.

There are positive constants $c$, $C$, such that for any $u$ from BMO
satisfying ${\rm div}u=0$, we have

$c\|I_{u}\|\leqslant\|u\|_{\rm BMO}\leqslant C\|I_{u}\|.$

##  2 Proof of Theorem 1

It suffices to show that under the assumptions of Theorem 1, the field
$u\times f$ is orthogonal to $G$ for any $f\in G_{0}$. For $u\in
C^{1}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, this follows from the fact that for
an arbitrary function $\varphi\in C_{0}^{\infty}({\mathbb{R}}^{3})$, we have

$\int_{{\mathbb{R}}^{3}}\langle{}u\times f,\overline{\partial\varphi}\rangle
dx=-\int_{{\mathbb{R}}^{3}}{\rm div}(u\times f)\overline{\varphi}\,dx=0$

(here and further $\langle{}u,v\rangle$ is the bilinear form in
${\mathbb{C}}^{3}$ defined on the standard orthonormal frame
$\\{e_{\alpha}\\}_{\alpha=1,2,3}$ by the equality
$\langle{}e_{\alpha},e_{\beta}\rangle=\delta_{\alpha\beta}$). In the last
equality we used the identity

${\rm div}(u\times f)=\langle{\rm curl}\,u,f\rangle-\langle{}u,{\rm
curl}\,f\rangle$ (6)

and the relation ${\rm curl}\,f=0$.

In the case of nonsmooth $u$, one can apply a smoothing mollifier, which
provides smooth functions $u^{\varepsilon}$, $\varepsilon>0$, ${\rm
curl}\,u^{\varepsilon}=0$, approximating $u$ in the $L_{1}$-norm on the
intersection of the supports of $f$ and $\varphi$. We have

$\int_{{\mathbb{R}}^{3}}\langle{}u\times f,\overline{\partial\varphi}\rangle
dx=\int_{{\mathbb{R}}^{3}}\langle{}u,f\times\overline{\partial\varphi}\rangle
dx=\lim_{\varepsilon\to
0}\int_{{\mathbb{R}}^{3}}\langle{}u^{\varepsilon},f\times\overline{\partial\varphi}\rangle
dx\\\ =\lim_{\varepsilon\to
0}\int_{{\mathbb{R}}^{3}}\langle{}u^{\varepsilon}\times
f,\overline{\partial\varphi}\rangle dx=0.$

##  3 BMO space

A function $u\in L_{1,\,\rm loc}({\mathbb{R}}^{d};{\mathbb{C}}^{N})$ is said
to belong to BMO if

$\|u\|_{\rm BMO}=\sup_{Q}|Q|^{-1}\int_{Q}|u(x)-u_{Q}|\,dx<\infty,$ (7)

where the supremum is taken over all cubes $Q\subset{\mathbb{R}}^{d}$,

$u_{Q}=|Q|^{-1}\int_{Q}u(x)\,dx.$

For constant functions $u=\rm const$ (and only for them), we have $\|u\|_{\rm
BMO}=0$. Thus the functional $\|u\|_{\rm BMO}$ is a seminorm, rather than a
norm. However, we will call it the BMO-norm.

Functions from BMO belong to $L_{p,\,\rm loc}({\mathbb{R}}^{d})$ for any
$1\leqslant p<\infty$, and the norm (7) is equivalent to

$\sup_{Q}\left(|Q|^{-1}\int_{Q}|u(x)-u_{Q}|^{p}\,dx\right)^{1/p}.$

Recall that we have already used the fact that ${\rm BMO}\subset L_{2,\,\rm
loc}({\mathbb{R}}^{d})$ when we obtained Corollary 1.

We will need certain characterizations of $L_{2}$ and BMO spaces, which differ
from their standard definitions. Let a real-valued radially symmetric function
$\Phi$ from $C_{0}^{\infty}({\mathbb{R}}^{d})$ satisfy the following
conditions

$\Phi\not\equiv 0,\quad\widehat{\Phi}(0)=0$ (8)

($\hat{f}$ denotes Fourier transform of $f$). In this case, we have

$\int_{0}^{\infty}\widehat{\Phi}(t\xi)^{2}\frac{dt}{t}=c^{2}>0,\quad\xi\neq 0$
(9)

(due to (8), the integral converges and $c$ is positive). Then $L_{2}$ space
can be characterized in terms of convolutions of its functions with the
functions

$\Phi_{t}(x)=t^{-d}\Phi(t^{-1}x),\quad t>0.$ (10)

Namely, for any function $u\in L_{2}({\mathbb{R}}^{d})$, we have

$\left(\int_{0}^{\infty}\|\Phi_{t}*u\|_{L_{2}}^{2}\frac{dt}{t}\right)^{1/2}=c\|u\|_{L_{2}},$
(11)

where $c$ is the same constant as in equality (9). This fact is a trivial
consequence of Plancherel’s theorem, since
$\widehat{\Phi}_{t}(\xi)=\widehat{\Phi}(t\xi)$. Thus the convolutions
$\Phi_{t}*u$ provide an equivalent norm in $L_{2}$ space. As is known, various
function spaces are characterized in terms of such convolutions [7, 8, 9],
which is far less trivial than the same fact for $L_{2}$ space. This concerns
Sobolev spaces (or, more generally, Triebel-Lizorkin spaces), Besov’s spaces,
Hardy space, and BMO space. In most cases, conditions similar to (8) (more
strong ones, as a rule) are imposed on $\Phi$. Now we give a characterization
of BMO space, which will be used later. For any $u$ from BMO, we have [7]

$\sup_{Q}\left(\int_{0}^{l(Q)}\|\Phi_{t}*u\|_{Q}^{2}\,\frac{dt}{t}\right)^{1/2}\leqslant
C\|u\|_{\rm BMO},$

where $l(Q)$ is the side length of the cube $Q$, and the functional
$\|\cdot\|_{Q}$ is defined as follows

$\|u\|_{Q}=\left(|Q|^{-1}\int_{Q}|u|^{2}dx\right)^{1/2}.$

The converse estimate holds as well: if a function $u\in L_{1,\,\rm
loc}({\mathbb{R}}^{d};{\mathbb{C}}^{N})$ satisfies condition

$\int_{{\mathbb{R}}^{d}}\frac{|u(x)|}{1+|x|^{d+1}}\,dx<\infty,$ (12)

then [7]

$\|u\|_{\rm BMO}\leqslant
C\sup_{Q}\left(\int_{0}^{l(Q)}\|\Phi_{t}*u\|_{Q}^{2}\,\frac{dt}{t}\right)^{1/2}.$
(13)

Condition (5) in Theorem 2 is nothing else than condition (12) in the case
$d=3$. For any function from BMO, condition (12) holds automatically. Thus the
supremum occurring in the last two estimates yields an equivalent norm in BMO
space.

##  4 Auxiliary assertions

In the proof of Theorem 2, estimate (13) will be used. However, $\Phi$ will be
replaced by the function $\Psi=\Phi*\Phi$ with $\Phi=\Delta\Theta$, where

$\Theta\in C_{0}^{\infty}(\\{x\in{\mathbb{R}}^{3}\,|\,\,|x|<1/2\\})$ (14)

is a real-valued radially symmetric function, $\Theta\not\equiv 0$. Clearly,
$\Phi,\Psi\in C_{0}^{\infty}({\mathbb{R}}^{3})$. Besides, the functions $\Phi$
and $\Psi$ satisfy conditions (8).

For $\alpha=1,2,3$, introduce the following vector-functions

$\Phi^{\alpha}=\partial\partial_{\alpha}\Theta.$

Let $\Phi_{t}$, $\Phi^{\alpha}_{t}$, $\Psi_{t}$ ($t>0$) be the families of
functions related to $\Phi$, $\Phi^{\alpha}$, $\Psi$, respectively, by
equality of the form (10) with $d=3$.

To a vector-function $u$, we associate a family of vector-functions

$u^{\alpha}_{t}=\Phi^{\alpha}_{t}\,\vec{*}\,u,\quad\alpha=1,2,3,\quad t>0,$

where the “vector convolution” operation $\vec{*}$ is defined by

$(u\,\vec{*}\,v)(x)=\int_{{\mathbb{R}}^{3}}u(x-y)\times v(y)\,dy.$

In the proof of Theorem 2, we will estimate the convolutions $\Psi_{t}*u$. To
this end, we will need the following lemma, which relates them to the
functions $u^{\alpha}_{t}$.

######  Lemma 1.

For $u\in L_{1,\,\rm loc}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, ${\rm div}u=0$,
$t>0$, we have

$\Psi_{t}*u=-\sum_{\alpha=1,2,3}\Phi^{\alpha}_{t}\,\vec{*}\,u^{\alpha}_{t}.$
(15)

###### Proof.

Since $\Psi_{t}$, $\Phi^{\alpha}_{t}$ are compactly supported functions, both
sides of equality (15) are smooth functions in ${\mathbb{R}}^{3}$. It is
possible to approximate $u$ by smooth divergence-free convolutions with an
appropriate smooth compactly supported function. So it will suffice to
establish (15) for smooth functions $u$.

Now fix an arbitrary point $x\in{\mathbb{R}}^{3}$ and choose a closed ball $B$
centered at $x$ (its radius will be specified later). In the ball $B$, we have

$u={\rm curl}\,z,\quad z\in C^{\infty}(B;{\mathbb{C}}^{3}),$

which is a consequence of the condition ${\rm div}u=0$. Choose an arbitrary
smooth compactly supported extension of $z$ to ${\mathbb{R}}^{3}$, which will
be denoted by the same symbol, and define the field $v={\rm curl}\,z$ entirely
in ${\mathbb{R}}^{3}$. Since $u=v$ in $B$, we will have

$(\Psi_{t}*u)(x)=(\Psi_{t}*v)(x),\quad\left(\Phi^{\alpha}_{t}\,\vec{*}\,u^{\alpha}_{t}\right)(x)=\left(\Phi^{\alpha}_{t}\,\vec{*}\,v^{\alpha}_{t}\right)(x),$

as soon as we choose the radius of $B$ sufficiently large that relations
$\Psi_{t}(x-y)=0=\Phi^{\alpha}_{t}(x-y)$ hold for any
$y\in{\mathbb{R}}^{3}\setminus B$. Therefore we will obtain (15) at $x$, as
soon as we establish the same relation for $v$ (incidentally, the latter will
be established entirely in ${\mathbb{R}}^{3}$ rather than at the single point
$x$). We have

$\widehat{\Phi}^{\alpha}(\xi)=\widehat{\Phi}(\xi)\,\langle\xi,e_{\alpha}\rangle\frac{\xi}{|\xi|^{2}},\quad\widehat{\Phi}^{\alpha}_{t}(\xi)=\widehat{\Phi}^{\alpha}(t\xi)=\widehat{\Phi}_{t}(\xi)\,\langle\xi,e_{\alpha}\rangle\frac{\xi}{|\xi|^{2}},$

whence

$\hat{v}^{\alpha}_{t}(\xi)=\widehat{\Phi}^{\alpha}_{t}(\xi)\times\hat{v}(\xi)=\widehat{\Phi}_{t}(\xi)\,\langle\xi,e_{\alpha}\rangle\,\frac{\xi\times\hat{v}(\xi)}{|\xi|^{2}}.$

Therefore

$\left(\sum_{\alpha=1,2,3}\Phi^{\alpha}_{t}\,\vec{*}\,v^{\alpha}_{t}\right)\widehat{}\,(\xi)=\sum_{\alpha=1,2,3}\widehat{\Phi}^{\alpha}_{t}(\xi)\times\hat{v}^{\alpha}_{t}(\xi)=\sum_{\alpha=1,2,3}\widehat{\Phi}_{t}(\xi)^{2}\langle\xi,e_{\alpha}\rangle^{2}\,\frac{\xi\times(\xi\times\hat{v}(\xi))}{|\xi|^{4}}\\\
=\widehat{\Phi}_{t}(\xi)^{2}\,\frac{\xi\times(\xi\times\hat{v}(\xi))}{|\xi|^{2}}=-\widehat{\Phi}_{t}(\xi)^{2}\hat{v}(\xi)=-\widehat{\Psi}_{t}(\xi)\hat{v}(\xi)$

(we used the equality $\langle\hat{v}(\xi),\xi\rangle=0$, which follows from
${\rm div}v=0$). Thus we arrive at relation (15) for the function $v$. ∎

######  Lemma 2.

For $u\in C^{1}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, we have

$u^{\alpha}_{t}=t(\partial_{\alpha}\Theta)_{t}*{\rm
curl}\,u,\quad\alpha=1,2,3,\quad t>0,$ (16)

where $(\partial_{\alpha}\Theta)_{t}$ is related to $\partial_{\alpha}\Theta$
by equality of the form (10) with $d=3$.

###### Proof.

The left hand side of (16) equals

$\Phi^{\alpha}_{t}\,\vec{*}\,u=t(\partial(\partial_{\alpha}\Theta)_{t})\,\vec{*}\,u.$

So the desired assertion follows immediately from the identity

$(\partial f)*g=f*\partial g$

for scalar functions, in which $f$ should be replaced by
$t(\partial_{\alpha}\Theta)_{t}$, and $g$ should be replaced by the components
of the vector-function $u$. ∎

In the proof of the following lemma, we will use the representaion of the
orthogonal projection $P$ in terms of Fourier transform ($v\in
L_{2}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$):

$\widehat{Pv}(\xi)=\frac{\xi}{|\xi|^{2}}\,\langle\hat{v}(\xi),\xi\rangle.$
(17)

######  Lemma 3.

For $u\in C^{1}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, $f\in G_{0}$, the
following equality holds true

$\Phi_{t}*I_{u}f=t(\partial\Theta)_{t}*\langle{\rm curl}\,u,f\rangle,\quad
t>0.$ (18)

###### Proof.

The scalar function $\langle{\rm curl}\,u,f\rangle$ belongs to
$L_{2}({\mathbb{R}}^{3})$, so equality (18) is equivalent to the following
equality of functions from $L_{2}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$ of the
variable $\xi$

$-t^{2}|\xi|^{2}\widehat{\Theta}(t\xi)(P(u\times
f))\,\hat{}\,(\xi)=t^{2}i\xi\,\widehat{\Theta}(t\xi)(\langle{\rm
curl}\,u,f\rangle)\,\hat{}\,(\xi).$ (19)

In view of (17), we have

$|\xi|^{2}(P(u\times f))\,\hat{}\,(\xi)=\xi\,\langle(u\times
f)\,\hat{}\,(\xi),\xi\rangle.$

However, the inner product $\langle(u\times f)\,\hat{}\,(\xi),\xi\rangle$
equals Fourier transform of $-i\,{\rm div}(u\times f)$, the latter being an
element of $L_{2}({\mathbb{R}}^{3})$, hence

$\langle(u\times f)\,\hat{}\,(\xi),\xi\rangle=-i({\rm div}(u\times
f))\,\hat{}\,(\xi)=-i(\langle{\rm curl}\,u,f\rangle)\,\hat{}\,(\xi).$

In the second equality we used identity (6). Thus we obtain equality (19), and
so equality (18) as well. ∎

##  5 Proof of Theorem 2 in the case of smooth $u$

In this section, we prove Theorem 2 under the additional assumption $u\in
C^{1}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$.

Let $Q$ be an arbitrary cube in ${\mathbb{R}}^{3}$. Fix $\beta\in\\{1,2,3\\}$
and choose a function $\tilde{f}\in G_{0}$ that is equal to $e_{\beta}$ on the
cube centered at the origin with side length $1+\sqrt{3}$. Then for the
function

$f(x)=\tilde{f}\left(\frac{x-c(Q)}{l(Q)}\right)$

($c(Q)$ is the center of the cube $Q$), we have

$\displaystyle f\big{|}_{Q^{\prime}}=e_{\beta},$ (20)
$\displaystyle\|I_{u}f\|_{L_{2}}\leqslant\|I_{u}\|\cdot\|f\|_{L_{2}}\leqslant
C\|I_{u}\|\cdot|Q|^{1/2},$ (21)

where $Q^{\prime}$ is the cube centered at $c(Q)$ with side length
$(1+\sqrt{3})\,l(Q)$. Due to (18), for $\alpha=1,2,3$, $t>0$, we have

$\langle\Phi_{t}*I_{u}f,e_{\alpha}\rangle=t(\partial_{\alpha}\Theta)_{t}*\langle{\rm
curl}\,u,f\rangle.$ (22)

In the case $t<l(Q)$, the convolution occurring on the right hand side being
restricted on the cube $Q$ is determined by the values of the function
$\langle{\rm curl}\,u,f\rangle$ on $Q^{\prime}$, which follows from (14). This
can be recorded as follows

$\chi_{Q}(t(\partial_{\alpha}\Theta)_{t}*\langle{\rm
curl}\,u,f\rangle)=\chi_{Q}(t(\partial_{\alpha}\Theta)_{t}*(\chi_{Q^{\prime}}\langle{\rm
curl}\,u,f\rangle))$

(here and further $\chi_{E}$ is the characteristic function of a set $E$).
According to (20), on $Q^{\prime}$ we have $\langle{\rm
curl}\,u,f\rangle=\langle{\rm curl}\,u,e_{\beta}\rangle$. Hence the expression
we have obtained equals

$\chi_{Q}\left(t(\partial_{\alpha}\Theta)_{t}*(\chi_{Q^{\prime}}\langle{\rm
curl}\,u,e_{\beta}\rangle)\right)=\chi_{Q}\left(t(\partial_{\alpha}\Theta)_{t}*\langle{\rm
curl}\,u,e_{\beta}\rangle\right).$

Thus the convolution (22) on the cube $Q$ equals

$t(\partial_{\alpha}\Theta)_{t}*\langle{\rm
curl}\,u,e_{\beta}\rangle=\langle{}t(\partial_{\alpha}\Theta)_{t}*{\rm
curl}\,u,e_{\beta}\rangle=\langle{}u^{\alpha}_{t},e_{\beta}\rangle$

(the last equality follows from (16)). Therefore

$\|\langle{}u^{\alpha}_{t},e_{\beta}\rangle\|_{Q}=\|\langle\Phi_{t}*I_{u}f,e_{\alpha}\rangle\|_{Q}\leqslant|Q|^{-1/2}\|\langle\Phi_{t}*I_{u}f,e_{\alpha}\rangle\|_{L_{2}}\leqslant|Q|^{-1/2}\|\Phi_{t}*I_{u}f\|_{L_{2}}.$

Hence

$\left(\int_{0}^{l(Q)}\|\langle{}u^{\alpha}_{t},e_{\beta}\rangle\|_{Q}^{2}\,\frac{dt}{t}\right)^{1/2}\leqslant
C|Q|^{-1/2}\left(\int_{0}^{l(Q)}\|\Phi_{t}*I_{u}f\|_{L_{2}}^{2}\,\frac{dt}{t}\right)^{1/2}\\\
\leqslant
C|Q|^{-1/2}\left(\int_{0}^{\infty}\|\Phi_{t}*I_{u}f\|_{L_{2}}^{2}\,\frac{dt}{t}\right)^{1/2}\leqslant
C|Q|^{-1/2}\|I_{u}f\|_{L_{2}}\leqslant C\|I_{u}\|.$

In the second to last inequality we applied (11), whereas in the last one we
used (21). Now varying $\beta=1,2,3$, yields

$\left(\int_{0}^{l(Q)}\|u^{\alpha}_{t}\|_{Q}^{2}\,\frac{dt}{t}\right)^{1/2}\leqslant
C\|I_{u}\|.$ (23)

Now we are able to estimate the convolutions $\Psi_{t}*u$. According to (15),
we have

$\|\Psi_{t}*u\|_{Q}\leqslant\sum_{\alpha=1,2,3}\|\Phi^{\alpha}_{t}\,\vec{*}\,u^{\alpha}_{t}\|_{Q}=|Q|^{-1/2}\sum_{\alpha=1,2,3}\|\chi_{Q}(\Phi^{\alpha}_{t}\,\vec{*}\,u^{\alpha}_{t})\|_{L_{2}}.$

For $t<l(Q)$, we may apply the equality

$\chi_{Q}(\Phi^{\alpha}_{t}\,\vec{*}\,u^{\alpha}_{t})=\chi_{Q}(\Phi^{\alpha}_{t}\,\vec{*}\,(\chi_{Q^{\prime}}u^{\alpha}_{t}))$

(we have already used a similar argument previously), and proceed with our
calculation

$|Q|^{-1/2}\sum_{\alpha=1,2,3}\|\chi_{Q}(\Phi^{\alpha}_{t}\,\vec{*}\,(\chi_{Q^{\prime}}u^{\alpha}_{t}))\|_{L_{2}}\leqslant|Q|^{-1/2}\sum_{\alpha=1,2,3}\|\Phi^{\alpha}_{t}\,\vec{*}\,(\chi_{Q^{\prime}}u^{\alpha}_{t})\|_{L_{2}}\\\
\leqslant
C|Q|^{-1/2}\sum_{\alpha=1,2,3}\|\chi_{Q^{\prime}}u^{\alpha}_{t}\|_{L_{2}}\leqslant
C\sum_{\alpha=1,2,3}\|u^{\alpha}_{t}\|_{Q^{\prime}}.$

Whence

$\left(\int_{0}^{l(Q)}\|\Psi_{t}*u\|_{Q}^{2}\,\frac{dt}{t}\right)^{1/2}\leqslant
C\sum_{\alpha=1,2,3}\left(\int_{0}^{l(Q)}\|u^{\alpha}_{t}\|_{Q^{\prime}}^{2}\,\frac{dt}{t}\right)^{1/2}\leqslant
C\|I_{u}\|$

(the last inequality follows from estimate (23) applied to the cube
$Q^{\prime}$).

##  6 Proof of Theorem 2 in the general case

Under the assumptions of Theorem 2, we may turn from $u$ to its smooth
approximations $u^{\varepsilon}=\omega^{\varepsilon}*u$, $\varepsilon>0$,
where

$\displaystyle\omega\in C_{0}^{\infty}({\mathbb{R}}^{3}),\quad\omega\geqslant
0,\quad\int_{{\mathbb{R}}^{3}}\omega(x)\,dx=1,\quad\omega^{\varepsilon}(x)=\varepsilon^{-3}\omega(\varepsilon^{-1}x).$

Clearly, the field $u^{\varepsilon}$ belongs to
$C^{\infty}({\mathbb{R}}^{3};{\mathbb{C}}^{3})$, satisfies condition (5) and
the relation ${\rm div}u^{\varepsilon}=0$. Besides, we have
$\|I_{u^{\varepsilon}}\|\leqslant\|I_{u}\|$. Indeed, the operator
$I_{u^{\varepsilon}}$ can be represented as follows

$I_{u^{\varepsilon}}f=\int_{{\mathbb{R}}^{3}}\omega^{\varepsilon}(y)I_{u(\cdot-y)}fdy.$

Evidently, $\|I_{u(\cdot-y)}\|=\|I_{u}\|$, so by applying Minkowski’s
inequality, we obtain

$\|I_{u^{\varepsilon}}f\|=\bigg{\|}\int_{{\mathbb{R}}^{3}}\omega^{\varepsilon}(y)I_{u(\cdot-y)}fdy\bigg{\|}\leqslant\int_{{\mathbb{R}}^{3}}\omega^{\varepsilon}(y)\|I_{u(\cdot-y)}f\|dy\leqslant\int_{{\mathbb{R}}^{3}}\omega^{\varepsilon}(y)\|I_{u(\cdot-y)}\|\,\|f\|dy\\\
=\|I_{u}\|\,\|f\|\int_{{\mathbb{R}}^{3}}\omega^{\varepsilon}(y)dy=\|I_{u}\|\,\|f\|.$

As was shown in sec. 5, we have

$\|u^{\varepsilon}\|_{\rm BMO}\leqslant C\|I_{u^{\varepsilon}}\|\leqslant
C\|I_{u}\|.$

We will establish the same fact for $u$ with the use of the standard
definition of BMO-norm (7). We have $(u^{\varepsilon})_{Q}\to u_{Q}$,
$\varepsilon\to 0$, for any cube $Q$. Hence by applying Fatou’s lemma we
obtain

$|Q|^{-1}\int_{Q}|u(x)-u_{Q}|dx\leqslant\sup_{\varepsilon>0}|Q|^{-1}\int_{Q}|u^{\varepsilon}(x)-(u^{\varepsilon})_{Q}|dx\leqslant\sup_{\varepsilon>0}\|u^{\varepsilon}\|_{\rm
BMO}\leqslant C\|I_{u}\|,$

which implies the desired assertion.

## References

  * [1] R. R. Coifman, R. Rochberg, and G. Weiss, Factorization theorems for Hardy spaces in several variables, Ann. of Math., 103 (1976), 611–635.
  * [2] E. B. Bykhovskii, N. V. Smirnov, Orthogonal decomposition of the space of vector functions square-summable on a given domain, and the operators of vector analysis, Trudy Mat. Inst. Steklov., 59 (1960), 5–36 (in Russian).
  * [3] P. Auscher and M. Taylor, Paradifferential operators and commutator estimates, Comm. PDE, 20 (1995), 1743–1775.
  * [4] M. E. Taylor, Tools for PDE. Pseudodifferential Operators, Paradifferential Operators, and Layer Potentials, Mathematical Surveys and Monographs, Volume 81, AMS, 2000.
  * [5] S. Janson and J. Peetre, Paracommutators – Boundedness and Schatten-Von Neumann Properties, Transactions of the American Mathematical Society, 305:2 (1988), 467–504.
  * [6] S. Janson, Mean oscillation and commutators of singular integral operators, Ark. Math., 16 (1978), 263–270.
  * [7] E. M. Stein, Harmonic Analysis: Real-Variable Methods, Orthogonality, and Oscillatory Integrals, Princeton University Press, 1993\.
  * [8] H. Triebel, Theory of Function Spaces II, Birkhauser, Basel, 1992.
  * [9] L. Grafakos, Modern Fourier Analysis, 2nd Edition, Graduate Texts in Mathematics, Volume 250, Springer, 2009.