Clarification on acceptance of relative URIs
Suggested change
The current specification permits for relative URIs in all cases. Based on the discussion on the 2021-09-24 meeting I suggest the following changes:
- Generators MUST create absolute URIs when the absolute form of the URI is known to the generator or can be evaluated by the generator.
- Parsers MUST support absolute URIs in all cases and MAY report or reject relative URIs but SHOULD be able to handle them for backward compatibility.
- The content of the
<location>
-tag is excluded from the above rules. Relative URIs are still considered valid. - Generators SHOULD NOT generate relative URIs in elements that point to a level in a directory structure higher than their own. Generators SHOULD NOT us the parent directory operator ".." in URIs used in
<location>
.¹
In addition the current clarifications on URIs should be kept in the specification as they are relevant at least when working with legacy data. A note might be added clarifying the reason for them to be still present. Such as: "While relative URIs are not valid they may be present in data generated under earlier revisions of this specification, therefore these rules apply when such data is encountered.".
Required version updates
This change will not require a version or namespace update.
¹ Those are actually two rules as e.g. "a/../b" is not referring to a higher level but makes it more complex for parsers to check.