Clarify that xml:base processing does not apply to <relative-profile-designator>.

[skynavga]

Add note to §8.3.14 indicating that xml:base related processing does not apply when absolutizing a <relative-profile-designator>.

[nigelmegitt]

Is this not also the case for <fragment-profile-designator>?

Come to think of it, the spec seems to be ambiguous here because a <fragment-profile-designator> is a <relative-profile-designator> since the constraint on <uri> for <relative-uri> is that no scheme is present, and that constraint also applies to all <fragment-uri>s too.

Only in the single case that a query is present is any distinction between the two possible types. Further, no other use is made of <fragment-uri> anywhere in the document.

I suggest adding to this issue that we should remove <fragment-uri> altogether since it serves no purpose beyond what is already allowed by <relative-uri>.

[skynavga]

@nigelmegitt In part, but we need <fragment-profile-designator> to be different. I will address your point in #1038, not this issue.

[nigelmegitt]

@skynavga I've re-examined the spec text here and it looks like I made a mistake in #1033 (comment) - the presence or absence of the path is adequate to distinguish between <fragment-profile-designator> (where it is absent) and <relative-profile-designator> (where it is present). I think any reasonable reader would infer that for a path to be present it must be non-empty, though RFC3986 does allow empty paths.