FAQ
34. Formally reserve keys for private 'in-house' use

Proposal:

For in-house, non-CPAN use, it would be nice to be able to extend META.yml
to contain extra keys and data, but any extensions that we choose to make
may one day clash with an official key not yet introduced.

For this reason I'd like to formally define the acceptance of 'x-' prefixed
key names. Clients that validate META.yml should ignore any and all keys
starting with 'x-' and those keys should be formally declared as never
being used in future extensions to the spec.

Comments:

* This seems like a fairly good way to allow experimentation with new
features without changing the spec, and pretty non-controvertial in
general --Adam K

* I thought this was what key names containing a capital letter did?
CSJewell

Search Discussions

  • Ricardo Signes at Oct 9, 2009 at 1:20 pm
    * David Golden [2009-10-09T07:56:46]
    34. Formally reserve keys for private 'in-house' use

    Proposal:

    For in-house, non-CPAN use, it would be nice to be able to extend META.yml
    to contain extra keys and data, but any extensions that we choose to make
    may one day clash with an official key not yet introduced.
    [...]

    * I thought this was what key names containing a capital letter did?
    CSJewell
    Me, too. If not, let's do that instead of X-.

    --
    rjbs
  • Graham Barr at Oct 9, 2009 at 2:42 pm

    On Oct 9, 2009, at 8:20 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:56:46]
    34. Formally reserve keys for private 'in-house' use

    Proposal:

    For in-house, non-CPAN use, it would be nice to be able to extend
    META.yml
    to contain extra keys and data, but any extensions that we choose
    to make
    may one day clash with an official key not yet introduced.
    [...]

    * I thought this was what key names containing a capital letter did?
    CSJewell
    Me, too. Me too
    If not, let's do that instead of X-.
    personally I dislike the case distinction and would rather switch to
    using x- prefixes which are used in so many other places to mean
    private extensions

    Graham.


    phew - did I get to the end :)
  • Ricardo Signes at Oct 9, 2009 at 3:06 pm
    * Graham Barr [2009-10-09T10:42:17]
    personally I dislike the case distinction and would rather switch to
    using x- prefixes which are used in so many other places to mean private
    extensions
    I agree, but I also don't like the idea of "in this zone of the struct, case
    determines authority; elsewhere it is the x- prefix."

    --
    rjbs
  • David E. Wheeler at Oct 9, 2009 at 7:00 pm

    On Oct 9, 2009, at 8:06 AM, Ricardo Signes wrote:

    personally I dislike the case distinction and would rather switch to
    using x- prefixes which are used in so many other places to mean
    private
    extensions
    I agree, but I also don't like the idea of "in this zone of the
    struct, case
    determines authority; elsewhere it is the x- prefix."
    Agreed, as long as it's consistent. I like [xX]-.

    David
  • David Golden at Oct 9, 2009 at 9:18 pm

    On Fri, Oct 9, 2009 at 3:00 PM, David E. Wheeler wrote:
    On Oct 9, 2009, at 8:06 AM, Ricardo Signes wrote:

    personally I dislike the case distinction and would rather switch to
    using x- prefixes which are used in so many other places to mean private
    extensions
    I agree, but I also don't like the idea of "in this zone of the struct,
    case
    determines authority; elsewhere it is the x- prefix."
    Agreed, as long as it's consistent. I like [xX]-.
    I agree as well: [xX]- and remove case-sensitivity rule

    -- David
  • Steffen Mueller at Oct 9, 2009 at 3:09 pm

    Graham Barr wrote:
    * David Golden [2009-10-09T07:56:46]
    34. Formally reserve keys for private 'in-house' use
    personally I dislike the case distinction and would rather switch to
    using x- prefixes which are used in so many other places to mean private
    extensions +1
    Graham.


    phew - did I get to the end :)
    +1

    Steffen
  • Barbie at Oct 31, 2009 at 7:09 pm

    On Fri, Oct 09, 2009 at 09:20:37AM -0400, Ricardo Signes wrote:
    * David Golden [2009-10-09T07:56:46]
    34. Formally reserve keys for private 'in-house' use

    Proposal:

    For in-house, non-CPAN use, it would be nice to be able to extend META.yml
    to contain extra keys and data, but any extensions that we choose to make
    may one day clash with an official key not yet introduced.
    [...]

    * I thought this was what key names containing a capital letter did?
    CSJewell
    Me, too. If not, let's do that instead of X-.
    Agreed.

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • Zefram at Oct 12, 2009 at 9:33 am

    David Golden wrote:
    For this reason I'd like to formally define the acceptance of 'x-' prefixed
    key names.
    Good concept, but I think "x_" would be a better prefix than "x-".
    We've already established usage of "_" to separate words, making the
    top-level hash keys satisfy identifier syntax. (Except for "meta-spec",
    which is an ugly exception.)

    -zefram
  • David Golden at Oct 12, 2009 at 2:08 pm

    On Mon, Oct 12, 2009 at 5:33 AM, Zefram wrote:
    David Golden wrote:
    For this reason I'd like to formally define the acceptance of 'x-' prefixed
    key names.
    Good concept, but I think "x_" would be a better prefix than "x-".
    We've already established usage of "_" to separate words, making the
    top-level hash keys satisfy identifier syntax.  (Except for "meta-spec",
    which is an ugly exception.)
    I don't have a strong feeling about "x_" vs "x-". The former is more
    consistent with the naming pattern of the spec and the latter is more
    consistent with how extension fields are named in a lot of RFCs.

    Unfortunately, "meta-spec" is the one field we *can't* change when we
    upgrade to 2.0. :-)

    -- David
  • Zefram at Oct 12, 2009 at 2:14 pm

    David Golden wrote:
    I don't have a strong feeling about "x_" vs "x-". The former is more
    consistent with the naming pattern of the spec and the latter is more
    consistent with how extension fields are named in a lot of RFCs.
    "x-" is used in a lot of RFCs where field names generally use "-" as
    a separator. There's also "x." in MIME media subtypes, under the new
    system where "." is used as a hierarchical separator. ("x-" was used in
    the same place under the older, flat, form of the namespace, where "-"
    is commonly used as a word separator.) The consistent feature of this
    pattern is using "x" as the leading component of a multi-component name;
    the component separator is an orthogonal issue.

    -zefram
  • David Golden at Oct 31, 2009 at 8:08 pm

    On Mon, Oct 12, 2009 at 10:08 AM, David Golden wrote:
    On Mon, Oct 12, 2009 at 5:33 AM, Zefram wrote:
    David Golden wrote:
    For this reason I'd like to formally define the acceptance of 'x-' prefixed
    key names.
    Good concept, but I think "x_" would be a better prefix than "x-".
    We've already established usage of "_" to separate words, making the
    top-level hash keys satisfy identifier syntax.  (Except for "meta-spec",
    which is an ugly exception.)
    I don't have a strong feeling about "x_" vs "x-".  The former is more
    consistent with the naming pattern of the spec and the latter is more
    consistent with how extension fields are named in a lot of RFCs.
    Since no one has strong feeling about it, the new rule shall be qr{^x[_-]}i.

    Patch here:

    http://github.com/dagolden/cpan-meta-spec/tree/34-private-keys

    -- David
  • Adam Kennedy at Nov 2, 2009 at 11:57 pm
    I'd prefer we avoid pointless flexibility.

    Recommend we pick one, and since underscore requires less quoting and
    can be used as part of a method name, recommend we go with that.

    Adam K
    On Sun, Nov 1, 2009 at 7:07 AM, David Golden wrote:
    On Mon, Oct 12, 2009 at 10:08 AM, David Golden wrote:
    On Mon, Oct 12, 2009 at 5:33 AM, Zefram wrote:
    David Golden wrote:
    For this reason I'd like to formally define the acceptance of 'x-' prefixed
    key names.
    Good concept, but I think "x_" would be a better prefix than "x-".
    We've already established usage of "_" to separate words, making the
    top-level hash keys satisfy identifier syntax.  (Except for "meta-spec",
    which is an ugly exception.)
    I don't have a strong feeling about "x_" vs "x-".  The former is more
    consistent with the naming pattern of the spec and the latter is more
    consistent with how extension fields are named in a lot of RFCs.
    Since no one has strong feeling about it, the new rule shall be qr{^x[_-]}i.

    Patch here:

    http://github.com/dagolden/cpan-meta-spec/tree/34-private-keys

    -- David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:57a
activeNov 2, '09 at 11:57p
posts13
users8
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase