Next in thread →
Next in month →
Re: [camp] YAML 1.1
On Thu, Nov 7, 2013 at 8:30 AM, Martin Chapman <> wrote: Thanks Robin. Jamie/Robin sounds like we could write this up in a general way should another TC stumble across a similar document it needs to reference. Thanks, Martin. A writeup is possible, but I'm not sure motivated, as the CAMP-YAML-v1.1 situation is (I think) a rare exception, occasioned by the confluence of several factors. In the general case there's a well known community of participants committed to their informal spec work, and multiple spec copies on various servers... If such a spec goes AWOL (e.g., lights out on an Internet domain), it's detected quickly, and the authors/editors are young people (still alive!, with contact email addresses!), so recovery is highly likely. I suspect that could we know -- by fiat or by running some tests -- a lot of published OASIS specs/standards make normative reference by URL to assets that are 404'd at the published location, and in cases where we are (sic!) surprised that such a reputable organization has abandoned its (expected) commitment to data availability. I'd probably prefer not to elevate the CAMP-YAML-v1.1 use case to template a generalized solution to the perceived risk. - Robin Martin. From: Robin Cover [mailto:] Sent: 07 November 2013 02:33 To: Gilbert Pilz Cc: Alex Heneveld; Anish Karmarkar; Adrian Otto; Jamie Clark; <>; Chet Ensign; Carol Geyer Subject: Re: [camp] YAML 1.1 On Wed, Nov 6, 2013 at 7:49 PM, Gilbert Pilz <> wrote: Robin, Many thanks for all your help. I am naught but a lowly editor and I have a practical question: what does it mean to "include the yaml.org URIs in the text of the specification References"? I'm not sure what you mean by "dual URI references". Right now our YAML reference looks like this: [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/ What would it look like if we used a "dual URI reference"? ~ gp OK: something like: [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. Does that seem OK to you? Further, FYI: If someone has a better suggestion, than the above that's great. In a few months, we may have stronger prescriptions/recommendations about how to create "best-practice" References, but for now, we have none -- other than cultural expectations in SSO/SDO arenas. We hope to provide some citation libraries -- as per IETF and W3C -- so that TC editors can simply SELECT references from a list, and then populate the spec References section with a select-copy-paste gesture, or equivalent, to stop the madness of making software engineers become bibliography format geeks. (How stupid is that?) My POV -- since the great "descriptive-markup qua be-verbose/explicit paradigm shift -- exemplified in descriptive markup (1967-1981): explicit information almost always trumps brevity. So: we include editors' names. Don't make someone else do the research, for pity's sake. So: your formulation "Oren Ben-Kiki, Clark Evans, Brian Ingerson" is very interesting, and even encouraging to me. At this moment, Staff (and TAB) are considering how to enhance the recommended citations for OASIS specifications in spec sections "Normative References" and "Non-Normative References", as well as in the model "Citation format:" block. At the moment, we do not cite spec editors, but it's very common practice to do so. The "YAML" spec reference above illustrates one use case where omission of editors names would be odd (IMO: deficient) bibliographically. So also W3C and IETF, and many others. We're working on it... :-) At your service! Cheers, - Robin On Nov 6, 2013, at 5:13 PM, Robin Cover <> wrote: On Wed, Nov 6, 2013 at 6:28 PM, Alex Heneveld <> wrote: Anish- Yes, you are quite correct -- either I didn't mean contribute in the OASIS sense or I don't know exactly what that means or both. In any case I will let the YAML authors know that the problem is resolved and that permanent archives are also available at http://xml.coverpages.org/yaml.txt . Robin- +1 thanks Anish and Alex: I think you are on a reasonable path to justify normative reference to YAML (whatever version you want: 1.0, 1.1, 1.2) in your CAMP specification. I agree with the initial concern that the target of a normative reference in an OASIS spec be something identifiable (have identity), discoverable/accessible, and stable. I agree with Jamie not only in the matter of suggesting that "YAML" can qualify, but I agree with the position that OASIS has taken to date, viz., that we levy no fixed requirements on what may [not] be cited as a "normative" reference in an OASIS specification. Some other SSOs/SDOs do so -- in great detail -- and I respect their motivations and practices. I even understand them :-) In the OASIS context, I think we are best served by allowing the members, as participants in the TCs, to make a decision about what qualifies as candidate for "normative." We all know that identity, findability, stability, and verifiable authenticity are desirable. Beyond that: I don't think we can "know" what other features MUST be present to determine whether a spec is worthy of a normative reference. So: I very much like the current OASIS practice and (lack of) policy on this matter. One notes, in this connection, that many SSOs/SDOs allow for "undated" references, where the Normative Reference specification is a moving target. I understand the rationale, and respect the practice, but it illustrates that attempts at ultimate determinism are variable in their effectiveness: "For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies." [ECMA ref example] - see also IEEE, ISO/IEC, OGC,... Alex, thank you for the word "also" in your formulation "...permanent archives are ALSO available at..." I trust the authors/editors of the YAML spec to provide continuity and longevity for access to their specification, so (IMO) the CAMP TC should not do or say anything to imply that the canonical references now at "yaml.org" are anything other than (also) "permanent" in some effective sense. I'm glad to provide stable URI references via the Cover Pages, which you are welcome to cite in "Normative References", but I would urge that your TC honor the primary/canonical sources by including those (yaml.org) URIs in the text of the specification References. OASIS TC Admin has no practice of deprecating dual URI references which serve as locators (URLs). Please let me know of there are other issues: I think you are heading down a good path. Thanks to Jamie and others who have identified the issues and provided the basis for reasonable solutions. Cheers, - Robin Best Alex On 07/11/2013 00:22, Anish Karmarkar wrote: On 11/6/13 4:10 PM, Alex Heneveld wrote: Feedback from Ingy dot Net (one of the authors) is that he expected they'd be happy for OASIS to host a copy, and he'd canvas the 2 other co-authors. But I haven't heard from them, nor had the chance to chase them. Don't think we need permission anyway, for any of us to contribute a copy of it to OASIS, as its license permits copying. I think we do need permission if it is to be considered a contribution. The copyright permits copying/hosting of the spec, but is mute on other IPR implications (eg patents, derivative works). For a TC member to make a contribution requires that the TC member ascertain that they have the appropriate rights. I suspect you didn't mean to say "contribution" the way it is used in OASIS that allows the TC to incorporate it in a spec or make derivative works. But more importantly OASIS (via coverpages.org) has already hosted the spec, so I think it would be sufficient for us to use the coverpages.org URL in our reference. -Anish -- (FWIW the three yaml co-authors each own one of yaml.{org,com,net} plus copies on github and other archives so I don't think they are personally concerned about it being lost.) Best Alex On 06/11/2013 23:54, Anish Karmarkar wrote: Sounds like Robin has already solved our problem! :-) -Anish -- On 11/6/13 3:28 PM, Robin Cover wrote: Seems to me that all of the options will work, in terms of providing stable resources. As further backup, the archives copies as cited below may be useful. Authors sometimes write me to say "Thanks for archiving my paper on the Cover Pages: it's the only surviving copy I could find on the Internet!" ;-) http://xml.coverpages.org/yaml.txt http://xml.coverpages.org/yaml-spec-v1.0-archive-copy.html http://xml.coverpages.org/yaml-spec-v1.1-archive-copy.html http://xml.coverpages.org/yaml-spec-v1.2-archive-copy.html Cheers, - Robin On Wed, Nov 6, 2013 at 4:37 PM, Adrian Otto < <mailto:>> wrote: Jamie, Thanks so much for helping us address this concern. I really like part of option 3, which would be for YAML's authors to post the spec to github. That requires minimal participation from them, and solves the reference stability problem. It is also much cleaner than a rights transfer. Adrian On Nov 7, 2013, at 5:58 AM, Jamie Clark < <mailto:>> wrote: Dear colleagues: We understand that the TC is interested in invoking an externally-developed markup language (or similar methodology) called YAML, as part of an OASIS specification. However, the TC wishes to ensure that a stable copy can be properly provided and "secured" at a known URL ... so that your TC's work product does not point to a URL space that might become empty in the future. As a "normative reference" used within the CAMP specs, its IPR issues and similar considerations for the OASIS spec are well documented in our rules, and as we have been advised, are understood by your committee. YAML may have no clear terms or licensing; but generally speaking, the TC is free to elect to reference it normatively, as its technical decision, just as it might other non-standards-track and perhaps-unlicensed works like RFC 4627. However, this spec currently resides at */http://yaml.org/spec/1.1//*, which unlike IETF RFCs, is a private website of unknown provenance and some age. OASIS as a standards host and publisher can only publish, display and re-use material that some party assures us, under our rules, that we have sufficient rights to re-post and use. * Our IPR Policy assures us that we get those rights, for CONTRIBUTIONS from a member. But as you know, that member must ascertain for itself that it has the right to make that contribution to the TC, and then make it. * Our policies also permit members or nonmembers to make explicit contributions into a TC via our PUBLIC COMMENT facility; but here too, the commenter takes upon itself the responsibility for the permissions needed to do so. For example, open source material can be taken in, this way, by a member or commenter who does so -- in reliance on a sufficient ASF Apache license, nonassertion covenant or similar general unconditional permission. Other than by those two methods, OASIS TCs cannot re-publish the work of other entities. One reason is that its inclusion in the TC's document repository, generally, would be misleading -- putting it there is the equivalent of claiming that the OASIS TC has the usual OASIS rights to re-publish, re-use and derive from it. We suggest that your TC or its members may have four options to up-grading the stability of the cite for */yaml.org <http://yaml.org/>/*: 1. Seek YAML's authors' permission to contribute it into your TC, thus giving it a longer archival life, among other things. 2. Seek YAML's authors' permission to make it its own TC, with mostly the same outcome, except that this would make it more *generally* available, not just to CAMP. 3. Encourage them to re-post it to some other more archivally-predictable source, like GitHub or, if our communications staff can identify a proper case for it, the auxiliary sites we manage outside of the scope of our IPR policy, such as */xml.org <http://xml.org/> or /**xml.coverpages.org <http://xml.coverpages.org/>*. I have copied Carol Geyer and Robin Cover here, to see whether such a solution might be available. 4. Review the rights available in the YAML work (which may include additional declarations or reservations not known to me) and conclude that an OASIS member holds, or can acquire, the rights itself to do #1, #2 or #3. Please let us know if we can assist with any of these approaches; as informally discussed, we're happy to chat with the YAML folks if that would be useful. Cordially, Jamie James Bryce Clark, General Counsel OASIS: Advancing open standards for the information society http://www.oasis-open.org/who/staff.php#clark www.identi.ca/JamieXML <http://www.identi.ca/JamieXML> www.twitter.com/JamieXML <http://www.twitter.com/JamieXML> http://t.sina.cn/jamiexml http://www.slideshare.net/jamiexml http://facebook.com/oasis.open -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: <mailto:> Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783 -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: Staff bio: http://www.oasis-open.org/people/staff/robin-cover Cover Pages: http://xml.coverpages.org/ Newsletter: http://xml.coverpages.org/newsletterArchive.html Tel: +1 972-296-1783
Next in thread →
Next in month →