> The fires in HSS in Germany were determined using web crawling for the year 2023 because no other data was available. All other probabilities were calculated using researched data. The results show a significantly lower probability of an HSS fire compared to a general house fire.
> the findings indicate that the probability of an HSS fire is very low (0.0049 %) and is 50 times lower than for a general house fire.
So for every 50 "normal" house fires, one extra will be due to HSS.
The bigger question is, what are the consequences of such fires? Looking at burning electric cars, that can't be put out, having burning batteries in an apartment building basement doesn't really seem that fun.
I don't understand this part. The people who left X after Musk's takeover seem to be mostly people who were on the winning side of Covid, i.e. the side that used the state and media apparatus to coerce people to participate in a medical experiment.
Academic papers are generally written to be read by peers in the field. If you're not a researcher in the hypermedia field, you shouldn't expect to immediately understand a paper without doing some work. The abstract is a paper distilled to its essence, and is not the place to expect to learn the necessary background.
In this case, the abstract says: "This functional mechanic is used to create first an informal and then formal definition of the term "hypermedia control". Using this formal definition we then derive a generalization of the concept, referring contextually to the World Wide Web." Therefore, we should expect to look in the paper for the definition.
We find the "functional definition" at Definition 4.1: "A hypermedia control is an element that responds to an event trigger by issuing a type of request to a URL and placing the response at some position within the user agents viewport." The "formal defintion" then follows immediately after, but can't be quoted here because it requires LaTeX notation and a full page of text.
As a possible non-academic summary is that a hypermedia control can be defined as:
An interactive element within a hypermedia system (like a web page) that allows users to trigger actions, typically resulting in new content being loaded or displayed. Common examples include: links (clicking loads a new page); buttons (clicking triggers an action like submitting a form); form inputs (entering data and submitting retrieves results); images with embedded links (clicking loads new content).
The key aspects of a hypermedia control are that it responds to a user action (click, submit, etc.); it causes some kind of network request (usually to fetch new content); it specifies where that new content should go (replace the whole page, update a specific area, etc.)
One important clarification I should have mentioned: buttons and form inputs only meet the definition of hypermedia controls when HTMX or something similar is used. Under normal HTML only links, images, complete forms, and iframes qualify, since (for instance) form inputs and buttons can't on their own make a request or specify where new content would go.
You can put the actual definition on page 4, or you can make it easy for the reader and just say "hypermedia controls (like links and buttons)" the first time you mention the term in the abstract.
Strictly speaking, buttons aren't typically hypermedia controls. Haven't read the paper yet but the only controls in HTML are links and forms. Buttons can be nested inside those as actuators but aren't controls unto themselves since they don't meet that functional requirement of sending a request to a URL and inserting response content into the viewport.
EDIT: It seems the authors also consider images and iframes to be controls since they also make requests and add content to the viewport.
"four types of hypermedia controls found in HTML: links (anchors), forms, image tags and iframes"
"Examining the hypermedia control mechanic of links, forms, image
tags and iframes in HTML, we see the following common functional
pattern emerge:
For each of these controls:
(1) An event trigger (click, submit or load)
(2) Causes a particular type of HTTP request issuance
(3) That request is made to a resource location specified by a
URL
(4) The content of the HTTP response is then placed in the user
agent viewport
Within the context of HTML, this gives us the following functional definition of hypermedia controls as an element that incorporates this hypermedia control mechanic:
Definition 4.1 (Hypermedia Control). A hypermedia control is
an element that responds to an event trigger by issuing a type of
request to a URL and placing the response at some position within
the user agents viewport."
They mention the limitations of these existing hypermedia controls within HTML. In general, existing HTML controls don't allow the developer to choose any type of HTTP request to be sent from any type of HTML element and target any part of the page.
"in the absence of an extension
mechanism hypermedia clients and servers must agree in advance
on the types of hypermedia controls they will support.
HTML includes a very powerful extension mechanism: JavaScript
[47 ]. By taking advantage of this extension mechanism we are able
to extend HTML and provide the generalized hypermedia controls
outlined above to HTML authors."
"CONCLUSION
In this paper we proposed an informal and then definition of the
term "hypermedia control", derived from the implementations of
four common such controls found in HTML: anchors, forms, im-
ages and iframes. From this formal definition we then derived a
generalization of the concept of hypermedia controls within the
context of HTML.
We then introduced htmx, a JavaScript library that implements
these generalizations for HTML authors. We demonstrated two interactive patterns that can be implemented by HTML authors using
generalized hypermedia controls. Finally, we introduced Hyperview, a mobile hypermedia that also implements the generalization
we proposed. We demonstrated an interactive pattern achievable
in Hyperview using this generalization, thus demonstrating that
this generalization applies to hypermedia systems beyond HTML
and the WWW."
- examination of existing hypermedia controls in HTML
- formalization & definition
- generalization
- application (htmx & hyperview)
The TLDR is:
> So a hypermedia control (again, from a functional standpoint)
is an element found in a hypermedia document that initiates a
hypermedia exchange by a hypermedia client in response to some
event, thereby updating the client state in some manner (i.e.
with some disposition)
Actually, I built this because I don't really understand async/await. Now that I understand generators (somewhat), I might be able to grok async/await ;-)
Overall I agree: yes, with fexprs you lose some code introspection ability compared to macros. I haven't found it to be a big deal in my fexpr-based hobby Lisp so far.
Re your two points:
You could have "symbol fexprs", analogous to symbol macros, I guess.
For places I think the first-class solution as employed by T and others is better, and would work fine with fexprs:
(set (name-of person-1) "sam") simply stands for ((setter name-of) person-1 "sam").
IOW, name-of is expected to be a reader function. Every reader function has a writer function attached to it, that we extract with (setter name-of). Then we call that writer function with the rest of the original arguments.
I find the claim about image-based development being required for macros somewhat unfounded.
The most trivial counterexample is an interpreter - it can simply evaluate the macros just like ordinary functions.
A step up in complexity is a compiler that - during compilation - compiles macro definitions by emitting code and dynamically loading it (Goo does this http://people.csail.mit.edu/jrb/goo/goo.htm , and I have also put a toy implementation of this together using dlopen, and there are probably many other impls that do this.)
