# from David Golden
# on Friday 02 March 2007 02:45 pm:
>For the META.yml spec, should anything not expressly allowed be
> forbidden?
>
>If so, then any extension like this has to be explicitly added to the
>spec. On the positive side, it doesn't leave ambiguity for tools that
>work with META.yml.
What about having an "extensions" field as part of the spec declaration,
where anything listed in it is allowed? This would mean that tools
which are extending the spec would not have to change the attribute
name if it gets adopted as-is, and would still allow strict validation
if you're into that sort of thing.
---
thbbt: foo
meta-spec:
url: http://module-build.sourceforge.net/META-spec-v1.4.html
version: 1.4
extensions:
- thbbt
Later, say thbbt becomes an official part of 1.5:
---
thbbt: foo
meta-spec:
url: http://module-build.sourceforge.net/META-spec-v1.5.html
version: 1.5
At that point (v1.5), thbbt is probably not allowed in
'extensions' (because as an extension, it would conflict with a
now-official part of the spec.)
Wait, let's make 'extensions' a hash, thus allowing you to say which
(possibly competing) version of the thbbt extension you're using.
meta-spec:
...
extensions:
thbbt: http://welikethbbt.com/a_new_meta_attribute.html
So, ad-hoc extensibility which is ready-for-adoption without changing
the tools, all without namespace clashes?
(Concurrent usage of competing thbbt's is discouraged, but will be
handled via flame-war between the thbbt'ers as needed.)
--Eric
--
Consumers want choice, consumers want openness.
--Rob Glaser
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
