You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use regular text variables to represent URIs. In latis2, we use naming conventions ("file" or "url") to pick out the URI variables. This is limiting and less safe.
With a Uri class that extends Scalar (invoked with a class property in the fdml), we could more safely pick out the URI variable (e.g. in a granule list dataset).
Presumably we would encapsulate some URI utility methods here, though we need to be mindful of other URI use cases (e.g. reading datasets). Maybe make a uri package to encapsulate all things URI? This is akin to Time.
Another question to consider: Should we continue to use the java.net.URI class internally? Or http4s? Or...?
The text was updated successfully, but these errors were encountered:
We currently use regular text variables to represent URIs. In latis2, we use naming conventions ("file" or "url") to pick out the URI variables. This is limiting and less safe.
With a
Uri
class that extendsScalar
(invoked with aclass
property in the fdml), we could more safely pick out the URI variable (e.g. in a granule list dataset).Presumably we would encapsulate some URI utility methods here, though we need to be mindful of other URI use cases (e.g. reading datasets). Maybe make a
uri
package to encapsulate all things URI? This is akin toTime
.Another question to consider: Should we continue to use the java.net.URI class internally? Or http4s? Or...?
The text was updated successfully, but these errors were encountered: