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] Commented: (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:comment-tabpanel&focusedCommentId=35285#action_35285 ] 

Adrian Otto commented on CAMP-86:
---------------------------------

Patrick Durusau expresses the following two concerns:

1) There is no formal organization charged with maintenance of YAML 1.1
2) There is no known process other than email "consensus" for changes.

To address each:

1) There is no formal organization charged with maintenance of YAML 1.1

Our reference draft of YAML 1.1 has not changed since 2005-01-18. That was nearly 9 years ago. No maintenance of the spec is required. We can include a copy of the 2005-01-18 draft as part of our work product to have confidence that the reference will be accessible for as long as CAMP 1.1 is.

2) There is no known process other than email "consensus" for changes.

Our reference draft of YAML 1.1 clearly states "We expect all further changes to be strictly limited to wording corrections and fixing production bugs." That means there will be no material changes to that document. We can continue to reference the 2005-01-18 draft as part of our work product.

We are assigning an action item for Martin to follow up with the TC Admin to determine if we can simply include a copy of the 2005-10-18 as part of our work product so it can be referenced by CAMP.

Note that TOSCA is also considering YAML support in their spec, and is widely used in orchestration systems, including those based on open source. Solving this for CAMP will also solve it for other OASIS TC's.

> 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]