Initial import from AFP.

This commit is contained in:
Achim D. Brucker 2020-12-19 11:09:06 +00:00
commit 0e803ffaf3
8 changed files with 4853 additions and 0 deletions

File diff suppressed because it is too large Load Diff

14
DOM_Components/ROOT Normal file
View File

@ -0,0 +1,14 @@
chapter AFP
session "DOM_Components" (AFP) = "Shadow_DOM" +
options [timeout = 3600]
directories
counterexample
theories
Core_DOM_Components
Shadow_DOM_Components
fancy_tabs
document_files
"root.tex"
"root.bib"
"fancytabs-normal.jpg"

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,40 @@
<!DOCTYPE html>
<html>
<head>
<title>Global News</title>
</head>
<body>
<h1>Global News</h1>
<button>Search</button>
<button>Sign In</button>
<br>
<br>
<fancy-tabs background>
<template data-mode="open">
<style>---shortened---</style>
<div id="tabs">
<slot id="tabsSlot" name="title"></slot>
</div>
<div id="panels">
<slot id="panelsSlot"></slot>
</div>
<button>Previous Tab</button>
<button style="float:right">Next Tab</button>
</template>
<button slot="title">Politics</button>
<button slot="title" selected>Sports</button>
<button slot="title">Culture</button>
<section>content panel 1</section>
<ul>
<li>News Item 1 <button>Share</button></li>
<li>News Item 2 <button>Share</button></li>
<li>News Item 3 <button>Share</button></li>
</ul>
<section>content panel 3</section>
</fancy-tabs>
<script></script>
</body>
</html>

View File

@ -0,0 +1,96 @@
(***********************************************************************************
* Copyright (c) 2016-2020 The University of Sheffield, UK
* 2019-2020 University of Exeter, UK
*
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* * Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* * Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* SPDX-License-Identifier: BSD-2-Clause
***********************************************************************************)
(* This file is automatically generated, please do not modify! *)
section\<open>Testing fancy\_tabs\<close>
text\<open>This theory contains the test cases for fancy\_tabs.\<close>
theory fancy_tabs
imports
"Shadow_DOM.Shadow_DOM"
begin
definition fancy_tabs_heap :: "heap\<^sub>f\<^sub>i\<^sub>n\<^sub>a\<^sub>l" where
"fancy_tabs_heap = create_heap [(cast (document_ptr.Ref 1), cast (create_document_obj html (Some (cast (element_ptr.Ref 1))) [])),
(cast (element_ptr.Ref 1), cast (create_element_obj ''html'' [cast (element_ptr.Ref 2), cast (element_ptr.Ref 4)] fmempty None)),
(cast (element_ptr.Ref 2), cast (create_element_obj ''head'' [cast (element_ptr.Ref 3)] fmempty None)),
(cast (element_ptr.Ref 3), cast (create_element_obj ''title'' [cast (character_data_ptr.Ref 1)] fmempty None)),
(cast (character_data_ptr.Ref 1), cast (create_character_data_obj ''Global%20News'')),
(cast (element_ptr.Ref 4), cast (create_element_obj ''body'' [cast (element_ptr.Ref 5), cast (element_ptr.Ref 6), cast (element_ptr.Ref 7), cast (element_ptr.Ref 8), cast (element_ptr.Ref 9), cast (element_ptr.Ref 10), cast (element_ptr.Ref 30)] fmempty None)),
(cast (element_ptr.Ref 5), cast (create_element_obj ''h1'' [cast (character_data_ptr.Ref 2)] fmempty None)),
(cast (character_data_ptr.Ref 2), cast (create_character_data_obj ''Global%20News'')),
(cast (element_ptr.Ref 6), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 3)] fmempty None)),
(cast (character_data_ptr.Ref 3), cast (create_character_data_obj ''Search'')),
(cast (element_ptr.Ref 7), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 4)] fmempty None)),
(cast (character_data_ptr.Ref 4), cast (create_character_data_obj ''Sign%20In'')),
(cast (element_ptr.Ref 8), cast (create_element_obj ''br'' [] fmempty None)),
(cast (element_ptr.Ref 9), cast (create_element_obj ''br'' [] fmempty None)),
(cast (element_ptr.Ref 10), cast (create_element_obj ''fancy-tabs'' [cast (element_ptr.Ref 11), cast (element_ptr.Ref 12), cast (element_ptr.Ref 13), cast (element_ptr.Ref 14), cast (element_ptr.Ref 15), cast (element_ptr.Ref 22)] (fmap_of_list [(''background'', '''')]) (Some (cast (shadow_root_ptr.Ref 1))))),
(cast (element_ptr.Ref 11), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 5)] (fmap_of_list [(''slot'', ''title'')]) None)),
(cast (character_data_ptr.Ref 5), cast (create_character_data_obj ''Politics'')),
(cast (element_ptr.Ref 12), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 6)] (fmap_of_list [(''slot'', ''title''), (''selected'', '''')]) None)),
(cast (character_data_ptr.Ref 6), cast (create_character_data_obj ''Sports'')),
(cast (element_ptr.Ref 13), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 7)] (fmap_of_list [(''slot'', ''title'')]) None)),
(cast (character_data_ptr.Ref 7), cast (create_character_data_obj ''Culture'')),
(cast (element_ptr.Ref 14), cast (create_element_obj ''section'' [cast (character_data_ptr.Ref 8)] fmempty None)),
(cast (character_data_ptr.Ref 8), cast (create_character_data_obj ''content%20panel%201'')),
(cast (element_ptr.Ref 15), cast (create_element_obj ''ul'' [cast (element_ptr.Ref 16), cast (element_ptr.Ref 18), cast (element_ptr.Ref 20)] fmempty None)),
(cast (element_ptr.Ref 16), cast (create_element_obj ''li'' [cast (character_data_ptr.Ref 9), cast (element_ptr.Ref 17)] fmempty None)),
(cast (character_data_ptr.Ref 9), cast (create_character_data_obj ''News%20Item%201'')),
(cast (element_ptr.Ref 17), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 10)] fmempty None)),
(cast (character_data_ptr.Ref 10), cast (create_character_data_obj ''Share'')),
(cast (element_ptr.Ref 18), cast (create_element_obj ''li'' [cast (character_data_ptr.Ref 11), cast (element_ptr.Ref 19)] fmempty None)),
(cast (character_data_ptr.Ref 11), cast (create_character_data_obj ''News%20Item%202'')),
(cast (element_ptr.Ref 19), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 12)] fmempty None)),
(cast (character_data_ptr.Ref 12), cast (create_character_data_obj ''Share'')),
(cast (element_ptr.Ref 20), cast (create_element_obj ''li'' [cast (character_data_ptr.Ref 13), cast (element_ptr.Ref 21)] fmempty None)),
(cast (character_data_ptr.Ref 13), cast (create_character_data_obj ''News%20Item%203'')),
(cast (element_ptr.Ref 21), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 14)] fmempty None)),
(cast (character_data_ptr.Ref 14), cast (create_character_data_obj ''Share'')),
(cast (element_ptr.Ref 22), cast (create_element_obj ''section'' [cast (character_data_ptr.Ref 15)] fmempty None)),
(cast (character_data_ptr.Ref 15), cast (create_character_data_obj ''content%20panel%203'')),
(cast (shadow_root_ptr.Ref 1), cast (create_shadow_root_obj Open [cast (element_ptr.Ref 23), cast (element_ptr.Ref 24), cast (element_ptr.Ref 26), cast (element_ptr.Ref 28), cast (element_ptr.Ref 29)])),
(cast (element_ptr.Ref 23), cast (create_element_obj ''style'' [cast (character_data_ptr.Ref 16)] fmempty None)),
(cast (character_data_ptr.Ref 16), cast (create_character_data_obj ''---shortened---'')),
(cast (element_ptr.Ref 24), cast (create_element_obj ''div'' [cast (element_ptr.Ref 25)] (fmap_of_list [(''id'', ''tabs'')]) None)),
(cast (element_ptr.Ref 25), cast (create_element_obj ''slot'' [] (fmap_of_list [(''id'', ''tabsSlot''), (''name'', ''title'')]) None)),
(cast (element_ptr.Ref 26), cast (create_element_obj ''div'' [cast (element_ptr.Ref 27)] (fmap_of_list [(''id'', ''panels'')]) None)),
(cast (element_ptr.Ref 27), cast (create_element_obj ''slot'' [] (fmap_of_list [(''id'', ''panelsSlot'')]) None)),
(cast (element_ptr.Ref 28), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 17)] fmempty None)),
(cast (character_data_ptr.Ref 17), cast (create_character_data_obj ''Previous%20Tab'')),
(cast (element_ptr.Ref 29), cast (create_element_obj ''button'' [cast (character_data_ptr.Ref 18)] (fmap_of_list [(''style'', ''float:right'')]) None)),
(cast (character_data_ptr.Ref 18), cast (create_character_data_obj ''Next%20Tab'')),
(cast (element_ptr.Ref 30), cast (create_element_obj ''script'' [] fmempty None))]"
definition fancy_tabs_document :: "(unit, unit, unit, unit, unit, unit) object_ptr option" where "fancy_tabs_document = Some (cast (document_ptr.Ref 1))"
end

