Auto saved by Logseq
This commit is contained in:
@@ -0,0 +1,44 @@
|
||||
# 2021-01-29-1736-Notes-Submission-MSR11_DataShowCase
|
||||
|
||||
|
||||
|
||||
*\textit{Context}.*
|
||||
*What is JSON schema and why is it important? @Luca: please rewrite a bit this part and provide some references.
|
||||
*
|
||||
|
||||
JSON is a popular data serialization and messaging format \cite{XXX} Besides being open, standardized, textual, and human-readable, JSON smoothly integrates into systems because it is straight-forward for computers to parse and use. With its increasing adoption, the need for structural constraints and validation possibilities led to birth of the JSON Schema standardization\footnote{\url{http://json-schema.org}}, a dedicated language to define the structure of JSON documents. The main goal is providing users with a simple language to define constrains on JSON documents and make available tools for checking their conformance with the corresponding schema. \cite{pezoa_foundations_2016}
|
||||
|
||||
*\textit{Motivation for this dataset.}
|
||||
|
||||
The motivations underlying the needs for datasets of reusable JSON schemas are manifold. First of all, while JSON is frequently used nowadays, the JSON Schema language is still relatively new and still under development. As previous studies about other meta-languages revealed (such as XML Schema~\cite{\luca{todo}}), the usage of particular language concepts can vary drastically. This has been already acknowledged for JSON schema in recent work~\cite{Maiwald2019}. Consequently, the availability of reusable JSON schema specifications can represent a precious know-how to be conveyed to new users that might avoid to start from scratch. By analyzing available datasets, it is possible to understand the current state of practice of using JSON schemas as well as to stimulate
|
||||
further research on this data format such as to conceive smart validation checks, to develop quality models and corresponding metrics, and define guidelines on how to properly structure a JSON schema. Last but not least, the availability of JSON schema datasets is mandatory to foster the application of machine learning algorithms that need to be trained for instance to develop recommendation systems, or to support the automated organization and retrieval of JSON schemas with respect to the application domains of interest.
|
||||
|
||||
|
||||
|
||||
%\textit{Contribution.}
|
||||
|
||||
This paper presents a tool-supported method for mining, processing, and performing unsupervised classifications\juri{we skipped the classification at this round} of a dataset of more than 19.000 unique JSON Schema documents conforming to the latest JSON Schema standards or \ins{\textit{meta-schema}} (up to Draft 7). \manuel{maybe we should say from where we have taken the data?} Different metrics permit access to relevant schema information and obtain insight into the dataset's general characteristics. \manuel{why is this important? For future research topics?} Finally, it also allows to reason about the current usage of the JSON Schema language which may give further insights for further standardization efforts.
|
||||
|
||||
\textit{Contribution.} This paper presents a tool-supported method for mining, validating, and calculating metrics of a dataset of more than 19.000 unique JSON Schema documents collected from a GitHub archive dataset, conforming to the latest JSON Schema standards or \ins{\textit{meta-schema}} (up to Draft 7).
|
||||
|
||||
|
||||
%\luca{contribution}
|
||||
|
||||
%\luca{@juri I would rather shift the focus/value on the dataset first and then on the great tool support.}
|
||||
...
|
||||
%To improve this situation, we propose \toolname, a toolkit to retrieve and analyze JSON schemata.
|
||||
%By applying the \toolname tool-chain presented in the next sections, the resulting dataset is the largest collection of unique and valid JSON schemata consisting of more than 15,000 artifacts.
|
||||
|
||||
\textit{Structure.} In the following, we present the used methodology, i.e., the process of data extraction, data preprocessing, and calculation of the meta-information for the extracted dataset, the employed data structure and offered tool support, a list of research questions may be answered with our dataset in the future, and a discussion of related work followed by a conclusion.
|
||||
|
||||
The paper is structured as follows. Section~\ref{sec:methodology} outlines the data mining activities, which includes data extraction, data preprocessing and metrics calculations. Section~\ref{sec:data-structure-tool} introduces the data structure of our dataset and the support tool \toolname{}.
|
||||
%outlines possible research activities and challenges that can benefit from the availability of our JSON Schema dataset.
|
||||
Section~\ref{sec:related} collects related work and Section~\ref{sec:conclusions} concludes the paper.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The definition of JSON Schema documents is still part of bespoke processes and the reuse of already specified artifacts is not yet common mainly because of the lack of reusable datasets.
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
tags:
|
||||
|
||||
- '#conferences'
|
||||
- '#papersubmission'
|
||||
- '#deadlines'
|
||||
- '#paper/msr11'
|
||||
- '#re'
|
||||
---
|
||||
# MSR20201
|
||||
## Sources
|
||||
|
||||
URL: [MSR 2021 (researchr.org)](https://conf.researchr.org/home/msr-2021)
|
||||
CFP: [MSR 2021 - Technical Papers - MSR 2021 (msrconf.org)](https://2021.msrconf.org/track/msr-2021-technical-papers#Call-for-Papers)
|
||||
## Important dates
|
||||
- Tue 5 Jan 2021 Abstract Submission
|
||||
- Tue 12 Jan 2021 Full Paper Submission
|
||||
- Wed 10 Feb - Fri 12 Feb 2021 Authors Response
|
||||
- Mon 22 Feb 2021 Notification
|
||||
- Mon 22 Mar 2021 Camera-Ready
|
||||
## Working notes during the revision
|
||||
- [ ] Check if the concept of upgrade plan is clear. Here we do not want to manage the actual migration (Sec 3)
|
||||
- [ ] Check if the problem about which library is used to trigger the process is relevant
|
||||
- [x] Menzionare GitHub dependency bot in the introduction
|
||||
- Il processo da presentare e'
|
||||
- I see the process as follows:
|
||||
1. Identification of vulnerable library
|
||||
2. Identification of the target version for the library in 1)
|
||||
3. Identification of the target versions for other used libraries that need to be upgraded because of the upgrade in 2)
|
||||
- Doubts:
|
||||
- To recommend single library upgrades I need a lot of data. Maybe it's too late when I'll be able to provide recommendations!!!
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
|
||||
librarySelection[Identification of the library to be updated] --> libraryVersion
|
||||
libraryVersion[Identification of the target version] -->setVersion
|
||||
setVersion[Update plan for all the involved libraries]
|
||||
|
||||
```
|
||||
### Some motivations
|
||||
|
||||
Nel paper
|
||||
|
||||
> R. G. Kula, D. M. German, A. Ouni, T. Ishio, e K. Inoue, «Do developers update their library dependencies?: An empirical study on the impact of security advisories on library migration», _Empir Software Eng_, vol. 23, n. 1, pagg. 384–417, feb. 2018, doi: [10.1007/s10664-017-9521-5](https://doi.org/10.1007/s10664-017-9521-5).
|
||||
> @article{kulaDevelopersUpdateTheir2018,
|
||||
|
||||
title = {Do Developers Update Their Library Dependencies?: {{An}} Empirical Study on the Impact of Security Advisories on Library Migration},
|
||||
shorttitle = {Do Developers Update Their Library Dependencies?},
|
||||
author = {Kula, Raula Gaikovina and German, Daniel M. and Ouni, Ali and Ishio, Takashi and Inoue, Katsuro},
|
||||
year = {2018},
|
||||
month = feb,
|
||||
volume = {23},
|
||||
pages = {384--417},
|
||||
issn = {1382-3256, 1573-7616},
|
||||
doi = {10.1007/s10664-017-9521-5},
|
||||
annotation = {00001},
|
||||
journal = {Empirical Software Engineering},
|
||||
language = {en},
|
||||
number = {1}
|
||||
}
|
||||
|
||||
Si dice:
|
||||
- although system heavily depend on libraries, most systems rarely update their libraries and systems are less likely migrate their library dependencies, with 81.5% of systems remaining with a popular older versions.
|
||||
- Moreover there exist patterns where an older popular library version is still preferred even in case of a security advisory disclosure. They find developers are less likely to update a library that requires more migration effort and vice-versa.
|
||||
- Developers evaluate the decision whether or not to update dependencies based on project specific priorities. Developers cite migration as a practice that requires extra migration effort and added responsibility.
|
||||
Reference in New Issue
Block a user