Transclusion of blocks via fragment identifiers

[iilab]

Transclusion of blocks via fragment identifiers

[jmatsushita]

It could be that for linking the fragment identifier is meant as a location whether for transclusion it is understood as a container. In some context s it might be needed to qualify in order to explicitly we express whether one or the other is meant.

Techniques to keep track of fragments across changes could be:

• assign a unique ID automatically to blocks (in the org mode way)
• use a content addressability approach which links to the hash of a section's content.

Maybe the problem can be split in:

• how to keep track of the evolution of content blocks (including splitting merging or removing)
• how do links refer to a particular point in time.

It could be that web server would cache fragment retrieval sources in order to memorise what the client's expectations are. For larger volumes link versioning my be required so that the client refers to a particular point in time, minimising the effort on the server side.

HTTP moved status codes could be used to help update clients.

#12

[poser]

@jmatsushita

Inclusive section transclusion appears to over-transclude by a few characters:

index.md

# EtI Curriculum - TEST

Hi.

## Test transclusion

:[](test-folder/index##second-level-heading)

test-folder/index.md

# Test page

Hi again.

## Second-level heading

Second level heading text

### Third-level heading

Third level heading text

### Another third-level heading

More third level heading text

## Another second-level heading

More second level heading text

Result