From: Brian Ingerson <ingy@tt...>  20020503 16:04:41

On 03/05/02 01:30 0700, Neil Watkiss wrote: > Hi guys, > > You know what? I need more examples. Brian's lastbutone email convinced me > he was right again. > > We have Python and Perl YAML bindings. Would it be possible to come up with > an example showing how this affects YAML interoperability? I haven't seen an > example of exactly _why_ the "YNY" matters all that much. A long time ago I remember that the Y3C (YAML 3 Cohorts) made an edict that we only cared about NYN roundtripping, since YNY roundtripping was nigh impossible. (As Neil's examples below demonstrate). I don't think even Clark would think that total YNYRTing is possible. I think he just wants to make sure that a sequence doesn't turn into a map at the serialization level. I think Clark needs to produce some real world cases where this would cause problems, or we should just drop the notion of YNYRT forever. The funny thing is that something like "sparse arrays" really only matters in the "YAML as Serialization" world, not in the "YAML as XML" or "YAML as Config" worlds. In other words, the only processes (in the real world) that would be outputting sparse arrays are systems that would be reading them back in themselves. Even in the case where I have some system that is half Perl, half Python I don;t see the problem with normal sparse arrays. The only gray area is a Perl object (Foo::Bar) that likes to express itself in a sparse manner wouldn;t be interoperable in Python. Big fricking deal! This is *not* going to be a real world problem. If it is, the fix is simple: 'Foo::Bar' should express itself differently. Cheers, Brian > > Let's label some YAML data "Y", and say that Y[i] represents Y at some point > through the following system: > > 0 1 2 3 >    > input >  Perl  >  Python  >  Perl  > output >    > > At the beginning, Y[0], is the original YAML stream. > > In my mind, the following statements MUST be true if all components in this > system are YAML compliant: > > *1) Y[i] !=? Y[j] for i & j such that i != j > > **2) When loaded by a particular loader, Y[i] and Y[j] are "equal" > for all i and j > > * : !=? means "not necessarily equal to". > **: By equal, I mean that the data structures must be identical. In other > words, by being loaded and dumped, I can't have an integer turn into a > string or a floating point; arrays must stay arrays; "sparse arrays" > (whatever those may be) must remain sparse arrays. > > The obvious thing to notice here is that YAML does not _require_ the Python > implementation to load YAML in the same way as the Perl implementation, as > long as the result of loading Y[i] is the same, no matter what stage it was > grabbed from. > > Examples: > > Y[0]: > >  !seq > 0: 1 > 2: 3 > > Y[1]: > >  [1,~,3] > > Y[2]: > >  >  1 >  ~ >  3 > > Y[3]: > >  #YAML:1.0 !seq >  !intdec "1" >  !nulltilde "~" >  !inthex "0x03" > > See whatI mean? These all represent the exact same structure in memory (for > the same loader, that is  PyYAML differs from Perl of course). But each > stream is totally different at the Y level. > > Later, > Neil > > Clark C . Evans [03/05/02 02:24 0400]: > > Three options: > > > > 1. We have it such that "keyed"/"series" distinction should > > always be preserved in a YNY roundtrip. In this case, > > our trusty !seq {0:one, 1:two} example must be set aside > > and we should instead introduce !sparse {0:one, 1:two} for > > the use case of a sparse array. > > > > 2. We have it such that "keyed"/"series" distinction need not > > be preserved in a YNY roundtrip. In this case, your example > > of !perl/Foo::Bar {} is ambiguous and you must make your > > type family more explicit. > > > > 3. We be very restrictive. In this case, we state not only > > that "keyed"/"series" distinction must be preserved in a YNY > > roundtrip, but also that a given type family can only be used > > for keyed, series, or scalar kinds and not for any other kind. > > For this case, !perl/Foo::Bar would need a more explicit > > family to distinguish between "hashtable" and "array". Further, > > in this case, we would also need a !sparse type. > > > > I like option #3 the best. It is the least flexible, but I think > > that this will maximize the chances for roundtripping. I guess > > #1 is better than #2, I never really liked a !seq making a sparse > > array anyway. > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: bandwidth@... > _______________________________________________ > Yamlcore mailing list > Yamlcore@... > https://lists.sourceforge.net/lists/listinfo/yamlcore 