mime type for sync media

[marisademeglio]

Should we use application/smil+xml or try for something like application/sync+xml ?

The advantage of the latter is that it would remove ambiguity with Media Overlays, or other SMIL usages.

The advantage of the former is that we can reuse an existing mimetype.

The explainer discusses the relationship of SyncMedia to SMIL3; I believe it's a subset as all the extensions are within our sync: namespace.

@iherman would love to hear your thoughts!

[iherman]

There is, currently, a discussion happening, pushed by the DID working group, to see whether application/sync+smil+xml would be allowed. If yes, that would make sense.

If this is really some sort of a profile of SMIL, then the profile feature would also make sense. A good example can be seen in https://www.w3.org/TR/json-ld11/#iana-considerations

[marisademeglio]

There is, currently, a discussion happening, pushed by the DID working group, to see whether application/sync+smil+xml would be allowed. If yes, that would make sense.

That would be great! Is this discussion happening in a space that I can follow?

If this is really some sort of a profile of SMIL, then the profile feature would also make sense. A good example can be seen in https://www.w3.org/TR/json-ld11/#iana-considerations

We're not a proper "SMIL Profile" like "Unified Mobile" or "SMIL Tiny", which had to be composed of the official SMIL modules, however unwieldy, and which used the baseProfile attribute; but we are a profile of SMIL in less strictly defined senses of the word.

Are you thinking about a namespace expressed as a sub-SMIL namespace, e.g. http://www.w3.org/ns/SMIL#syncmedia? That's what the link you referenced looks like to me.

[iherman]

There is, currently, a discussion happening, pushed by the DID working group, to see whether application/sync+smil+xml would be allowed. If yes, that would make sense.

That would be great! Is this discussion happening in a space that I can follow?

Here is the discussion thread:

https://mailarchive.ietf.org/arch/browse/media-types/?gbt=1&index=L0YVPU1zUIlECS8_4ScB5H62GNI

I cc @msporny and @rhiaro; they should know more about what is happening with discussions possibly elsewhere. On the other hand, the sync media example may be welcome as yet another example where such a 'double +' media type would be useful.

If this is really some sort of a profile of SMIL, then the profile feature would also make sense. A good example can be seen in https://www.w3.org/TR/json-ld11/#iana-considerations

We're not a proper "SMIL Profile" like "Unified Mobile" or "SMIL Tiny", which had to be composed of the official SMIL modules, however unwieldy, and which used the baseProfile attribute; but we are a profile of SMIL in less strictly defined senses of the word.

Are you thinking about a namespace expressed as a sub-SMIL namespace, e.g. http://www.w3.org/ns/SMIL#syncmedia? That's what the link you referenced looks like to me.

Yes but it is not bound to the SMIL namespace. An expected HTTP response would look like

Host: example.sync
Accept: application/smil+xml;profile=http://www.w3.org/ns/SOMETHINGHERE

However, if the relationship to SMIL is not 100% clear then this may not be the best option. I guess the real question (and also with the sync+smil+xml option): what happens if a bona fide SMIL processor, that does not know about sync media, tries to interpret a sync file? Will the result be chaos or something reasonable? If the former, then maybe application/sync+xml is the best option. If the latter then the other options are probably preferable.

[marisademeglio]

However, if the relationship to SMIL is not 100% clear then this may not be the best option. I guess the real question (and also with the sync+smil+xml option): what happens if a bona fide SMIL processor, that does not know about sync media, tries to interpret a sync file? Will the result be chaos or something reasonable? If the former, then maybe application/sync+xml is the best option. If the latter then the other options are probably preferable.

SyncMedia custom features would not be supported by a pure SMIL processor but they are progressive enhancements*, so the presentation is still technically valid without them, even if to an end user, it would look different. So I can't say the result would be "chaos".

* The one exception to this "progressive enhancement" idea is sync:defaultSrc. Read on..

Because the sync:defaultSrc attribute can be used in place of SMIL's own src, a presentation that used this construct would not have its media object srcs resolved correctly by a pure SMIL processor. But also, src is not a required attribute in SMIL, thus the presentation is still technically valid without them. However, I don't know where this falls on the "chaos<-->something reasonable" spectrum. The result may not make sense to an end user but the processor would not be complaining either 🤷‍♀️

[msporny]

@marisademeglio wrote:

That would be great! Is this discussion happening in a space that I can follow?

There is a spec:

https://datatracker.ietf.org/doc/html/draft-w3cdidwg-media-types-with-multiple-suffixes-01

... and @iherman linked to the discussion so far:

https://mailarchive.ietf.org/arch/msg/media-types/Sv8oT38p1nWHPYZQmnL_9GPjeic/

I'll note that the application/sync+smil+xml use case is very similar to our application/did+ld+json use case, and was the reason we wrote the IETF draft linked to above.

[iherman]

@marisademeglio what I understand from #50 (comment) (and, having scanned through the document) if the synched media document does not use the track feature, then it can be regarded as a bona fide SMIL file with some additional metadata (sync:role) that does not really affect playback. For me this is a perfect use case for the application/sync+smil+xml.

[marisademeglio]

@iherman Yes, without sync:track and sync:role, a SyncMedia document looks like a regular SMIL document.