Grokbase › Groups › Perl › cpan-workers › October 2009
FAQ
02. Formally switch to "YAML Tiny"

Proposal:

Change the language referring to "YAML" to instead refer to "YAML Tiny" and
update the specification URL to point to the YAML Tiny specification.
(AdamKennedy)

Comments

* "YAML Tiny" is a subset-specification in the style of the "SVG Tiny"
specification [http://www.w3.org/TR/SVGTiny12/]. It just happens to be in
a module called YAML::Tiny, but a YAML Tiny parser is in the core as
Parse::CPAN::Meta. This parser also adds a few illegal edge cases like
the current illegal #YAML:1.0 version declarator (which no longer looks
like this).

* The creation of configure_requires stalled because of the need for a YAML
parser in the core to parse META.yml. All current full YAML parsers were
buggy or too large, and we don't use most of the features of YAML anyway.
The result was that the 5.10.1 contains a parser tailored to the needs of
META.yml. (AdamKennedy)

Search Discussions

  • Ricardo Signes at Oct 9, 2009 at 12:11 pm ⇧
    * David Golden [2009-10-09T07:42:06]
    02. Formally switch to "YAML Tiny"

    Proposal:

    Change the language referring to "YAML" to instead refer to "YAML Tiny" and
    update the specification URL to point to the YAML Tiny specification.
    (AdamKennedy)
    Accept with modification: YAML Tiny should be as the specification for
    YAML-like META files, which should be deprecated in favor of META files encoded
    in JSON.

    --
    rjbs
  • Graham Barr at Oct 9, 2009 at 1:24 pm ⇧

    On Oct 9, 2009, at 7:11 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:42:06]
    02. Formally switch to "YAML Tiny"

    Proposal:

    Change the language referring to "YAML" to instead refer to "YAML
    Tiny" and
    update the specification URL to point to the YAML Tiny specification.
    (AdamKennedy)
    Accept with modification: YAML Tiny should be as the specification for
    YAML-like META files, which should be deprecated in favor of META
    files encoded
    in JSON.
    +1

    Graham.
  • David Golden at Oct 9, 2009 at 1:38 pm ⇧

    On Fri, Oct 9, 2009 at 8:11 AM, Ricardo Signes wrote:
    * David Golden [2009-10-09T07:42:06]
    02. Formally switch to "YAML Tiny"

    Proposal:

    Change the language referring to "YAML" to instead refer to "YAML Tiny" and
    update the specification URL to point to the YAML Tiny specification.
    (AdamKennedy)
    Accept with modification: YAML Tiny should be as the specification for
    YAML-like META files, which should be deprecated in favor of META files encoded
    in JSON.
    Agreed, assuming JSON is agreed as the spec going forward.
  • David E. Wheeler at Oct 9, 2009 at 10:25 pm ⇧

    On Oct 9, 2009, at 6:37 AM, David Golden wrote:

    Accept with modification: YAML Tiny should be as the specification
    for
    YAML-like META files, which should be deprecated in favor of META
    files encoded
    in JSON.
    Agreed, assuming JSON is agreed as the spec going forward.
    +1m though I have no opinion on switching to JSON.

    David
  • Steffen Mueller at Oct 9, 2009 at 2:05 pm ⇧

    Ricardo Signes wrote:
    * David Golden [2009-10-09T07:42:06]
    02. Formally switch to "YAML Tiny"

    Proposal:

    Change the language referring to "YAML" to instead refer to "YAML Tiny" and
    update the specification URL to point to the YAML Tiny specification.
    (AdamKennedy)
    Accept with modification: YAML Tiny should be as the specification for
    YAML-like META files, which should be deprecated in favor of META files encoded
    in JSON.
    Certainly, everyone involved in this is aware of this, but let me state
    one time for the record YAML::Tiny minus dumping == Parse::CPAN::Meta.
    This assertion holds now and will in future. For this reason, I am
    *strongly in favour* of defining the YAML-based META files as using this
    subset/dialect of YAML.

    As for adopting JSON as the default format: What's the chances of
    including a full JSON parser in core?
    IIRC the main reason against including a full YAML parser in core was
    that they're all different and likely broken in subtle or not so subtle
    ways. Certainly, they're all dead-and-wrong or in flux (both of which is
    bad for perl core). I understand this criterion does not apply to JSON?

    Cheers,
    Steffen
  • Ricardo Signes at Oct 9, 2009 at 2:53 pm ⇧
    * Steffen Mueller [2009-10-09T10:04:44]
    As for adopting JSON as the default format: What's the chances of
    including a full JSON parser in core?
    I believe they are good. JSON.pm has no weird prereqs, works admirably, and
    the author has no objections.

    --
    rjbs
  • Steffen Mueller at Oct 9, 2009 at 3:10 pm ⇧

    Ricardo Signes wrote:
    * Steffen Mueller [2009-10-09T10:04:44]
    As for adopting JSON as the default format: What's the chances of
    including a full JSON parser in core?
    I believe they are good. JSON.pm has no weird prereqs, works admirably, and
    the author has no objections.
    Cool, then count me in. This increases the coreification chances by a lot.

    Steffen
  • David Golden at Oct 9, 2009 at 9:27 pm ⇧

    On Fri, Oct 9, 2009 at 10:04 AM, Steffen Mueller wrote:
    Certainly, everyone involved in this is aware of this, but let me state one
    time for the record YAML::Tiny minus dumping == Parse::CPAN::Meta. This
    assertion holds now and will in future. For this reason, I am *strongly in
    favour* of defining the YAML-based META files as using this subset/dialect
    of YAML.
    Worse, M::B::YAML in core is an ancient adaptation of YAML.pm. In the
    M::B repo, it's a now a rebadged YAML::Tiny minus some function
    exports. So we're wedging all of YAML::Tiny into core anyway, but not
    pretending core really won't have YAML. Madness.
    As for adopting JSON as the default format: What's the chances of including
    a full JSON parser in core?
    I hope that if this process for Meta 2.0, with the working group and
    broader input we have, resolve that the CPAN Meta spec needs JSON.pm
    in core, then we stand a much better chance of making that happen.

    (And if not, we'll hide JSON.pm the same way we did YAML::Tiny.)

    -- David
  • Jarkko Hietaniemi at Oct 9, 2009 at 2:44 pm ⇧

    Change the language referring to "YAML" to instead refer to "YAML Tiny" and
    update the specification URL to point to the YAML Tiny specification.
    (AdamKennedy)
    Accept with modification: YAML Tiny should be as the specification for
    YAML-like META files, which should be deprecated in favor of META files encoded
    in JSON. +1.
    --
    rjbs


    --
    There is this special biologist word we use for 'stable'. It is
    'dead'. -- Jack Cohen
  • Ricardo Signes at Oct 10, 2009 at 2:34 am ⇧
    * David Golden [2009-10-09T07:42:06]
    02. Formally switch to "YAML Tiny"
    Branch available: http://github.com/rjbs/cpan-meta-spec/commits/02-yamltiny

    --
    rjbs
  • David Golden at Oct 10, 2009 at 11:05 am ⇧

    On Fri, Oct 9, 2009 at 10:34 PM, Ricardo Signes wrote:
    * David Golden [2009-10-09T07:42:06]
    02. Formally switch to "YAML Tiny"
    Branch available: http://github.com/rjbs/cpan-meta-spec/commits/02-yamltiny
    If we only make this change and not JSON, that's fine.

    I think a longer section will eventually be necessary to explain
    serialization options (if there are any) and what clients are expected
    to do wrt to deserialization and validation.

    David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:42a
activeOct 10, '09 at 11:05a
posts12
users6
websitecpan.org

6 users in discussion

David Golden: 4 posts Ricardo Signes: 3 posts Steffen Mueller: 2 posts David E. Wheeler: 1 post Graham Barr: 1 post Jarkko Hietaniemi: 1 post

Content

People

Support

Translate

site design / logo © 2021 Grokbase