From: Clark C. E. <cc...@cl...> - 2003-02-03 20:45:51
|
Oren's updates have been uploaded to the site, I'll update perforce tonight/tomorow. Soon... I'll have have that automated pull so that perforce is always snapshotted here.... Thank you Oren! ;) Clark |
From: Brian I. <in...@tt...> - 2003-02-04 01:28:53
|
On 03/02/03 20:59 +0000, Clark C. Evans wrote: > Oren's updates have been uploaded to the site, I'll update > perforce tonight/tomorow. Soon... I'll have have that automated > pull so that perforce is always snapshotted here.... > Thank you Oren! ttul.org changed ip addresses. This means the wiki links (perhaps others) are broken. Could you please update. Cheers, Brian > > ;) Clark > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Brian I. <in...@tt...> - 2003-02-27 00:29:25
|
On 26/02/03 15:56 -0800, Rich Morin wrote: > [ I'm writing to you off the list, so as not to put you on the spot. > Feel free to answer on the list, if that seems appropriate. ] > > Quite a bit of discussion has been taking place about new features > that might or might not go into the YAML standard. Consequently, > you may not wish to do the work needed to meet a transient version > of the evolving (or at least mutating :-) document. Not really true. There is almost nothing more that I foresee going into the YAML standard. I'm sure Clark and Oren would concur. YAML as a syntax is basically done. The only work left is to correct bugs and inconsistencies. Ideas like "variables", etc are neat, but don't effect the language. They just become Loader add-ons. > In the meanwhile, however, there are YAML users (and would-be users, > like my readers in MacTech Magazine) who aren't being well served by > the fact that YAML.pm is missing some features. My own issues are: I hear you. And I hear from many others. I get involved in too many projects. Anyway, on my bike ride today I decided that I would rewrite YAML.pm from scratch. This sounds like a horribly wrong plan, but honestly I think it might be the quickest solution. There's a lot of details and it's best to have them in your brain all at once, rather than do things incrementally and miss the forest for the weeds. o/~ Don't fear the bduf o/~ Of course I plan on keeping the API 95% or more backwards compatible. > * allowing underscores in names > > * allowing some non-alphabetics (e.g., "?") in unquoted values > > * allowing nesting of braces and brackets Could you send examples of these please? I'm not clear on your intent. > but I'm sure there are others. Is there a chance that you could do > an interim release, handling some language features that you're > reasonably confident will survive, leaving some of the speculative > stuff for later? Even though I plan to rewrite, I could see a quick stab at a bug fix release being a good thing. I will start on this tonight. Promise. Cheers, Brian |
From: Clark C. E. <cc...@cl...> - 2003-02-27 02:32:25
|
On Wed, Feb 26, 2003 at 04:29:07PM -0800, Brian Ingerson wrote: | Not really true. There is almost nothing more that I foresee going into | the YAML standard. I'm sure Clark and Oren would concur. YAML as a | syntax is basically done. The only work left is to correct bugs and | inconsistencies. The only thing that I see as pending is some sort of declaration mechanism so that I can describe my schema and any loader/writer re-write rules which should be used when loading the information. Ideally, we should strive to create a "apache module" like system where various rewrite modules can be downloaded and used to augment YAML serialization/reloading. So, that _big_ issue aside, I don't see any changes. And even this is more external to the YAML syntax, the current declaration syntax will handle it; it is more of a definition of how the delcartions will work than about parser changes. For example, my current itch (poped up again and again in the past month or so) of not having to type in a primary key twice, once for the mapping key and again for the value prompted me to consider an enhancement to the alias system... objects: 1: caption: An object in my collection id: 1 3: caption: Another object id: 3 Which becomes (with aliases): objects: &ID 1: caption: An object in my collection id: *ID &ID 3: caption: Another object id: *ID And.... as a short cut, I was thinking... objects: 1: caption: An object in my collection id: *< 3: caption: Another object id: *< Where '<' is an implicit anchor which references the key to the parent's collection. Problem is, it is quite a special case, and it really doesn't help that all of these "id: *<" thingys get duplicated everwhere. Ideally, I'd just want to see... objects: 1: caption: An object in my collection 3: caption: Another object A reader _could_ implicity add an '@id' attribute for me with the value of 1 and 3 respectively; further, the writer, upon seeing a key starting with '@' may decide to skip it. The '@' being used as a symbol for "derived" data which isn't stored. So, what appears to be a nice feature to add, really comes down to a loadable "module" which augments the tree as it is read; re-write rules, so to speak. So, what would be kinda neet is to have a way to specify that my "@id" loader technique should be used (and yes, there are those that think this is application dependent and need not go into the YAML itself... I just happen to disagree). --- %MODULES:id,... objects: 1: caption: An object in my collection 2: caption: Another object Where %MODULES: is used to list the load/save "modules" used during processing. Other example modules are ones which handle various numeric data types "numbers", or ones which do source expansion, "include". Each of these modules could then have their own spec, etc. | Ideas like "variables", etc are neat, but don't effect the language. | They just become Loader add-ons. Exactly! | Even though I plan to rewrite, I could see a quick stab at a bug fix | release being a good thing. I will start on this tonight. Promise. I was talking with Oren, and what do you say about just working on a shaared "C" tokenizer, but not yet sharing the parser. This seems like it would be a nice intermediate goal. Best, Clark |
From: Oren Ben-K. <or...@be...> - 2003-02-27 11:35:01
|
Clark C. Evans wrote: > The only thing that I see as pending is some sort of > declaration mechanism so that I can describe my schema and > any loader/writer re-write rules which should be used when > loading the information. Already there :-) --- !clarkevans.com/what-is-this-document The document content ... *By definition*, the type family identifies the loading rules... > Ideally, we should strive to create > a "apache module" like system where various rewrite modules > ... So write a mod_yaml_rewrite module that uses a config file like: --- yaml-type-family: rewrite-actions another-type-family: other-actions ... This is trivially extendible to triggering actions on the content as well as the type. > ... even this is more external to > the YAML syntax, the current declaration syntax will handle > it; it is more of a definition of how the declarations will work > than about parser changes. +10. > objects: > &ID 1: > caption: An object in my collection > id: *ID > &ID 3: > caption: Another object > id: *ID Seems neat enough. It isn't very verbose and it is very clear. I'm happy with this. > And.... as a short cut, I was thinking... > > objects: > 1: > caption: An object in my collection > id: *< > 3: > caption: Another object > id: *< > > ... Problem is, it is quite a special case, ... +1. For example, if the 'id' field is nested one level further down in the data structure, the shortcut breaks. > Ideally, I'd just want to see... > > objects: > 1: > caption: An object in my collection > 3: > caption: Another object > > A reader _could_ implicitly add an '@id' attribute for me with > the value of 1 and 3 respectively; further, the writer, upon > seeing a key starting with '@' may decide to skip it. The > '@' being used > as a symbol for "derived" data which isn't stored. Java serialization has the notion of derived fields as well. There you just declare a field as "transient" to avoid having it being serialized. However, if you want to intelligently fill it on loading you need to write your own de-serialization method. The same principle could hold here, I guess. > So, what would be kinda neat is to have a way to specify > that my "@id" loader technique should be used (and yes, there > are those that think this is application dependent and need > not go into the YAML itself... I just happen to disagree). Again, this would have to be triggered according to the type family; you wouldn't typically want _all_ sub-maps in a document to automatically get a '@id' field... > --- %MODULES:id,... > objects: > 1: > caption: An object in my collection > 2: > caption: Another object NO. It should be: --- !type-family objects: # Get an implicit @id 1: caption: An object in my collection 2: caption: Another object animals: # Do not get an implicit @id cat: legs: 4 snake: legs: 0 ... > | Ideas like "variables", etc are neat, but don't effect the > | language. They just become Loader add-ons. > > Exactly! I strongly feel that all loader add-ons are to be triggered on the type family and that no other mechanism is needed. It is OK for a loader/application to read a configuration file that specifies how to handle each type family; also it is OK for such processing to be restricted to a particular nested part of a node/document that is identified by a type family. In the example above, identifying the document as belonging to 'type-family' indicates that, within the 'objects' sub-mapping, all nodes should receive an implicit '@id'; but nodes in the 'animals' sub-mapping should not. > I was talking with Oren, and what do you say about just > working on a shared "C" tokenizer, but not yet sharing the > parser. This seems like it would be a nice intermediate goal. I thought I'll have time to take a stab at it this weekend but I need to hammer out a provisional patent or two. Sorry. Maybe we could IRC on this? Have fun, Oren Ben-Kiki |