[OASIS Issue Tracker] Updated: (CAMP-86) Nature of YAML makes its suitability as a normative reference problematic

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/CAMP-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Otto updated CAMP-86:
----------------------------

    Proposal: Copy YAML 1.1 2008-01-18 as as a part of the CAMP work product, so it can be accessed through a stable reference that will not change.

> Nature of YAML makes its suitability as a normative reference problematic
> -------------------------------------------------------------------------
>
>                 Key: CAMP-86
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-86
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Public Review
>            Reporter: Gilbert Pilz
>            Priority: Critical
>
> Patrick Durusau raises some issues about the nature of YAML and its suitability as a normative reference here: https://lists.oasis-open.org/archives/camp-comment/201309/msg00010.html
> I noticed the *normative* reference to YAML under 1.8 Normative
> References.
> Not being familiar with it, I followed the link.
> - From "Status of this Document" I read:
> *****
> This specification is a draft reflecting consensus reached by members
> of the yaml-core mailing list. Any questions regarding this draft
> should be raised on this list. We expect all further changes to be
> strictly limited to wording corrections and fixing production bugs.
> *****
> So the YAML normative reference is to a draft dated 2005-01-18, that
> reflects a "consensus" of members of a mailing list.
> Is that a fair characterization?
> There is no formal organization charged with its maintenance and no
> known process other than email "consensus" as far as any changes?
> As I said in a post earlier today:
> **********
> First, draft work should never be used in normative references at all.
> Under any circumstances. As the TC Process notes (Section 1, w:):
> *****
> "Normative Reference" means a reference in a Standards Track Work
> Product to an external document or resource with which the implementer
> must comply, in order to comply with a Normative Portion of the Work
> Product.
> *****
> Note the "must comply" language.
> Drafts by their very nature change and reliance on a draft invites a
> lack of interoperability.
> **********
> - From examining the draft it is clear that conformance to YAML, a
> mailing list consensus draft, is critical for use of this standard.
> The only solution that comes to mind, given that YAML states it can be
> copied if not modified, would be to include a copy of YAML 1.1 as an
> appendix and cite that appendix as your normative reference.
> That fixes the text of YAML 1.1 to be what is included in the appendix
> and provides implementers with a stable target for their implementations.
> If YAML has not been modifed since its "final draft" date of
> 2005-01-18, it should be stable enough to not burden the TC with too
> many maintenance duties.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira