From: Clark C. E. <cc...@cl...> - 2004-09-14 00:03:20
|
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 !! 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 ~ * |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-14 00:12:06
|
On Monday 13 September 2004 08:03 pm, Clark C. Evans wrote: > =C2=A0 - Brian's proposal to reverse the meaning of ! and !! :( :[ :( :[ . . . =2D-=20 ( o _ =E3=82=AB=E3=83=A9=E3=83=81 // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: Sean O'D. <se...@ce...> - 2004-09-14 00:41:56
|
On Monday 13 September 2004 17:03, Clark C. Evans wrote: > > 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. Leave YAML where it is and start a completely different project based on it. Fork your own project, leave YAML at 100% compatibility with itself and do something 100% right from the ground up. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-14 01:21:10
|
On Mon, Sep 13, 2004 at 05:41:22PM -0700, Sean O'Dell wrote: | Leave YAML where it is and start a completely different project based | on it. Fork your own project, leave YAML at 100% compatibility with | itself and do something 100% right from the ground up. Sean, I don't believe anything can be "100% right from the ground up". YAML has been, and will continue to be developed by concensus. This may seem to produce inconsistent results and do so in an inefficient manner. I personally don't think any system I could make by my self would come out anywhere near as well as YAML, warts and all. Perhaps you are different, there are Einstein's out there. I'm just not one of them. I'm sticking with the process; and now that we are a bit more "mature", we probably need a tiny more control in our changes. That was the intent of this post. I do think it will limit our direction somewhat, however, I'm not certain that this would be, overall, a bad thing to keep in mind going forward. Cheers! Clark P.S. If you are looking for a 'new' project, I've got another one that will be starting soon (that I've poured about 12 months of effort into the first pass). If I get anywhere near as lucky as I've gotten with YAML, I'll be exceptionally happy. Alas, it's not even related to YAML (although it uses YAML heavily). |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-14 01:45:20
|
On Monday 13 September 2004 08:41 pm, Sean O'Dell wrote: > On Monday 13 September 2004 17:03, Clark C. Evans wrote: > > 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. > > Leave YAML where it is and start a completely different project based on > it. Fork your own project, leave YAML at 100% compatibility with itself a= nd > do something 100% right from the ground up. Woooooooooooooeeeeeeeeeeee!!!!!! Sean is <b>bold<b>! But really, how much would you do differently? Maybe allow for a bit more= =20 variety in data structures? Maybe get rid of implicit wart altogether?=20 Switch ! with !!. Clean up the syntax a little more. I don't really know = if=20 there's enough to justify a /\w+/AY. Unless you have some bold new direction.....=20 T. (ever heard of Z-spaces btw?) =2D-=20 ( o _ =E3=82=AB=E3=83=A9=E3=83=81 // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: Sean O'D. <se...@ce...> - 2004-09-14 03:26:40
|
On Monday 13 September 2004 18:45, trans. (T. Onoma) wrote: > On Monday 13 September 2004 08:41 pm, Sean O'Dell wrote: > > On Monday 13 September 2004 17:03, Clark C. Evans wrote: > > > 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. > > > > Leave YAML where it is and start a completely different project based on > > it. Fork your own project, leave YAML at 100% compatibility with itself > > and do something 100% right from the ground up. > > Woooooooooooooeeeeeeeeeeee!!!!!! > > Sean is <b>bold<b>! I was talking about Clark or someone in general forking it and creating an "ideal" version of YAML where backwards compatibility isn't one of the criteria. That way, people don't have their apps broken by some future version of YAML, and we're not prevented from applying ideas that depart too far from YAML proper. Some ideas I would try, though: Eliminate pre-typing strings and put all implicit typing into one phase. Scalars are just scalars until that phase. Domains; URL format. Shortcuts for domains instead of tags/prefixes. !shortcut!type means a type within a domain. !!shortcut means a type in the default domain. allow domains (!fulldomainurl!type) to appear in the document. No special syntax in header or anywhere else; YAML format always used. Tuples. Kinds would be only !!map, !!seq or !!scalar. Scalar styles would be only plain, literal or folded. Scalars have no type tag until the implicit phase. Implicit typing is not part of the spec; handled per implementation/language Quotes aren't character escapes but are parsed intact. Outer quotes means !!str and are stripped during the implicit typing phase. Domain shortcuts fully resolved when parsed. ...and anything else that comes up that sounds good, is neat and uniform, but which can't be put into YAML because of backwards compatibility. Sean O'Dell |
From: Rich M. <rd...@cf...> - 2004-09-14 04:35:58
|
At 8:26 PM -0700 9/13/04, Sean O'Dell wrote: >I was talking about Clark or someone in general forking it and creating an >"ideal" version of YAML where backwards compatibility isn't one of the >criteria. That way, people don't have their apps broken by some future >version of YAML, and we're not prevented from applying ideas that depart too >far from YAML proper. This is probably a fine idea, as long as (a) it can be kept away from the main line, official definition (call it "YAML 1.1x1" or some such) and (b) it doesn't distract the YAML implementers and language lawyers from advancing the state of the official version. My suggestion, however, would be to give the emerging definition a year (at least) of use before embarking on the fork. Otherwise, you won't really know what needs to be changed. -r -- email: rd...@cf...; phone: +1 650-873-7841 http://www.cfcl.com - Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series |
From: Oren Ben-K. <or...@be...> - 2004-09-14 05:56:59
|
On Tuesday 14 September 2004 03:03, Clark C. Evans wrote: > Backwards compability should not be broken unless there > is an obvious and significant advantage... +1 > 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. Sigh. OK, I'll now focus on #4 ("default strings") :-) > - Brian's proposal to reverse the meaning of ! and !! Brian will have smilodons. Also, I'd like to point out that his reason for reversing ! and !! was actually _increasing_ backward compatibility for all his files with !perl/Foo::Bar' tags that would have to be re-written as '!!Foo::Bar' tags. Have fun, Oren Ben-Kiki |
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 |
From: Clark C. E. <cc...@cl...> - 2004-09-14 16:49:32
|
On Tue, Sep 14, 2004 at 01:00:18AM -0700, Brian Ingerson wrote: | 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. I gave this quite a bit of thought the last day, and I do admit that 80% of the tag use cases (between ! and !! excluding !handle!) will be local. Further, I do perfer moving in this direction, however, I'm not sure if it meets the test, advantage: It reduces the 'clutter' for 80% of the tag uses, for a document littered with tags, this is a significant savings. transition: perl: Brian says that !!private tags were never used, and the only ! tags were prefixed with perl/Package::Name. Brian stated that he will probably keep this style. Thus, there really isn't a problem for perl, backwards or forwards. python: PyYaml never really used !yaml types, and relied solely on !!private tags. Unfortunately, it didn't emit a %YAML directive, so it won't be easy to auto-detect older documents. The transition path is to _always_ serialize YAML documents with %YAML 1.1 for the short run, and assume !! means private tag unless the %YAML directive appears. ruby: Ruby appears to be in the same situation as Python, the %YAML tag was not explicit, and !! was used for private tags. I suppose the same transition path is needed. importance: It may actually hurt YAML adoption if the common case always longer than necessary. I guess the important consideration is how large our user base has become. If we are under a few hundred, then perhaps it is worth the swap with a good transition plan. If we are in the thousands of users, well, it probably should stay as-is. ;( | 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. If we swap ! and !! there is no way it can remain YAML 1.0 as we have made the promise, even though the spec was not frozen, that it was only subject to 'tweaks'. Swapping ! and !! isn't a tweak. | 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. Regardless, it is a significant burden for Python people and perhaps i Ruby people as well. | 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. Ok. Then we _must_ carefully design a phase-in period. 1) If documents are explictly marked YAML 1.1 then ! is local, and !! is YAML. YAML processors will be enouraged to use the %YAML 1.1 directive to help reduce this sort of issue in the rare chance of future changes. 2) If unmarked, then !! is a warning for approximately a year or so (say 2005) when the warning will go away. The implementation will have to provide a flag to allow ! and !! to have %YAML 1.0 behavior. Does the Perl printer agree to put out %YAML 1.1 in your serializations? Certainly hand-edited config files are a different issue; but these rarely use !tags. | 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) This is fine. We need a bandaid, if you and Oren think this is the best alternative; then I'm perfectly happy. | All the other stuff below are big improvements. Go team. Nice. This means the original #11 proposal. The single ! has a 'magic' meaning per the 4th survey item, and the double !! is a syntax error. | 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! Agreed. But, some groups of users will have to be careful, and others will experience some transition pain. Best, Clark |
From: Clark C. E. <cc...@cl...> - 2004-09-14 16:57:35
|
Ok. There are two primary uses of YAML, - name: config file (human generated) desc: For configuration files, the application is well known, and data is not usually 'transactional' further humans are the editors. tags: Tags almost _never_ appear. - name: serialization (machine generated) desc: In this case, the application may not be known as well, data is probably a document of one sort of another, and humans may be reading it, but are not usually the authors. tags: Tags are common, if not frequent. So, I have a proposal for YAML 1.1 Use of the !tag is a syntax error _unless_ a %YAML X.X version number is present. We allow for %YAML 1.0 directive (using the new syntax) so that a 'patch' program can simply append '%YAML 1.0' to the front of each file. In this case, the old tag semantics are used. Thoughts? This makes all of the existing Ruby and Python YAML 1.0 documents 'errors' in YAML 1.1, and allows for a very simple way to 'patch' them for use in a YAML 1.1 setting. Best, Clark On Tue, Sep 14, 2004 at 12:49:31PM -0400, Clark C. Evans wrote: | On Tue, Sep 14, 2004 at 01:00:18AM -0700, Brian Ingerson wrote: | | 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. | | I gave this quite a bit of thought the last day, and I do admit | that 80% of the tag use cases (between ! and !! excluding !handle!) | will be local. Further, I do perfer moving in this direction, | however, I'm not sure if it meets the test, | | advantage: | It reduces the 'clutter' for 80% of the tag uses, for a | document littered with tags, this is a significant savings. | transition: | perl: | Brian says that !!private tags were never used, and the | only ! tags were prefixed with perl/Package::Name. Brian | stated that he will probably keep this style. Thus, there | really isn't a problem for perl, backwards or forwards. | python: | PyYaml never really used !yaml types, and relied solely on | !!private tags. Unfortunately, it didn't emit a %YAML | directive, so it won't be easy to auto-detect older documents. | The transition path is to _always_ serialize YAML documents | with %YAML 1.1 for the short run, and assume !! means private | tag unless the %YAML directive appears. | ruby: | Ruby appears to be in the same situation as Python, the | %YAML tag was not explicit, and !! was used for private tags. | I suppose the same transition path is needed. | importance: | It may actually hurt YAML adoption if the common case always | longer than necessary. | | I guess the important consideration is how large our user base | has become. If we are under a few hundred, then perhaps it is | worth the swap with a good transition plan. If we are in the | thousands of users, well, it probably should stay as-is. ;( | | | 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. | | If we swap ! and !! there is no way it can remain YAML 1.0 as we | have made the promise, even though the spec was not frozen, that | it was only subject to 'tweaks'. Swapping ! and !! isn't a tweak. | | | 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. | | Regardless, it is a significant burden for Python people and perhaps i | Ruby people as well. | | | 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. | | Ok. Then we _must_ carefully design a phase-in period. | | 1) If documents are explictly marked YAML 1.1 then ! is local, | and !! is YAML. YAML processors will be enouraged to use | the %YAML 1.1 directive to help reduce this sort of issue | in the rare chance of future changes. | | 2) If unmarked, then !! is a warning for approximately a year or | so (say 2005) when the warning will go away. The implementation | will have to provide a flag to allow ! and !! to have %YAML 1.0 | behavior. | | Does the Perl printer agree to put out %YAML 1.1 in your | serializations? Certainly hand-edited config files are a different | issue; but these rarely use !tags. | | | 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) | | This is fine. We need a bandaid, if you and Oren think this is | the best alternative; then I'm perfectly happy. | | | All the other stuff below are big improvements. Go team. | | Nice. This means the original #11 proposal. The single ! has a | 'magic' meaning per the 4th survey item, and the double !! is a | syntax error. | | | 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! | | Agreed. But, some groups of users will have to be careful, and | others will experience some transition pain. | | Best, | | 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 ~ * |
From: Oren Ben-K. <or...@be...> - 2004-09-14 19:08:06
|
On Tuesday 14 September 2004 19:57, Clark C. Evans wrote: > So, I have a proposal for YAML 1.1 > > Use of the !tag is a syntax error _unless_ a %YAML X.X > version number is present. > > We allow for %YAML 1.0 directive (using the new syntax) > so that a 'patch' program can simply append '%YAML 1.0' > to the front of each file. In this case, the old tag > semantics are used. > > Thoughts? Why needless complicate matters? I agree with Brian. We need to choose somethging good and move to it, and if that means a few pains in the transition, so be it. I'd hate to try to justify this particular arbitrary restriction in, say, a year from now. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-09-14 21:50:46
|
On Tue, Sep 14, 2004 at 10:07:58PM +0300, Oren Ben-Kiki wrote: | On Tuesday 14 September 2004 19:57, Clark C. Evans wrote: | > So, I have a proposal for YAML 1.1 | > Use of the !tag is a syntax error _unless_ a %YAML X.X | > version number is present. | | I'd hate to try to justify this particular | arbitrary restriction in, say, a year from now. I don't see the harm in requiring %YAML 1.1 if someone wants to use explicit tags. - it allows us to clearly detect YAML 1.0 documents, so that an adequate warning can be presented - if on the off chance we need to change this again (shudder) in 2014 then we won't be in the position of guessing what !!bing actually means. For config files, if you don't want to have the %YAML 1.1 then don't use ! tags. It's not that arbitrary. Cheers, Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-14 17:08:35
|
On Tuesday 14 September 2004 12:49 pm, Clark C. Evans wrote: > I guess the important consideration is how large our user base > has become. =C2=A0If we are under a few hundred, then perhaps it is > worth the swap with a good transition plan. If this turns out to be the case. Then that puts #1 back on the table too. = (?)=20 Or are we all set against it, now? I think if #1 were back, I might actually buy in to it. But I'm about to do= a=20 major point review to #1 - #4. So we'll see. =2D-=20 ( o _ =E3=82=AB=E3=83=A9=E3=83=81 // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: why t. l. s. <yam...@wh...> - 2004-09-14 17:09:40
|
I'll offer two parsers in Syck. This could significantly ease the transition, since the default parser would be 1.0 for a few months while the 1.1 parser gains stability. You would be able to use the 1.1 parser like so: yp = YAML::Parser::new( :version => '1.1' ) yp.load( "--- !private type" ) Same goes for the emitter. I'm not sure if I'll need separate loaders or not yet. I don't think I will. I'm not really worried about any of these changes causing migration problems. Everybody knows that version changes affect everybody. We just need to educate everybody, get the word out clearly. _why |