From: Clark C. E. <cc...@cl...> - 2002-09-07 20:41:30
|
On Sat, Sep 07, 2002 at 08:44:37AM -0700, Brian Ingerson wrote: | Maybe that was the main source of my headache. We really can't put any | restraints on the Native representation. All we can say is that it should | preserve all of the information of the Generic model for round tripping | purposes. We *could* talk a lot about the "best" ways of doing this, but I | don't think we have to. It will be obvious. If we just concentrate on | solidifying the Generic model (which we must for YPATH) then we don't need to | say much at all about the Native except that: | | - it exists | - it is the most natural representation for the particular language | - it should preserve as much information from the Generic model as possible | - it can be skipped altogether for YPATH purposes Sure. | Information Attributes: | DC: Data Content | NK: Node Kind | TI: Type Identifier | AA: Anchor/Alias names | KO: Mapping Key Order | NS: Node Style | IN: Indentation | TA: Throwaway Comments | | Information Models: | Syntax: [DC, NK, TI, KO, AA, NS, IN, TA] | Serial: [DC, NK, TI, KO, AA] | Generic: [DC, NK, TI, KO] | Native: [DC] I differ in one primary way, KO should be a serial property and not a generic property (this is what the current spec says as well) Also, I think that Native should be removed from this list of models. As its caused more confusion than helped. It's not as much as a model as it is a particular system which happens to support (perhaps with some assistance) the generic model. | Many of you might say that KO doesn't belong in Generic. I say why not! | Generic YAML processors could be so much more powerful if we held onto this | information up until the Native Model. I see no reason to throw it away | unnecessarily. That means that if we skip the Native model, YAML processes | could YNY roundtrip key-order! How cool is that? (rhetorical) The generic model is a way of viewing a native binding. Certainly there may be a "YAML Native Binding" as a "C" library in libyaml, but this is a different issue. Since most native bindings don't support key order; it can't be in the generic model. Also, from a formal standpoint having the key order in the generic model causes all kinds of complexity that just isn't required. I'd rather have our collections be plain-ole-mathematical functions. Let's keep key order down in the serial/syntax model, please? There is nothing saying that we can't have yaml tools which operate at these levels as well; but I'd like to keep the generic model a bit more simple than this. | Also some languages (like PHP I believe) actually preserve key order in their | hashes natively. Good for them. Yes, I guess it does. Python and Perl don't. Clark |