From: Brian I. <in...@tt...> - 2004-09-14 09:07:03
|
On 13/09/04 20:03 -0400, Clark C. Evans wrote: > I had a chat with a few more friends regarding if and when it > is appropriate to break backward compability. I heard a > consistent story: > > Backwards compability should not be broken unless there > is an obvious and significant advantage, the transition > is dooable without ambiguity, and the product would be > significantly hobbled without the break. > > Clearly, the older and widespread a technology becomes, the more > difficult this criteria is to meet. A side issue raised in this > conversation was the precident that is being set -- if we break > compatibility without a very compelling reason, it will be harder > to convince others to continue adoption or to try the next version > for fear that the rug may be pulled out from under them. > > With this criteria, there are two proposals under consideration > which don't make the grade: > > - Oren and my proposal to remove the 'plain scalar wart', > in other words, make 23 and '23' identical. > > - Brian's proposal to reverse the meaning of ! and !! My perspective... YAML 1.0 is a great language. The only things I felt queasy about were tags and directives. Now I don't feel queasy. We have gotten them (or are very close to getting them) to be as nice as all the other things that we've gotten very nice. There are early adopters, and I respect that. But I see YAML as still in its infancy. There is only one really good implementation right now, the Ruby one. And since we have Why's support to go ahead and do the right thing, I am all for doing it. To be honest I really don't anticipate a YAML 1.2. And we could still call this one YAML 1.0 since we never froze the spec. But my gut is that 1.1 is the right move. As far as ! vs !! is concerned, I don't see it as a reversal per se. The term "Private tags" means something totally different to me than it did in YAML 1.0. I see now that private tags are the things that you are using all the time when you mint your own types in private applications. YAML types almost always have implicits, so it is very rare to use the !!int. And !! is shouting that "I MEAN THE YAML INT, DAMMIT". Anyway I feel very strongly to use this new meaning for 1.1. I think that Oren's 4th survey item is very close to YAML 1.0 and makes 23 and '23' different as they were before. But it keeps the plain scalar flag out, which is cool. (Especially for Oren) All the other stuff below are big improvements. Go team. If you look at the big picture through a fuzzy lens, the YAML spirit hasn't changed one bit from 1.0 to 1.1. It's just gotten better. I don't see anybody that we are truly screwing over with these things. So let's move forward! Cheers, Brian > Neither of these items have a "significant advantage", in both cases > transition is somewhat "ambiguous", and YAML will be just fine if we > leave both as-they-be. So, while the discussion of the merits for > these has been nice, I humbly suggest they were academic excersizes. > > ... > > As for the other proposals: > > - > name: prologue > advantage: > Allows a set of directives to apply to a series of > documents without duplication > transition: > Per-document directives are easy to detect, unambiguous > and straight-forward to convert; breaking compatibility > does not have a significant cost > importance: > Per-document directives (instead of per-stream) will > actually hobble development; it prevents a good %TAG > directive from being used in log files and transaction > streaming applications > - > name: %TAG directive > advantage: > Allows for very long global tags to be used in a mixed-schema > environment; makes documents in this scenerio significantly > easy to manage and read. > transition: > New tag, no problem with compatibility; the use of ^ can be > depreciated and transitioned without ambiguity. This proposal > changes some of the cooking rules for xxx/xxx YAML tags. > However, these cases can be detected and transitioned. > importance: > The %TAG mechanism is better equipped to handle unique > tag complexity over the ^ mechanism. On the whole, one > could leave the ^ mechanism in place. > - > name: bandaid > description: > One of the many proposals (not #4) for better specification > of how the plain scalar flag should be used; in particular, > helping to work out API differences to help build a unified > understanding of this exception. > advantage: > Current specificiation is quite vague in this regard, and > the one could read this as requiring a "isPlain()" flag on > each node. This is clearly not desireable. This makes > the behavior uniform across parsers so that use of plain > scalars is portable. > transition: > Existing documents need not be transitioned; however, some > APIs may need change. Overall, this is not a huge deal. > importance: > If each platform does plain scalar handling differently > it could hinder YAML document portability. This is a > serious concern. > > That's it. So, in short, I think the other ones are accepted by > the criteria, but the one I'm most in favor of doesn't pass muster. > Such is life. Interestingly enough, the -1s have largely been > on the two issues which break compatibilty. No suprise, I guess. > > Cheers! > > Clark > > -- > Clark C. Evans Prometheus Research, LLC. > http://www.prometheusresearch.com/ > o office: +1.203.777.2550 > ~/ , mobile: +1.203.444.0557 > // > (( Prometheus Research: Transforming Data Into Knowledge > \\ , > \/ - Research Exchange Database > /\ - Survey & Assessment Technologies > ` \ - Software Tools for Researchers > ~ * > -- > Clark C. Evans Prometheus Research, LLC. > http://www.prometheusresearch.com/ > o office: +1.203.777.2550 > ~/ , mobile: +1.203.444.0557 > // > (( Prometheus Research: Transforming Data Into Knowledge > \\ , > \/ - Research Exchange Database > /\ - Survey & Assessment Technologies > ` \ - Software Tools for Researchers > ~ * > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |