tac
tac copied to clipboard
guidance/input to Apple re: Uniform Type Identifiers for the various ASWF projects
Please share any additional details on this topic
[Uniform Type Identifiers ](https://en.wikipedia.org/wiki/Uniform_Type_Identifier#:~:text=A%20Uniform%20Type%20Identifier%20(UTI,class%20or%20type%20of%20item.) akin to MIME types
Detail what actions or feedback you would like from the TAC
We'd love to get any guidance from the TAC re: this. Should not take long.
How much time do you need for this topic?
None
Following up - if you can provide a proposal doc I can work to get it ready for the TAC website and to be approved. Thanks!
Hey @drwave - can you provide that proposal doc when you have time? Thanks!
Thanks John. We have something; let me get it up here...
On Nov 27, 2023, at 8:29 AM, John Mertic @.***> wrote:
Hey @drwave https://github.com/drwave - can you provide that proposal doc when you have time? Thanks!
— Reply to this email directly, view it on GitHub https://github.com/AcademySoftwareFoundation/tac/issues/541#issuecomment-1828180210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM2AOS77W3RPLREOOEA2HDYGS5WTAVCNFSM6AAAAAA7NDTZ7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRYGE4DAMRRGA. You are receiving this because you were mentioned.
@dgovil - please add the proposal to this issue.
Adding here as a markdown. Some notes :
- We've only included projects with associated file formats in the table below. As such, we've skipped OpenCue, ORI, OpenAssetIO, DPEL, OIIO etc...
- Where the extension references the Open part of the project name, we've kept it in the identifiers. e.g oil, ocio, otio.
- ~~Where they don't reference the open part, we coincidentally also have multiple implementations that use the same extension, so we drop the Open part in the identifier to be agnostic.~~
- I've included OpenFX in the table below, but I don't believe we should give it a specific identifier because it uses generic dynamic library extensions, and as such shouldn't be associated with an identifier.
- Media Type below is what people would historically refer to as MIME type. UTTYpe is the current and historical Apple specific identifier
Project | Extensions | UTType | Media Type | Notes |
---|---|---|---|---|
Open Shading Language | .osl | io.aswf.openshadinglanguage | application/vnd.aswf.openshadinglanguage | .osl is source. Can they be used interchangeably wth oso? |
.oso | io.aswf.openshadinglanguage-object | application/vnd.aswf.openshadinglanguage-object | .oso is a compiled version of the OSL, but plaintext. | |
OpenColorIO | .ocio | io.aswf.opencolorio | application/vnd.aswf.opencolorio | |
OpenEXR | .exr | com.ilm.openexr-image | image/x-exr | EXR is already well established by these descriptors |
OpenVDB | .vdb | io.aswf.openvdb | application/vnd.aswf.openvdb | VDB extension used by both OpenVDB and NanoVDB |
MaterialX | .mtlx | io.aswf.materialx | application/vnd.aswf.materialx | |
OpenTimelineIO | .otio | io.aswf.opentimelineio | application/vnd.aswf.opentimelineio | |
.otioz | io.aswf.opentimelineio-package | application/vnd.aswf.opentimelineio-package | Can all applications that open otio, open otioz? | |
.otiod | io.aswf.opentimelio-bundle | N/A | Can all applications that open otio, open otiod? | |
OpenFX | .dll / .dylib | N/A | N/A | Skipping this one because the extensions are too commonly used |
I'm not sure how widely supported it is but OpenTimelineIO also uses the ".otiod" extension for directories that contain an .otio file and associated media: https://opentimelineio.readthedocs.io/en/stable/tutorials/otio-plugins.html?highlight=otiod#otiod
@darbyjohnston ah good callout. I'll look into how directories are handled by both.
Afaik MIME/Media doesn't handle directories but UTType might because you can register directories as a bundle type on Apple platforms.
Thanks, @darbyjohnston . I added a UTType for otiod. I don't see a way to do it for MIME types, but UTType supports it.
Questions for some of the folks (just cc'ing who comes to mind first, but anyone please feel free to answer)
- @meshula , can any application that supports otio also support otioz and otiod?
- @lgritz , can
.osl
and.oso
be used interchangeably? Can any application that supports one , support the other?
.oso is not technically part of the OSL spec, it's used by the library. If somebody else wrote an independent implementation of the OSL language, it would read the .osl files of course, but I wouldn't necessarily expect it to use .oso unless they particularly wanted to be able to read compiled shaders that were built with our oslc compiler.
Okay that's good to know. I'll ditch it from the table above
OTOH, the "oslquery" library and "oslinfo" utility to read oso files. I don't have a strong opinion on whether you should care about the oso extension.
Let's just leave it as: .osl files are "user-facing", but .oso files are not, if you see my point.
can any application that supports otio also support otioz and otiod?
Yes, although it is not transparent like opening a usdz file, an application must take specific action upon encountering such a file.
There seems to be a mix where for some you are using the name of the project (opentimelineio, openshadinglangauge) and others you are using the file extension (exr, vdb). Should w be consistent?
I had called that out in the points above the table. Happy to make them start with open as well, but I wasn't sure if that was the right call.
- I used Open when the extension starts with an o from the acronym
- VDB is used by both OpenVDB and NanoVDB. Should that be associated with one over the other?
- EXR also has a few implementations kicking about, like the one Nick put in USD recently. Should we associate it with a specific one?
nanovdb is part of the openvdb project now
I don't have especially strong feelings about it, but my leaning is that the "io.aswf" part indicates that these are meant to be full, formal, maximally unique names, so I think use the correct project name across the board?
I'm not crazy about the "if there is another implementation, switch to the abbreviation" heuristic, because (a) so what, these are the official ones; and (b) that nice rule of thumb is going to become an inconsistent mess as soon as a currently-one-implementation format has a second implementation released after you have carved these things in stone.
That's fair. If nanovdb is considered part of OpenVDB, and not a separate thing, I'll just go ahead and adjust them all to prefix with open. (Except for MaterialX of course)
@dgovil Hi Dhruv! -- In an earlier comment you wrote in a table that OpenEXR files should have the MIME type (Media Type) of application/vnd.aswf.openexr
but I just wanted to share that the shared-mime-info
package from the Freedesktop folks -- which is used by a lot of Linux projects -- already locked-in *.exr type as being image/x-exr
, as per this line:
https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/091b9b604fd29b622067afb6a69fb63109c978e5/data/freedesktop.org.xml.in#L5432
Personally I think a mimetype starting with image/
makes a lot more sense as exrs are.. well, images.
I'm also not saying that the shared-mime-info
package is the ultimate authority on the matter, but it is an extremely popular database that a lot of MIME-using codebases (like Gnome Desktop) source their types from already.
Whatever MIME types the ASWF ultimately decides to "officialize" ("popularize"?) might be worth contributing into that package maybe.
Yeah you're right on the money about exr. Our type folks also suggest keeping it as the current ilm version.
I'll adjust the table above accordingly.
I don't think it makes sense to have OpenFX dll/dylib in the table. Those are not file type associations, they are implementation artifacts.
I don't think it makes sense to have OpenFX dll/dylib in the table. Those are not file type associations, they are implementation artifacts.
Yep, that's why I marked them as N/A. I was just listing all the ASWF projects on the left column to make sure I didn't miss any.
Ok, how about putting N/A in the associated file extension column, as it still a fact that dll/dylib are not file extensions associated with OpenFX. It would be nonsense to check all dll/dylib files to discover if they are in fact associated with OpenFX.
Hi @dgovil - anything else needed on this one?
I think we're good here and can close this out. Either you or Michael would have to close it though.
There are some good points about a different mime type, but for our needs of the UTType, I think we are good.