Replace modelica:// by modelica:/

[HansOlsson]

Fix the major problem that using authority as a path is problematic, since they are normally case-insensitive.
(And keep the old variant as a deprecated feature to not break compatibility.)

This should be straightforward to adapt in tools, and then in libraries - in a safe way without breaking compatibility.

[henrikt-ma]

We shouldn't miss the opportunity to make the new Modelica URIs more useful than the ones we have today. That's the purpose of MCP #2663.

[HansOlsson]

We shouldn't miss the opportunity to make the new Modelica URIs more useful than the ones we have today. That's the purpose of MCP #2663.

We should correct Modelica URIs so that they work right now; and can be updated with minimal changes in models.
Restructuring all resources as proposed in #2663 would break compatibility in various ways and is thus problematic and shouldn't block this good change.

[henrikt-ma]

We should correct Modelica URIs so that they work right now; and can be updated with minimal changes in models.
Restructuring all resources as proposed in #2663 would break compatibility in various ways and is thus problematic and shouldn't block this good change.

No, #2663 isn't breaking backwards compatibility thanks to the use of a new form of Modelica URIs that can't be mistaken for the old form. Hence, the problem is that if we do what is suggested here, we will miss the opportunity to introduce a better mechanism in a backwards compatible way.

[HansOlsson]

I have now found the specific part that requires the authority to be case-insensitive, which allows things like modelica://modelica.mechanics/ with current syntax.

It's found in RFC3986 (but likely not in the original RFC1738) https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2 so technically it's not the authority that is case-insensitive, but its host-part (which amounts to the same). (Which means that modelica URIs were broken when it was added in 2009, since the rfc is from 2005.)

[henrikt-ma]

Nothing has changes since my last review, but it would be nice to try to find a solution after we're done releasing 3.6.

[HansOlsson]

Based on the meeting discussion for #2663 I understand this should be re-activated.

[henrikt-ma]

Considering that we use the period for separating identifiers of the class, the leading path separator in modelica:/Modelica.Mechanics/Resources/foo.txt doesn't really make sense to me. Since it doesn't really make sense, we should also consider omitting it, like this:

modelica:Modelica.Mechanics/Resources/foo.txt

[HansOlsson]

Considering that we use the period for separating identifiers of the class, the leading path separator in modelica:/Modelica.Mechanics/Resources/foo.txt doesn't really make sense to me. Since it doesn't really make sense, we should also consider omitting it, like this:

modelica:Modelica.Mechanics/Resources/foo.txt

The leading path separator has semantic meaning in URIs, and the leading path separator makes sense currently - and allow us to later introduce a variant without - with different semantics.

[HansOlsson]

The leading path separator has semantic meaning in URIs, and the leading path separator makes sense currently - and allow us to later introduce a variant without - with different semantics.

Thus I think we should move forward with this one as is.

[henrikt-ma]

I'm missing a description of the deprecated use of the host part to give the class name.

[HansOlsson]

I'm missing a description of the deprecated use of the host part to give the class name.

It was sort of there, but I cleaned it up, made it into a separate paragraph, and added two examples.

[henrikt-ma]

Looks OK with the exception of removing the constraint on the "first part of the path".

[henrikt-ma]

It would also be good to see the conflicts resolved before giving a final approval.

[HansOlsson]

It would also be good to see the conflicts resolved before giving a final approval.

Now done. It was the comma-change that caused the conflict.

[henrikt-ma]

Looks good now.