That could work, but it doesnât really convey the idea that all referenced files must be contained within the repository. For example, if I say;
Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ
file://localhost/etc/passwd
Â
that would cause casual readers to believe that weâre looking for the /etc/passwd file on the local machine, rather than for an /etc/passwd file within the
local CSAR or local repository. I think such an approach would be very confusing.
Â
Relative file URLs do not require a host. This would be enough:
file:etc/passwd
That would (possibly) interpreted as relative to the CSAR root. But really you don't need a URL scheme, as it can inherit from the source document. So this should be enough (and it's also a valid relative URL):
etc/passwd
Is identical to "file:etc/passwd" if the importing document is local. Absolute paths are more difficult to interpret, as Matej implied. Relative to what machine? So something like this:
file:///etc/passwd
Might mean ... the local machine where you run the parser? The orchestrator? The remote server? This could be left up to implementations to figure out. And they may very well disable absolute "file:" URLs for security and practical reasons. Any good URL library will be able to tell you if a URL is absolute or not.
I'll also point out the "http:" scheme URLs are very useful, both for imports and for artifacts. E.g.:
imports:
It could be very useful (and indeed ONAP does this, as does Cloudify) to import from a well-known DNS hostname within the orchested environment. I don't see any reason not to use URLs, as they are flexible enough (they were designed exactly for such use cases). But in case there's strong resistance, I don't see why TOSCA has to have an opinion about their interpretation. I'd rather have it left vague than have a limiting opinion. (Unless ... we really want to talk about the CSAR spec, which is woefully skimpy right now.)
By the way, Puccini (which expects URLs) handles the "implicit" import of the Simple Profile by using a custom URL scheme, "internal:", for resources embedded inside the tool executable. Users don't see it, but could potentially do an import of an "internal:" URL path explicitly. Obviously, that's just a Puccini feature, but still valid within the URL spec. My point: the URL spec is flexible enough for all our needs, in my opinion.