Fragment reference inconsitency

[mbakeranalecta]

There is an inconsistency in how fragment references work. This is probably left over from before the normalization of insert by reference syntax. The issue is this:

Normal rules are that object inserts are not typed. That is, if

[#foo]

generates a reference to the object named foo by looking up its type and creating the appropriate kind of reference. (This is in contrast to many XML vocabularies, where the reference statement states what kind of thing it is referencing.)

The corollary of this is that an object insert is similarly untyped:

>>>[#foo]

This inserts the named object, regardless of type.

But this is not true with fragments. Unlike stings, fragments do not have separate names in a separate namespace. They can be identified by either ID or name.

However, there is specific syntax for inserting fragments:

>>>[~foo]

This is doubly confusing, first because it is inconsistent with other inserts and because it is not clear if ~foo refers to an ID or a name. This also means that the parser can't validate the ID reference if an ID is used.

There seems to be no justification for this syntax. I think it should be removed.

One of the implications of this is that there is nothing special about a fragment as an object. It is just an arbitrary block. This in turn implies that there is nothing special about the string scoping rules for fragments or string substitution rules for inserted blocks. I don't see how that raises any issues.

[mbakeranalecta]

The use of ~ to dereference fragment identifiers removed before 3e9b8f6fd8cddf9cbedb25c44ab48323216ce71e

[mbakeranalecta]

Documented before 0b71073284a0e079833263af0c4cadc38595bab7