[Spec] Application Specific Headers

[codello]

Suggestion

I'd like to suggest the addition of Application specific headers to the spec. These are headers that are not part of the specification but may be used by implementations for various purposes. This suggestion is currently included in spec.md:

format/spec.md

Lines 164 to 168 in 23bf930

	Implementations MAY define application-specific headers
	but SHOULD prefix those headers with the application name to avoid conflicts with future standardized headers.
	Implementations MUST ignore headers they do not recognize.
	The order of headers is irrelevant (note the exception in section 3.1.)
	although standardized headers should precede any application-specific headers.

Use case

We have seen the need for application-specific metadata in several places. Examples include #RESOLUTION, #NOTESGAP or the non-standard use of the #VIDEO header by usdb_syncer.
This proposal offers a standardized way for applications to add custom metadata that is unlikely to conflict with future standardized headers or custom headers used by other applications.

In practice USDX-specific headers like #RESOLUTION could continue to exist as, for example, #USDX-RESOLUTION.

Extra info/examples/attachments

This proposal also gives way to a possible standardization process for new headers: If a certain feature is used by an implementation (say via the header #USDX-FOO) and this feature is deemed useful by other applications, these other applications may begin to support their own variant (for example #VOCALUXE-FOO). If a feature becomes popular enough it can be standardized (for example as #FOO) with a clearly defined syntax and behavior. Migration of existing songs that use the prefixed-variants should be simple in most cases.

This kind of prefixing behavior bears some similarity to vendor prefixing in CSS.

The spec currently only says that application specific headers should be prefixed with the application name. A specific format is not suggested (I have been using - to separate the prefix in the examples above). This might be something that should be defined as well.

[Baklap4]

I think this is a great idea. I'd do the prefix seperation with _ instead of - since its more inline with environment variable naming. However CSS and Html Headers use the - either is probably fine.

i do sense a problem though.. If an application finds the need for a custom header, they could just come directly to the format project and suggest their changes either in discord or on github. This makes for a smoother experience overall since they don't have to program something at start which might change when adopted into the spec. You see the problem with vendor-prefixing in css is that in the end it's added to the spec, but the vendor specific one still stays until forever and won't be cleaned up..

[codello]

I see your point. From a purist perspective it is certainly desirable. However I think that at some point (if not already) an implementation will have the need for new functionality and doesn't want to wait for standardization. Or we decide not to standardize a feature and the application still wants to use it. If we provide a way to do that we avoid running into conflicts later on when we want to standardize a header that is already in use by some application with different semantics.

I also kind of see a risk (or maybe a tendency even) that the spec gets bloated with a lot of headers, many of which may only be supported by a subset of implementations. I tend to prefer an approach where applications implement a proof-of-concept using application specific headers so that we can standardize the semantics when implementation details are less vague. The potential of duplication with vendor prefixes is unfortunate but I don't see a way to avoid that. The alternative of applications defining their own headers without standardization and with different semantics seems worse to me.

I'd do the prefix seperation with _ instead of - since its more inline with environment variable naming.

I don't have a strong opinion on this. The current convention of capitalizing headers hasn't led me to thinking of environment variables. I'd be fine with both.

[Baklap4]

Hmmm you do bring in a valid point. Since the spec already mentions vaguely that you can define your custom headers, might aswell just make it more complete by specifying how to. Feel free to draft a pr for this 👍