Apparent inconsistency in definition and use of the term 'target-complete'

SML says (2.2):

A target-complete identifier is a URI or IRI that contains all the information required to locate a target of an SML reference. It is a consequence of this definition that a target-complete identifier cannot be a relative URI/IRI.

This seems to say explicitly that "relative URI/IRI" and "target-complete identifier" are disjoint classes.

But SML 4.3 says of references defined by some arbitrary reference scheme:

An SML reference scheme definition MUST specify all of the following:

...

An assertion that states whether or not the reference scheme uses target-complete identifiers. Using target-complete identifiers requires all the following:

If these references are allowed to be relative references, i.e. they are not already target-complete, then some implementation-dependent base URI or IRI is used to resolve them to URIs or IRIs. (See section 5 of [IETF RFC 3986] and section 6.5 of [IETF RFC 3987].)

If "relative URI/IRI" and "target-complete identifier" are disjoint classes, this makes no sense. If 3b makes sense, then the claim in 2.2 about the consequence of the definition of "target-complete" is false.

I don't think I care how this is resolved, only that the terms be used consistently.

Implementation-dependent base URI/IRI in SML reference schemes (general)

SML 4.3 point 3.b says that if a reference scheme requires target-complete identifiers, and a relative reference is used,

then some implementation-dependent base URI or IRI is used to resolve them to URIs or IRIs. (See section 5 of [IETF RFC 3986] and section 6.5 of [IETF RFC 3987].)

Questions: Does this mean that the definition of a reference scheme cannot (or MUST NOT) forbid relative URIs? I think it does not, since the phrase "if these references are allowed to be relative references" suggests that a schema MAY "allow" them to be relative (and thus may chooose not to). Does this mean that if a reference schema allows relative references, then it MUST NOT specify an interoperable way to identify the appropriate base URI? If not, then what is the force of the quoted material? Does this mean that if a reference schema allows relative references and does not specify an algorithm for identifying a base URI, then it MUST NOT specify that the choice of the base URI is implementation-defined (and thus must be documented)? If not, then what is the force of the quoted material? Is it possible for a user to provide useful relative references, which reliably capture the user's intention, without knowing how the base URI used to absolutize the relative references will be chosen? If so, is it wise to specify that the implementation need not document its method of identifying a base URI?

Implementation-dependent base URI/IRI in SML URI reference scheme

SML 4.3.1 describes in list item 2 how SML references using the SML URI reference schema are resolved. Among other things, it says

If the URI is a relative reference, then use an implementation-dependent base URI to resolve it to an URI.

One of the question evoked above by the general case is also relevant here: Is it possible for a user to provide useful relative references, which reliably capture the user's intention, without knowing how the base URI used to absolutize the relative references will be chosen? If so, is it wise to specify that the implementation need not document its method of identifying a base URI?

Base URI in SML IF

SML IF (4.1) says: The first child of each document is typically a docInfo element that contains a baseURI element and a list of alias elements. The baseURI element can be used to specify a base URI for relative references in the document.

Question: Would it not be easier just to allow or encourage the use of the spec?

Proposal for URI resolution in SML and SML IF Drop the current normative descriptions of URI resolution and aliasing. Optionally, restore the same or similar text, modified as need be, marked as non-normative paraphrase of the relevant normative specifications for URIs (RFC 3986, XML Base).