OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Gilbert Pilz updated CAMP-86:

Amend the YAML 1.1 reference to read:

[YAML 1.1] Oren Ben-Kiki, Clark Evans, Brian Ingerson, "YAML Ain't Markup Language (YAML) Version 1.1" http://yaml.org/spec/1.1/.  Also archived at: http://xml.coverpages.org/yaml.txt.

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

Updated proposal to reflect the consensus of the conversation between the TC, Jamie Clark, and Robin Cover.

> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]