Binary file not shown.

After

Width:  |  Height:  |  Size: 33 KiB

View File

@ -0,0 +1,747 @@
@STRING{j-fac = "Formal Aspects of Computing" }
@STRING{pub-springer={Springer-Verlag} }
@STRING{pub-springer:adr={Heidelberg} }
@STRING{s-lncs = "Lecture Notes in Computer Science" }
@Book{ nipkow.ea:isabelle:2002,
author = {Tobias Nipkow and Lawrence C. Paulson and Markus Wenzel},
title = {Isabelle/HOL---A Proof Assistant for Higher-Order Logic},
publisher = pub-springer,
address = pub-springer:adr,
series = s-lncs,
volume = 2283,
doi = {10.1007/3-540-45949-9},
abstract = {This book is a self-contained introduction to interactive
proof in higher-order logic (HOL), using the proof
assistant Isabelle2002. It is a tutorial for potential
users rather than a monograph for researchers. The book has
three parts.
1. Elementary Techniques shows how to model functional
programs in higher-order logic. Early examples involve
lists and the natural numbers. Most proofs are two steps
long, consisting of induction on a chosen variable followed
by the auto tactic. But even this elementary part covers
such advanced topics as nested and mutual recursion. 2.
Logic and Sets presents a collection of lower-level tactics
that you can use to apply rules selectively. It also
describes Isabelle/HOL's treatment of sets, functions and
relations and explains how to define sets inductively. One
of the examples concerns the theory of model checking, and
another is drawn from a classic textbook on formal
languages. 3. Advanced Material describes a variety of
other topics. Among these are the real numbers, records and
overloading. Advanced techniques are described involving
induction and recursion. A whole chapter is devoted to an
extended example: the verification of a security protocol.
},
year = 2002,
acknowledgement={brucker, 2007-02-19},
bibkey = {nipkow.ea:isabelle:2002}
}
@Misc{ dom-specification,
year = 2016,
month = {DOM Living Standard -- Last Updated 20 October 2016},
day = 20,
url = {https://dom.spec.whatwg.org/},
organization = {Web Hypertext Application Technology Working Group
(WHATWG)},
note = {An archived copy of the version from 20 October 2016 is
available at
\url{https://git.logicalhacking.com/BrowserSecurity/fDOM-idl/}.}
}
@InProceedings{ brucker.ea:core-dom:2018,
author = {Achim D. Brucker and Michael Herzberg},
title = {A Formal Semantics of the Core {DOM} in {Isabelle/HOL}},
booktitle = {Proceedings of the Web Programming, Design, Analysis, And
Implementation (WPDAI) track at WWW 2018},
location = {Lyon, France},
url = {https://www.brucker.ch/bibliography/abstract/brucker.ea-fdom-2018},
year = {2018},
abstract = {At its core, the Document Object Model (DOM) defines a
tree-like data structure for representing documents in
general and HTML documents in particular. It forms the
heart of any rendering engine of modern web browsers.
Formalizing the key concepts of the DOM is a pre-requisite
for the formal reasoning over client-side JavaScript
programs as well as for the analysis of security concepts
in modern web browsers. In this paper, we present a
formalization of the core DOM, with focus on the node-tree
and the operations defined on node-trees, in Isabelle/HOL.
We use the formalization to verify the functional
correctness of the most important functions defined in the
DOM standard. Moreover, our formalization is (1)
extensible, i.e., can be extended without the need of
re-proving already proven properties and (2) executable,
i.e., we can generate executable code from our
specification. },
keywords = {Document Object Model, DOM, Formal Semantics,
Isabelle/HOL},
classification= {conference},
areas = {formal methods, software},
public = {yes}
}
@Article{ klein:operating:2009,
author = {Gerwin Klein},
title = {Operating System Verification --- An Overview},
journal = {S\={a}dhan\={a}},
publisher = pub-springer,
year = 2009,
volume = 34,
number = 1,
month = feb,
pages = {27--69},
abstract = {This paper gives a high-level introduction to the topic of
formal, interactive, machine-checked software verification
in general, and the verification of operating systems code
in particular. We survey the state of the art, the
advantages and limitations of machine-checked code proofs,
and describe two specific ongoing larger-scale verification
projects in more detail.}
}
@InProceedings{ gardner.ea:securing:2009,
author = {Ryan W. Gardner and Sujata Garera and Matthew W. Pagano
and Matthew Green and Aviel D. Rubin},
title = {Securing medical records on smart phones},
booktitle = {ACM workshop on Security and privacy in medical and
home-care systems (SPIMACS)},
year = 2009,
isbn = {978-1-60558-790-5},
pages = {31--40},
location = {Chicago, Illinois, USA},
doi = {10.1145/1655084.1655090},
address = pub-acm:adr,
publisher = pub-acm,
abstract = {There is an inherent conflict between the desire to
maintain privacy of one's medical records and the need to
make those records available during an emergency. To
satisfy both objectives, we introduce a flexible
architecture for the secure storage of medical records on
smart phones. In our system, a person can view her records
at any time, and emergency medical personnel can view the
records as long as the person is present (even if she is
unconscious). Our solution allows for efficient revocation
of access rights and is robust against adversaries who can
access the phone's storage offline.}
}
@InProceedings{ raad.ea:dom:2016,
author = {Azalea Raad and Jos{\'{e}} Fragoso Santos and Philippa
Gardner},
title = {{DOM:} Specification and Client Reasoning},
booktitle = {Programming Languages and Systems - 14th Asian Symposium,
{APLAS} 2016, Hanoi, Vietnam, November 21-23, 2016,
Proceedings},
pages = {401--422},
year = 2016,
crossref = {igarashi:programming:2016},
doi = {10.1007/978-3-319-47958-3_21},
abstract = {We present an axiomatic specification of a key fragment of
DOM using structural separation logic. This specification
allows us to develop modular reasoning about client
programs that call the DOM.}
}
@InProceedings{ bohannon.ea:featherweight:2010,
author = {Aaron Bohannon and Benjamin C. Pierce},
title = {Featherweight {F}irefox: {F}ormalizing the Core of a Web
Browser},
booktitle = {Usenix Conference on Web Application Development
(WebApps)},
year = 2010,
month = jun,
url = {http://www.cis.upenn.edu/~bohannon/browser-model/},
abstract = {We offer a formal specification of the core functionality
of a web browser in the form of a small-step operational
semantics. The specification accurately models the asyn-
chronous nature of web browsers and covers the basic as-
pects of windows, DOM trees, cookies, HTTP requests and
responses, user input, and a minimal scripting lan- guage
with first-class functions, dynamic evaluation, and AJAX
requests. No security enforcement mechanisms are
included{\^a}instead, the model is intended to serve as a
basis for formalizing and experimenting with different
security policies and mechanisms. We survey the most
interesting design choices and discuss how our model re-
lates to real web browsers.}
}
@Proceedings{ joyce.ea:higher:1994,
editor = {Jeffrey J. Joyce and Carl-Johan H. Seger},
title = {Higher Order Logic Theorem Proving and Its Applications
(HUG)},
booktitle = {Higher Order Logic Theorem Proving and Its Applications
(HUG)},
publisher = pub-springer,
address = pub-springer:adr,
series = s-lncs,
abstract = {Theorem proving based techniques for formal hardware
verification have been evolving constantly and researchers
are getting able to reason about more complex issues than
it was possible or practically feasible in the past. It is
often the case that a model of a system is built in a
formal logic and then reasoning about this model is carried
out in the logic. Concern is growing on how to consistently
interface a model built in a formal logic with an informal
CAD environment. Researchers have been investigating how to
define the formal semantics of hardware description
languages so that one can formally reason about models
informally dealt with in a CAD environment. At the
University of Cambridge, the embedding of hardware
description languages in a logic is classified in two
categories: deep embedding and shallow embedding. In this
paper we argue that there are degrees of formality in
shallow embedding a language in a logic. The choice of the
degree of formality is a trade-off between the security of
the embedding and the amount and complexity of the proof
effort in the logic. We also argue that the design of a
language could consider this verifiability issue. There are
choices in the design of a language that can make it easier
to improve the degree of formality, without implying
serious drawbacks for the CAD environment.},
volume = 780,
year = 1994,
doi = {10.1007/3-540-57826-9},
isbn = {3-540-57826-9},
acknowledgement={brucker, 2007-02-19}
}
@Misc{ whatwg:dom:2017,
key={whatwg},
author={{WHATWG}},
url={https://dom.spec.whatwg.org/commit-snapshots/6253e53af2fbfaa6d25ad09fd54280d8083b2a97/},
month=mar,
year=2017,
day=24,
title={{DOM} -- Living Standard},
note={Last Updated 24 {March} 2017},
institution = {WHATWG},
}
@Misc{ whatwg:html:2017,
key={whatwg},
author={{WHATWG}},
url={https://html.spec.whatwg.org/},
month=apr,
year=2017,
day=13,
title={{HTML} -- Living Standard},
note={Last Updated 13 {April} 2017},
institution = {WHATWG},
}
@Misc{ w3c:dom:2015,
key={w3c},
author={{W3C}},
url={https://www.w3.org/TR/dom/},
month=nov,
year=2015,
day=19,
title={{W3C} {DOM4}},
institution = {W3C},
}
@Proceedings{ igarashi:programming:2016,
editor = {Atsushi Igarashi},
title = {Programming Languages and Systems - 14th Asian Symposium,
{APLAS} 2016, Hanoi, Vietnam, November 21-23, 2016,
Proceedings},
series = {Lecture Notes in Computer Science},
volume = 10017,
year = 2016,
doi = {10.1007/978-3-319-47958-3},
isbn = {978-3-319-47957-6}
}
@InProceedings{ gardner.ea:dom:2008,
author = {Philippa Gardner and Gareth Smith and Mark J. Wheelhouse
and Uri Zarfaty},
title = {{DOM:} Towards a Formal Specification},
booktitle = {{PLAN-X} 2008, Programming Language Technologies for XML,
An {ACM} {SIGPLAN} Workshop colocated with {POPL} 2008, San
Francisco, California, USA, January 9, 2008},
year = 2008,
crossref = {plan-x:2008},
url = {http://gemo.futurs.inria.fr/events/PLANX2008/papers/p18.pdf},
abstract = {The W3C Document Object Model (DOM) specifies an XML up-
date library. DOM is written in English, and is therefore
not compo- sitional and not complete. We provide a first
step towards a compo- sitional specification of DOM. Unlike
DOM, we are able to work with a minimal set of commands and
obtain a complete reason- ing for straight-line code. Our
work transfers O{\^a}Hearn, Reynolds and Yang{\^a}s
local Hoare reasoning for analysing heaps to XML, viewing
XML as an in-place memory store as does DOM. In par-
ticular, we apply recent work by Calcagno, Gardner and
Zarfaty on local Hoare reasoning about a simple tree-update
language to DOM, showing that our reasoning scales to DOM.
Our reasoning not only formally specifies a significant
subset of DOM Core Level 1, but can also be used to verify
e.g. invariant properties of simple Javascript programs.}
}
@InProceedings{ jang.ea:establishing:2012,
author = {Dongseok Jang and Zachary Tatlock and Sorin Lerner},
title = {Establishing Browser Security Guarantees through Formal
Shim Verification},
booktitle = {Proceedings of the 21th {USENIX} Security Symposium,
Bellevue, WA, USA, August 8-10, 2012},
pages = {113--128},
year = 2012,
crossref = {kohno:proceedings:2012},
url = {https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/jang},
abstract = { Web browsers mediate access to valuable private data in
domains ranging from health care to banking. Despite this
critical role, attackers routinely exploit browser
vulnerabilities to exfiltrate private data and take over
the un- derlying system. We present Q UARK , a browser
whose kernel has been implemented and verified in Coq. We
give a specification of our kernel, show that the
implementation satisfies the specification, and finally
show that the specification implies several security
properties, including tab non-interference, cookie
integrity and confidentiality, and address bar integrity.
}
}
@Proceedings{ kohno:proceedings:2012,
editor = {Tadayoshi Kohno},
title = {Proceedings of the 21th {USENIX} Security Symposium,
Bellevue, WA, USA, August 8-10, 2012},
publisher = {{USENIX} Association},
year = 2012,
timestamp = {Thu, 15 May 2014 09:12:27 +0200}
}
@Proceedings{ plan-x:2008,
title = {{PLAN-X} 2008, Programming Language Technologies for XML,
An {ACM} {SIGPLAN} Workshop colocated with {POPL} 2008, San
Francisco, California, USA, January 9, 2008},
year = 2008,
timestamp = {Fri, 18 Jan 2008 13:01:04 +0100}
}
@Article{ brucker.ea:extensible:2008-b,
abstract = {We present an extensible encoding of object-oriented data models into HOL. Our encoding is supported by a datatype package that leverages the use of the shallow embedding technique to object-oriented specification and programming languages. The package incrementally compiles an object-oriented data model, i.e., a class model, to a theory containing object-universes, constructors, accessor functions, coercions (casts) between dynamic and static types, characteristic sets, and co-inductive class invariants. The package is conservative, i.e., all properties are derived entirely from constant definitions, including the constraints over object structures. As an application, we use the package for an object-oriented core-language called IMP++, for which we formally prove the correctness of a Hoare-Logic with respect to a denotational semantics.},
address = {Heidelberg},
author = {Achim D. Brucker and Burkhart Wolff},
doi = {10.1007/s10817-008-9108-3},
issn = {0168-7433},
issue = {3},
journal = {Journal of Automated Reasoning},
keywords = {object-oriented data models, HOL, theorem proving, verification},
language = {USenglish},
pages = {219--249},
pdf = {https://www.brucker.ch/bibliography/download/2008/brucker.ea-extensible-2008-b.pdf},
publisher = {Springer-Verlag},
title = {An Extensible Encoding of Object-oriented Data Models in HOL},
url = {https://www.brucker.ch/bibliography/abstract/brucker.ea-extensible-2008-b},
volume = {41},
year = {2008},
}
@PhDThesis{ brucker:interactive:2007,
abstract = {We present a semantic framework for object-oriented specification languages. We develop this framework as a conservative shallow embedding in Isabelle/HOL. Using only conservative extensions guarantees by construction the consistency of our formalization. Moreover, we show how our framework can be used to build an interactive proof environment, called HOL-OCL, for object-oriented specifications in general and for UML/OCL in particular.\\\\Our main contributions are an extensible encoding of object-oriented data structures in HOL, a datatype package for object-oriented specifications, and the development of several equational and tableaux calculi for object-oriented specifications. Further, we show that our formal framework can be the basis of a formal machine-checked semantics for OCL that is compliant to the OCL 2.0 standard.},
abstract_de = {In dieser Arbeit wird ein semantisches Rahmenwerk f{\"u}r objektorientierte Spezifikationen vorgestellt. Das Rahmenwerk ist als konservative, flache Einbettung in Isabelle/HOL realisiert. Durch die Beschr{\"a}nkung auf konservative Erweiterungen kann die logische Konsistenz der Einbettung garantiert werden. Das semantische Rahmenwerk wird verwendet, um das interaktives Beweissystem HOL-OCL f{\"u}r objektorientierte Spezifikationen im Allgemeinen und insbesondere f{\"u}r UML/OCL zu entwickeln.\\\\Die Hauptbeitr{\"a}ge dieser Arbeit sind die Entwicklung einer erweiterbaren Kodierung objektorientierter Datenstrukturen in HOL, ein Datentyp-Paket f{\"u}r objektorientierte Spezifikationen und die Entwicklung verschiedener Kalk{\"u}le f{\"u}r objektorientierte Spezifikationen. Zudem zeigen wir, wie das formale Rahmenwerk verwendet werden kann, um eine formale, maschinell gepr{\"u}fte Semantik f{\"u}r OCL anzugeben, die konform zum Standard f{\"u}r OCL 2.0 ist.},
author = {Achim D. Brucker},
keywords = {OCL, UML, formal semantics, theorem proving, Isabelle, HOL-OCL},
month = {mar},
note = {ETH Dissertation No. 17097.},
pdf = {https://www.brucker.ch/bibliography/download/2007/brucker-interactive-2007.pdf},
school = {ETH Zurich},
title = {An Interactive Proof Environment for Object-oriented Specifications},
url = {https://www.brucker.ch/bibliography/abstract/brucker-interactive-2007},
year = {2007},
}
@InCollection{ brucker.ea:standard-compliance-testing:2018,
talk = {talk:brucker.ea:standard-compliance-testing:2018},
abstract = {Most popular technologies are based on informal or
semiformal standards that lack a rigid formal semantics.
Typical examples include web technologies such as the DOM
or HTML, which are defined by the Web Hypertext Application
Technology Working Group (WHATWG) and the World Wide Web
Consortium (W3C). While there might be API specifications
and test cases meant to assert the compliance of a certain
implementation, the actual standard is rarely accompanied
by a formal model that would lend itself for, e.g.,
verifying the security or safety properties of real
systems.
Even when such a formalization of a standard exists, two
important questions arise: first, to what extend does the
formal model comply to the standard and, second, to what
extend does the implementation comply to the formal model
and the assumptions made during the verification? In this
paper, we present an approach that brings all three
involved artifacts - the (semi-)formal standard, the
formalization of the standard, and the implementations -
closer together by combining verification, symbolic
execution, and specification based testing.},
keywords = {standard compliance, compliance tests, DOM},
location = {Toulouse, France},
author = {Achim D. Brucker and Michael Herzberg},
booktitle = {{TAP} 2018: Tests And Proofs},
language = {USenglish},
publisher = pub-springer,
address = pub-springer:adr,
series = s-lncs,
number = 10889,
editor = {Cathrine Dubois and Burkhart Wolff},
title = {Formalizing (Web) Standards: An Application of Test and
Proof},
categories = {holtestgen, websecurity},
classification= {conference},
areas = {formal methods, software engineering},
public = {yes},
year = 2018,
doi = {10.1007/978-3-319-92994-1_9},
pages = {159--166},
isbn = {978-3-642-38915-3},
pdf = {http://www.brucker.ch/bibliography/download/2018/brucker.ea-standard-compliance-testing-2018.pdf},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-standard-compliance-testing-2018}
}
@InCollection{ brucker.ea:interactive:2005,
keywords = {symbolic test case generations, black box testing, white
box testing, theorem proving, interactive testing},
abstract = {HOL-TestGen is a test environment for specification-based
unit testing build upon the proof assistant Isabelle/HOL\@.
While there is considerable skepticism with regard to
interactive theorem provers in testing communities, we
argue that they are a natural choice for (automated)
symbolic computations underlying systematic tests. This
holds in particular for the development on non-trivial
formal test plans of complex software, where some parts of
the overall activity require inherently guidance by a test
engineer. In this paper, we present the underlying methods
for both black box and white box testing in interactive
unit test scenarios. HOL-TestGen can also be understood as
a unifying technical and conceptual framework for
presenting and investigating the variety of unit test
techniques in a logically consistent way. },
location = {Edinburgh},
author = {Achim D. Brucker and Burkhart Wolff},
booktitle = {Formal Approaches to Testing of Software},
language = {USenglish},
publisher = pub-springer,
address = pub-springer:adr,
series = s-lncs,
number = 3997,
doi = {10.1007/11759744_7},
isbn = {3-540-25109-X},
editor = {Wolfgang Grieskamp and Carsten Weise},
pdf = {http://www.brucker.ch/bibliography/download/2005/brucker.ea-interactive-2005.pdf},
project = {CSFMDOS},
title = {Interactive Testing using {HOL}-{TestGen}},
classification= {workshop},
areas = {formal methods, software},
categories = {holtestgen},
year = 2005,
public = {yes},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-interactive-2005}
}
@Article{ brucker.ea:theorem-prover:2012,
author = {Achim D. Brucker and Burkhart Wolff},
journal = j-fac,
publisher = pub-springer,
address = pub-springer:adr,
language = {USenglish},
categories = {holtestgen},
title = {On Theorem Prover-based Testing},
year = 2013,
issn = {0934-5043},
pages = {683--721},
volume = 25,
number = 5,
classification= {journal},
areas = {formal methods, software},
public = {yes},
doi = {10.1007/s00165-012-0222-y},
keywords = {test case generation, domain partitioning, test sequence,
theorem proving, HOL-TestGen},
abstract = {HOL-TestGen is a specification and test case generation
environment extending the interactive theorem prover
Isabelle/HOL. As such, HOL-TestGen allows for an integrated
workflow supporting interactive theorem proving, test case
generation, and test data generation.
The HOL-TestGen method is two-staged: first, the original
formula is partitioned into test cases by transformation
into a normal form called test theorem. Second, the test
cases are analyzed for ground instances (the test data)
satisfying the constraints of the test cases. Particular
emphasis is put on the control of explicit test-hypotheses
which can be proven over concrete programs.
Due to the generality of the underlying framework, our
system can be used for black-box unit, sequence, reactive
sequence and white-box test scenarios. Although based on
particularly clean theoretical foundations, the system can
be applied for substantial case-studies. },
pdf = {http://www.brucker.ch/bibliography/download/2012/brucker.ea-theorem-prover-2012.pdf},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-theorem-prover-2012}
}
@Article{ brucker.ea:afp-core-dom:2018,
abstract = {In this AFP entry, we formalize the core of the Document Object Model (DOM). At its core, the DOM defines a tree-like data structure for representing documents in general and HTML documents in particular. It is the heart of any modern web browser. Formalizing the key concepts of the DOM is a prerequisite for the formal reasoning over client-side JavaScript programs and for the analysis of security concepts in modern web browsers. We present a formalization of the core DOM, with focus on the node-tree and the operations defined on node-trees, in Isabelle/HOL. We use the formalization to verify the functional correctness of the most important functions defined in the DOM standard. Moreover, our formalization is 1) extensible, i.e., can be extended without the need of re-proving already proven properties and 2) executable, i.e., we can generate executable code from our specification.},
author = {Achim D. Brucker and Michael Herzberg},
date = {2018-12-26},
file = {https://www.brucker.ch/bibliography/download/2018/brucker.ea-afp-core-dom-outline-2018.pdf},
filelabel = {Outline},
issn = {2150-914x},
journal = {Archive of Formal Proofs},
month = {dec},
note = {\url{http://www.isa-afp.org/entries/Core_DOM.html}, Formal proof development},
pdf = {https://www.brucker.ch/bibliography/download/2018/brucker.ea-afp-core-dom-2018.pdf},
title = {The Core {DOM}},
url = {https://www.brucker.ch/bibliography/abstract/brucker.ea-afp-core-dom-2018-a},
year = {2018},
}
@Misc{ whatwg:dom:2019,
key = {whatwg},
author = {{WHATWG}},
url = {https://dom.spec.whatwg.org/commit-snapshots/7fa83673430f767d329406d0aed901f296332216/},
month = feb,
year = 2019,
day = 11,
title = {{DOM} -- Living Standard},
note = {Last Updated 11 {February} 2019},
institution = {WHATWG}
}
@Misc{ bidelman:self-contained:2017,
author = {Eric Bidelman},
title = {Shadow DOM v1: Self-Contained Web Components},
month = may,
day = 12,
year = 2017,
url = {https://developers.google.com/web/fundamentals/getting-started/primers/shadowdom}
}
@Article{ brucker.ea:afp-shadow-sc-dom:2020,
author = {Achim D. Brucker and Michael Herzberg},
title = {Shadow SC DOM: A Formal Model of the Safelty Composable Document Object Model with Shadow Roots},
journal = {Archive of Formal Proofs},
month = sep,
year = 2020,
date = {2020-09-28},
note = {\url{http://www.isa-afp.org/entries/Shadow_SC_DOM.html}, Formal proof development},
issn = {2150-914x},
abstract = { In this AFP entry, we extend our formalization of the safely composable DOM with \emph{Shadow
Roots}. Shadow roots are a recent proposal of the web community to support a component-based
development approach for client-side web applications.
Shadow roots are a significant extension to the DOM standard and, as web standards are condemned to be
backward compatible, such extensions often result in complex specification that may contain unwanted
subtleties that can be detected by a formalization.
Our Isabelle/HOL formalization is, in the sense of object-orientation, an extension of our
formalization of the core DOM and enjoys the same basic properties, i.e., it is extensible, i.e., can
be extended without the need of re-proving already proven properties and executable, i.e., we can
generate executable code from our specification. We exploit the executability to show that our
formalization complies to the official standard of the W3C, respectively, the WHATWG. },
public = {yes},
classification= {formal},
categories = {websecurity},
pdf = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-shadow-sc-dom-2020.pdf},
filelabel = {Outline},
file = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-shadow-sc-dom-outline-2020.pdf},
areas = {formal methods, security, software engineering},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-afp-shadow-sc-dom-2020}
}
@Article{ brucker.ea:afp-dom-components:2020,
author = {Achim D. Brucker and Michael Herzberg},
title = {A Formalization of Web Components},
journal = {Archive of Formal Proofs},
month = sep,
year = 2020,
date = {2020-09-28},
note = {\url{http://www.isa-afp.org/entries/DOM_Components.html}, Formal proof development},
issn = {2150-914x},
public = {yes},
classification= {formal},
categories = {websecurity},
pdf = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-dom-components-2020.pdf},
filelabel = {Outline},
file = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-dom-components-outline-2020.pdf},
areas = {formal methods, security, software engineering},
abstract = { While the DOM with shadow trees provide the technical basis for defining web components, the DOM
standard neither defines the concept of web components nor specifies the safety properties that web
components should guarantee. Consequently, the standard also does not discuss how or even if the
methods for modifying the DOM respect component boundaries.
In AFP entry, we present a formally verified model of web components and define safety properties
which ensure that different web components can only interact with each other using well-defined
interfaces. Moreover, our verification of the application programming interface (API) of the DOM
revealed numerous invariants that implementations of the DOM API need to preserve to ensure the
integrity of components. },
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-afp-dom-components-2020}
}
@Article{ brucker.ea:afp-sc-dom-components:2020,
author = {Achim D. Brucker and Michael Herzberg},
title = {A Formalization of Safely Composable Web Components},
journal = {Archive of Formal Proofs},
month = sep,
year = 2020,
date = {2020-09-28},
note = {\url{http://www.isa-afp.org/entries/SC_DOM_Components.html}, Formal proof development},
issn = {2150-914x},
public = {yes},
classification= {formal},
categories = {websecurity},
pdf = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-sc-dom-components-2020.pdf},
filelabel = {Outline},
file = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-sc-dom-components-outline-2020.pdf},
areas = {formal methods, security, software engineering},
abstract = { While the (safely composable) DOM with shadow trees provide the technical basis for defining web
components, it does neither defines the concept of web components nor specifies the safety properties
that web components should guarantee. Consequently, the standard also does not discuss how or even if
the methods for modifying the DOM respect component boundaries. In AFP entry, we present a formally
verified model of safely composable web components and define safety properties which ensure that
different web components can only interact with each other using well-defined interfaces. Moreover,
our verification of the application programming interface (API) of the DOM revealed numerous
invariants that implementations of the DOM API need to preserve to ensure the integrity of components.
},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-afp-sc-dom-components-2020}
}
@Article{ brucker.ea:afp-core-sc-dom:2020,
author = {Achim D. Brucker and Michael Herzberg},
title = {The Safely Composable {DOM}},
journal = {Archive of Formal Proofs},
month = sep,
year = 2020,
date = {2020-09-28},
note = {\url{http://www.isa-afp.org/entries/Core_SC_DOM.html}, Formal proof development},
issn = {2150-914x},
abstract = { In this AFP entry, we formalize the core of the Safely Composable Document Object Model (SC DOM).
The SC DOM improve the standard DOM by strengthening the tree boundaries set by shadow roots: in the
SC DOM, the shadow root is a sub-class of the document class (instead of a base class).
This modifications also results in changes to some API methods (e.g., getOwnerDocument) to return the
nearest shadow root rather than the document root. As a result, many API methods that, when called on
a node inside a shadow tree, would previously ``break out'' and return or modify nodes that are
possibly outside the shadow tree, now stay within its boundaries. This change in behavior makes
programs that operate on shadow trees more predictable for the developer and allows them to make more
assumptions about other code accessing the DOM. },
public = {yes},
classification= {formal},
categories = {websecurity},
pdf = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-core-sc-dom-2020.pdf},
filelabel = {Outline},
file = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-core-sc-dom-outline-2020.pdf},
areas = {formal methods, security, software engineering},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-afp-core-sc-dom-2020}
}
@Article{ brucker.ea:afp-shadow-dom:2020,
author = {Achim D. Brucker and Michael Herzberg},
title = {Shadow DOM: A Formal Model of the Document Object Model with Shadow Roots},
journal = {Archive of Formal Proofs},
month = sep,
year = 2020,
date = {2020-09-28},
note = {\url{http://www.isa-afp.org/entries/Shadow_DOM.html}, Formal proof development},
issn = {2150-914x},
abstract = { In this AFP entry, we extend our formalization of the core DOM with \emph{Shadow Roots}. Shadow
roots are a recent proposal of the web community to support a component-based development approach for
client-side web applications.
Shadow roots are a significant extension to the DOM standard and, as web standards are condemned to be
backward compatible, such extensions often result in complex specification that may contain unwanted
subtleties that can be detected by a formalization.
Our Isabelle/HOL formalization is, in the sense of object-orientation, an extension of our
formalization of the core DOM and enjoys the same basic properties, i.e., it is extensible, i.e., can
be extended without the need of re-proving already proven properties and executable, i.e., we can
generate executable code from our specification. We exploit the executability to show that our
formalization complies to the official standard of the W3C, respectively, the WHATWG. },
public = {yes},
classification= {formal},
categories = {websecurity},
pdf = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-shadow-dom-2020.pdf},
filelabel = {Outline},
file = {http://www.brucker.ch/bibliography/download/2020/brucker.ea-afp-shadow-dom-outline-2020.pdf},
areas = {formal methods, security, software engineering},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-afp-shadow-dom-2020}
}
@InCollection{ brucker.ea:web-components:2019,
abstract = {The trend towards ever more complex client-side web applications is unstoppable. Compared to
traditional software development, client-side web development lacks a well-established component
model, i.e., a method for easily and safely reusing already developed functionality. To address this
issue, the web community started to adopt shadow trees as part of the Document Object Model (DOM):
shadow trees allow developers to "partition" a DOM instance into parts that should be safely
separated, e.g., code modifying one part should not, unintentionally, affect other parts of the DOM.
While shadow trees provide the technical basis for defining web components, the DOM standard neither
defines the concept of web components nor specifies the safety properties that web components should
guarantee. Consequently, the standard also does not discuss how or even if the methods for modifying
the DOM respect component boundaries. In this paper, we present a formally verified model of web
components and define safety properties which ensure that different web components can only interact
with each other using well-defined interfaces. Moreover, our verification of the application
programming interface (API) of the DOM revealed numerous invariants that implementations of the DOM
API need to preserve to ensure the integrity of components.},
keywords = {Web Component, Shadow Tree, DOM, Isabelle/HOL},
location = {Amsterdam, The Netherlands},
author = {Achim D. Brucker and Michael Herzberg},
booktitle = {Formal Aspects of Component Software (FACS)},
language = {USenglish},
publisher = pub-springer,
address = pub-springer:adr,
series = s-lncs,
number = 12018,
isbn = {3-540-25109-X},
doi = {10.1007/978-3-030-40914-2_3},
editor = {Sung-Shik Jongmans and Farhad Arbab},
pdf = {http://www.brucker.ch/bibliography/download/2019/brucker.ea-web-components-2019.pdf},
title = {A Formally Verified Model of Web Components},
classification= {conference},
areas = {formal methods, software},
year = 2020,
public = {yes},
url = {http://www.brucker.ch/bibliography/abstract/brucker.ea-web-components-2019}
}
@PhdThesis{herzberg:web-components:2020,
author = {Michael Herzberg},
title = {Formal Foundations for Provably Safe Web Components},
school = {The University of Sheffield},
year = {2020}
}

View File

@ -0,0 +1,238 @@
\documentclass[10pt,DIV16,a4paper,abstract=true,twoside=semi,openright]
{scrreprt}
\usepackage[USenglish]{babel}
\usepackage[numbers, sort&compress]{natbib}
\usepackage{isabelle,isabellesym}
\usepackage{booktabs}
\usepackage{paralist}
\usepackage{graphicx}
\usepackage{amssymb}
\usepackage{xspace}
\usepackage{xcolor}
\usepackage{listings}
\lstloadlanguages{HTML}
\usepackage[]{mathtools}
\usepackage[pdfpagelabels, pageanchor=false, plainpages=false]{hyperref}
\lstdefinestyle{html}{language=XML,
basicstyle=\ttfamily,
commentstyle=\itshape,
keywordstyle=\color{blue},
ndkeywordstyle=\color{blue},
}
\lstdefinestyle{displayhtml}{style=html,
floatplacement={tbp},
captionpos=b,
framexleftmargin=0pt,
basicstyle=\ttfamily\scriptsize,
backgroundcolor=\color{black!2},
frame=lines,
}
\lstnewenvironment{html}[1][]{\lstset{style=displayhtml, #1}}{}
\def\inlinehtml{\lstinline[style=html, columns=fullflexible]}
\newsavebox{\fstlst}
\newsavebox{\sndlst}
\usepackage[caption=false]{subfig}
\pagestyle{headings}
\isabellestyle{default}
\setcounter{tocdepth}{1}
\newcommand{\ie}{i.\,e.\xspace}
\newcommand{\eg}{e.\,g.\xspace}
\newcommand{\thy}{\isabellecontext}
\renewcommand{\isamarkupsection}[1]{%
\begingroup%
\def\isacharunderscore{\textunderscore}%
\section{#1 (\thy)}%
\endgroup%
}
\title{A Formalization of Web Components}
\author{Achim~D.~Brucker \and Michael~Herzberg}%
\publishers{
\footnotemark[1]~Department of Computer Science, University of Exeter, Exeter, UK\texorpdfstring{\\}{, }
\texttt{a.brucker@exeter.ac.uk}\\[2em]
%
\footnotemark[2]~ Department of Computer Science, The University of Sheffield, Sheffield, UK\texorpdfstring{\\}{, }
\texttt{msherzberg1@sheffield.ac.uk}
}
\begin{document}
\maketitle
\begin{abstract}
\begin{quote}
While the DOM with shadow trees provide the technical basis for
defining web components, the DOM standard neither defines the
concept of web components nor specifies the safety properties
that web components should guarantee. Consequently, the standard
also does not discuss how or even if the methods for modifying
the DOM respect component boundaries.
In AFP entry, we present a formally verified model of web
components and define safety properties which ensure that
different web components can only interact with each other using
well-defined interfaces. Moreover, our verification of the
application programming interface (API) of the DOM revealed
numerous invariants that implementations of the DOM API need to
preserve to ensure the integrity of components.
\bigskip
\noindent{\textbf{Keywords:} Web Components, DOM}
\end{quote}
\end{abstract}
\tableofcontents
\cleardoublepage
\chapter{Introduction}
The trend towards ever more complex client-side web applications is
unstoppable. Compared to traditional software development, client-side
web development lacks a well-established component model which allows
easily and safely reusing implementations. The Document Object Model
(DOM) essentially defines a tree-like data structure (the \emph{node
tree}) for representing documents in general and HTML documents in
particular.
\emph{Shadow trees} are a recent addition to the DOM
standard~\cite{whatwg:dom:2019} to enable web developers to partition
the node tree into ``sub-trees.'' The vision of shadow trees is to
enable web developers to provide a library of re-usable and
customizable widgets. For example, let us consider a multi-tab view
called \emph{Fancy Tab}, which is a simplified version
of~\cite{bidelman:self-contained:2017}.
\begin{figure}[b]
\begin{lrbox}{\fstlst}%
\begin{minipage}{.34\linewidth}
\centering
\includegraphics[width=\linewidth]{fancytabs-normal}
\end{minipage}
\end{lrbox}
\begin{lrbox}{\sndlst}%
\begin{minipage}{.63\linewidth}
\begin{html}[basicstyle=\ttfamily\scriptsize]
<fancy-tabs>
<button slot="title">Politics</button>
<button slot="title" selected>Sports</button>
<button slot="title">Culture</button>
<section>content panel 1</section>
<ul>
<li>News Item 1 <button>Share</button></li>
<li>News Item 2 <button>Share</button></li>
<li>News Item 3 <button>Share</button></li>
</ul>
<section>content panel 3</section>
</fancy-tabs>
\end{html}
\end{minipage}
\end{lrbox}
\subfloat[\label{fig:running-example-user}
User view
]{\usebox{\fstlst}}%
\hfill%
\subfloat[\label{fig:running-example-consumer}
Consumer view
]{\usebox{\sndlst}}
\caption{A simple example: a fancy tab component.}\label{fig:running-example}
\end{figure}
The left-hand side of \autoref{fig:running-example} shows the rendered
output of the widget in use while the right-hand side shows the HTML
source code snippet. It provides a custom HTML tag
\inlinehtml{<fancy-tabs>} using an HTML template that developers can
use to include the widget. Its children will be rendered inside the
widget, more precisely, inside its \emph{slots} (elements of type
\inlinehtml{slot}). It has a slot called ``title'' and a default
slot, which receives all children that do not specify a ``slot''
attribute.
It is important to understand that slotting does \emph{not change} the
structure of the DOM (\ie, the underlying pointer graph): instead,
slotting is implemented using special element attributes such as
``slot,'' which control the final rendering. The DOM standard
specifies methods that inspect the effect of these attributes such as
\texttt{assigned\_slot}, but the majority of DOM methods do not
consider the semantics of these attributes and therefore do not
traverse into shadow trees.
This provides an important boundary for client-side code. For example,
a JavaScript program coming from the widget developer that changes the
style attributes of the ``Previous Tab'' and ``Next Tab'' buttons in the lower
corners of the widget will not affect buttons belonging to other parts
coming from outside, \ie, the application of the widget consumer.
Similarly, a JavaScript program that changes the styles of buttons
outside of Fancy Tab, such as the navigation buttons, will not have
any effect on them, even in the case of duplicate identifiers.
Sadly, the DOM standard neither defines the concept of web components
nor specifies the safety properties that they should guarantee, not
even informally. Consequently, the standard also does not discuss how
or even if the methods for modifying the node tree respect component
boundaries. Thus, shadow roots are only the very first step in
defining a safe web component model.
Earlier~\cite{brucker.ea:core-dom:2018,brucker.ea:afp-core-dom:2018},
we presented a formalization of the ``flat'' DOM (called Core DOM)
without any support for shadow trees or components. We then extended
this formalisation with support for shadow trees and
slots~\cite{brucker.ea:afp-shadow-dom:2020}.
In this AFP entries, we use the basis provided by our earlier work for
defining a \emph{formally verified model of web components} in general
and, in particular, the notion of \emph{weak} and \emph{strong
component safety}. For all methods that query, modify, or transform
the DOM, we formally analyze their level of component safety. In more
detail, the contribution of this AFP entry is four-fold:
\begin{enumerate}
\item We provide a formal model of web components and their safety
guarantees to web developers, enabling a compositional development
of web applications,
\item for each method, we formally verify that it is either weakly or
strongly component safe, or we provide a proof showing
that it is not component safe,
\item we fill the gaps in the standard by explicitly formalizing
invariants that are left out in the standard. These invariants are
required to ensure that methods in the standard preserve a valid
node tree. Finally,
\item we present a formal model of the DOM with shadow roots including
the methods for querying, modifying, and transforming DOM instances
with shadow roots.
\end{enumerate}
Overall, our work gives web developers the guarantee that their code
will respect the component boundaries as long as they abstain from or
are careful when using certain DOM methods such as
\texttt{appendChild} or \texttt{ownerDocument}.
The rest of this document is automatically generated from the
formalization in Isabelle/HOL, i.e., all content is checked by
Isabelle (we refer readers interested in a more high-level
presentation of the work to \cite{herzberg:web-components:2020,
brucker.ea:web-components:2019}. The structure follows the theory
dependencies (see \autoref{fig:session-graph}).
\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{session_graph}
\caption{The Dependency Graph of the Isabelle Theories.\label{fig:session-graph}}
\end{figure}
\clearpage
\chapter{Web Components}
\label{cha:components}
\input{Core_DOM_Components.tex}
\input{Shadow_DOM_Components.tex}
\chapter{Example}
\label{cha:example}
\input{fancy_tabs.tex}
{\small
\bibliographystyle{abbrvnat}
\bibliography{root}
}
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End: