[Yaml-core] Forgotten Point

 [Yaml-core] Forgotten Point From: trans. (T. Onoma) - 2004-09-14 11:29:48 ```Somehow everyone has rallied behind Oren's proposal. And I understand the=20 inclination. The same notion had occurred to me a couple of times. But I=20 realized that it's actually a trap easy to fall into. Let me explain.=20 I think Brian's shower assessment puts it nicely: ``Today in the shower, I thought to myself "I really must assert that quoted things should be strings". I don't care how we rationalize it in the spec and all... it's just the right thing to do. It's what people expect.`` I admit my first reaction was to say "here! here!" But let us take pause. W= hat=20 are we really getting outselves into? Consider, the heart of this assertion= =20 is simply this: quoted things should be strings, its right, its expected But may I remind you that one would easily say the same of other possible=20 nodes. mapping things should be maps, its right, its expected sequence things should be sequences, its right, its expected So if you follow this to its conclusion, NULL tags go, and we're right back= =20 where we started. - "23" # tag:yaml.org,2002:str - [] # tag:yaml.org,2002:seq - {} # tag:yaml.org,2002:map What was the point of all this debate, anyway?=20 Alas, have we forgotten?!!! It would seem we have. So lets' set it out agai= n=20 as plain as can be: plain-scalar things should be ...er..., its right?, its expected? Our current problem lies here, nowhere else. Presently the plain-scalar is= =20 distinguish from the non-plain by a flag --a piece of style that bleeds ove= r=20 into the representation. This is the point of all this debate. This is our= =20 wart. This is the issue at a hand! Do not be distracted and misled. It is n= ot=20 about quotes being YAML strings (if there is a gapping wound it is here, wi= th=20 YAML's repository bleeding into my application's native types). No. It is=20 rather about what we might do to put a bandaid on this wound, or heal it al= l=20 together if possible. And so, with this fresh focus let us once again take aim at the objective a= nd=20 see what we have at our disposal: There are only two proposals that heal the wound all together. Proposal #1: The plain-scalar style is made indistinguishable from the others. =20 This is nice, but has two main problems: firstly, implicit typing becomes an all or nothing deal; some sort of "operator" would be required to control this, and secondly, backward compatibility is broken =3D=3D :( Proposal #5 (never was been much cared for) Style becomes an accepted part of the representation. This also heals the wound, but requires that we recognize new types based solely on scalar style: !plain, !quoted, !literal,=20 !folded. The concern with this is that it goes too far and makes the cure worse then the illness. =3D=3D :( Alas, unless someone pulls an Einstein, we will have to settle for a bandai= d.=20 What it means to be a bandaid is simply this: how to minimize the "bleeding= "=20 while plain-scalars yet remain distinct from non-plain scalars. Proposal #2:=20 Give the plain scalar its own type, on par with the rest. =20 We do this with the special variants ?map, ?seq, ?str, ?var. =20 Proposal #3: Give the plain scalar it's own type, but not on par with the rest. =20 We do this by falling back to _kind_ as the distingushing factor, hence the NULL tag. And then give the plain-scalar a tag of its own --the simplist one '!'. As for #4, I cannot add it as is, b/c it mixes two different issues. So I w= ill=20 first have to extract the "contaminating" issue before re-presenting it. The ready problem with #4 is how it decides what quotes determine: that the= y=20 are _YAML_ strings. This forces a YAML repository type into my application.= =20 There are two important questions to ask about this: 1) if the YAML !str is= =20 to be forced across, shouldn't the !map and !seq be so too? And 2) should=20 YAML types be forced into my application to begin with? The 1st seems the=20 logical conlusion --I cannot see why you'd be willing to do one but not the= =20 others. The second is more to the point. Consider that if I wanted all=20 strings to become MySpecialStrings, should I be allowed to do this? Can you= =20 stop me? -- Thus the point is simply that its mute to make these things YA= ML=20 types from the get go. They too must be resolved (perhaps into YAML types a= s=20 the case may be, but nonetheless) they must go through the same phase as th= e=20 plain-scalar. So there really is no significance to this. And is a separate= =20 (albiet not totally un-related) issue that we must can debate separately. Okay, with that out of the way, we can actaully see what #4 is about. #4=20 transfers the wart from the plain-scalar to the non-plain scalars, making=20 them distinct from the rest. So it seems to say that it is the non-plain=20 scalars that are bleeding style into representation, not the plain scalar.= =20 (And indeed #4 as given confirms it explicitly, giving all the non-plains t= he=20 specific meaning of _YAML string_). This displacement of the wart is not a= =20 totally unreasonble thing to do, it is really a just a symetric group=20 rotation of #3. I.e. #3 with the magic bullet ( ! ) giving way to magic=20 quotes ( ' " | > ). But mind you, its not a complete substitute. A speical= =20 tag is still needed for the non-plain scalars! *stess* Proposal #4: Give the non-plain scalars their own type, not on par with the rest. =20 We can do this by falling back to _kind_ as the distingushing factor, hence the NULL tag. And then giving the non-plain scalars a tag of thier own, (as with #3) probably the simplist one '!'. In looking over these proposals, it becomes clear to me that we need to loo= k=20 at each carefully and in full address of pros and cons, point by point, and= =20 in great detail. If I may suggest, we might take that up next. I hope I have clear things up and set us back on task. I'm hungry and will = not=20 take up any more of your valuable time --for now ;) At this point, I'll leave the pros and cons of these proposals up to you, m= y=20 fellow Yamlistas. T. =2D-=20 ( o _ =E3=82=AB=E3=83=A9=E3=83=81 // trans. / \ transami@... I don't give a damn for a man that can only spell a word one way. =2DMark Twain ```