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
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:
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.
The text was updated successfully, but these errors were encountered:
codello
changed the title
[SPEC] Application Specific Headers
[Spec] Application Specific Headers
May 6, 2024
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
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.The text was updated successfully, but these errors were encountered: