Hi
Thanks for all the great discussion around this, I appreciate it. I'll give my 2 cents, if I may. I do understand the point that the spec is describing REST over HTTP, and hesitation to expand on UriBuilder further for non-http schemes.
The reason for seeking clarification, unfortunately, isn't theoretical. The spec provides UriBuilder, and it can be used by a consumer anywhere the API and an implementation is present. I'm in a position where I have a consumer doing just that. I suspect that there was a requirement to build a File URI, and the developer found "UriBuilder" (IDE-auto complete maybe?), saw it under a javax namespace (I appreciate the package is changing in Jakarta EE 9), and thought it was good to use for this purpose.
There's a couple of things I'd point out:
1. The spec documentation does state "The specification will assume HTTP[bib4] is the underlying network protocol and will provide a clear mapping between HTTP and URI[bib5] elements and the corresponding API classes and annotations."
While point (1) is quite clear, it might not be obvious that it applies to UriBuilder. Even if it is, it appears to be contradictory to (2) and (3).
The file URI actually used to work in CXF. The change that broke it, bizarrely, is a change to pass TCK tests for other schemes (mailto, urn, ldap, telnet and foo!). Side note - I have reported this to CXF, and provided a patch. Some adjustments have been requested, but I'm hopeful that if I make the necessary changes, the fix will be merged in.
From a spec perspective, if the desire is for UriBuilder to be http only, then I think that should be called out in the Javadoc (and maybe more clearly in the spec doc), and the assertions for non-http schemes removed in the TCK. That would allow an implementation of UriBuilder to support nothing but http schemes and still pass the TCK. If the desire is to allow support for non-http URI schemes, then I think additional tests for UriBuilder.fromUri().path() with a range of schemes is reasonable, and shouldn't be too difficult to add. I doubt it'll have a big impact on the current implementations. Given that Jakarta EE 9 is mostly package rename, it might not actually be until Jakarta EE 10 that the tests changes would take effect.
Whichever way this ends up going, I do think there's some genuine confusion, and need for clarification so the spec doc, javadoc and TCK tests are in alignment. I'm very happy to do the work and submit PRs (in fact I would love the opportunity to do that).
Thank you again for all the discussion. I think it's fantastic to see more of this in the open with the move to Jakarta EE.