Open pietercolpaert opened 8 months ago
From the call of 2023-11-08:
gsp:asWKT
property as part of the shape of the other collection. Maybe the conditional imports are not needed after all?That way, imports could be entirely removed from the TREE specification.
From the call of 2024-06-05:
Conditional imports should go: they don’t work on mixed collections/streams
Actions:
Problems
The member extraction algorithm resolved a part of the use cases for having conditional imports in the spec. However, two problems imports solve still remain valid:
Problem 1: Fragmenting on external paths
A property is being used as a
tree:path
parameter, but it is not part of the actual member. Therefore, when theExample of when this might be useful:
Problem 2: importing streams
One should be able to register on a pubsub stream when the node or collection is going to update at a certain moment through that stream.
Solution
Conditional imports
A conditional import can be defined as follows - it defines an extra HTTP request that can be done if from the current page it must follow the link if it needs graph patterns that match the path.
Import Stream
Also
tree:importStream
was defined which allows one the subscribe on a websockets stream or an SSE stream.Questions
Conditional imports: Is this design still adequate to the use case? Is the term
import
correctly chosen?ImportStream: what can be expected from that stream? Should we constrain it to only view descriptions so that it always updates the full set of members? Or should we also allow to it being defined on a subset? Should we also define it to describe its updates through activity streams, as members can also be deleted?