The top level group field could support string formatted valid URIs for common attributes.
This way, multiple files could be included in a group by URI, and have shared attributes in the file, which could be either online as a web URL, or as a local file file:// path specifier.
(Note: skipped contents and prefix for clarity)
somefile.txt
{
...
"group": "file://common.js",
...
}
common.js
{
"__version__":"1.0.5",
"someNS":{
"someFields":"someData"
}
}
It is intended that the common features would be loaded first then any other fields in the local meta would override the referenced common file.
Technically, the common file could also have a group field, but it is unclear if it would break the specification if the group for the common file was not identical to itself, as if not it would break the semantics of the group.
Alternatively, this could all be implemented as a new top-level field, which under normal (omitted) cases defaults to a web URL with the current specifications' default settings.
The top level
groupfield could support string formatted valid URIs for common attributes.This way, multiple files could be included in a group by URI, and have shared attributes in the file, which could be either online as a web URL, or as a local file
file://path specifier.(Note: skipped contents and prefix for clarity)
It is intended that the common features would be loaded first then any other fields in the local meta would override the referenced common file.
Technically, the common file could also have a group field, but it is unclear if it would break the specification if the group for the common file was not identical to itself, as if not it would break the semantics of the group.
Alternatively, this could all be implemented as a new top-level field, which under normal (omitted) cases defaults to a web URL with the current specifications' default settings.