From: Rich M. <rd...@cf...> - 2004-08-08 16:51:12
|
As will be seen below, I am an active user of YAML. I am also a strong proponent of its use, having written articles and given presentations (e.g., "Modularity through Frozen Data Structures") on its behalf. So, please take the following comments as "constructive criticism" from a loyal (though troubled) supporter. I think that YAML needs a usable standard and good implementations far more than it needs more oddball notations. Frankly, I'm not convinced that YAML should HAVE much in the way of typed data. Putting a zillion data types (and related notations) in the standard * makes efficient parsers harder to write, * complicates the sharing of YAML files, and * increases the YAML learning curve. My preference would be to leave most of this out of the base standard, but allow for a formal way to tie notations to data types in a declaration. I don't want or expect YAML to have built-in notations for everything I might come up with (e.g., quoted regular expressions as hash keys), but it might be nice to be able to formally declare what I'm doing (and let YAML do more of the work of parsing it)... I've hand-edited some 30K lines of YAML for my current project and that amount is dwarfed by the mechanically-generated YAML the system uses. I use a tiny subset of the syntax, only what I need to encode comments, strings (folding and non-folding), lists, and hashes. I find myself using space-separated strings in some places where I'd like to use lists, as: foo: '1 2 3' because YAML.pm still (AFAIK) doesn't handle syntax like: foo: [ 1, 2, 3 ] Processing the input YAML often takes the majority of the time used by my scripts. I put up with this because YAML is a good match for Perlish data structures and because it's easy to read, edit, etc. I even transliterate XML files into YAML so that I can read them more easily, despite the fact that it will slow my scripts down appreciably. One of these days I'd like to use YAML to communicate with some Cocoa (Mac OS X) applications. Unfortunately, there's no YAML implementation for Objective-C. I may have to hack up Python or Ruby bridge code, just to import my data files. YAML might also be a good match for Java (etc), but folks use XML because it has implementations and YAML doesn't. Please, people, wake up and smell the coffee! Love YAML. Hate the interminable language-lawyering... -r P.S. The Perl 6 folks are having similarly arcane and interminable discussions, but I don't find this to be a problem. I think the difference is that I have a solid version of Perl to use while they work out the details of its (possible) successor. -- 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: Clark C. E. <cc...@cl...> - 2004-08-08 19:23:05
|
Howdy all. Sorry I didn't chime in earlier, I was following my very-soon-to-be-wife taking pictures of carved rocks in Peru. My understanding of the conversation: - Why pointed out that there is alot of out-of-date stuff in the specification regarding implicit data types causing confusion, clearly this must be fixed. - Tim pointed out that implicit types are problematic; and digs into all kinds of problems with localization and productions. - Brian stated that implicit typing is "schema" specific, where schema is undefined; Brian's new parser allows you enable various plugins do to implicit data typing. For now, your simple YAML parser should load all scalars as strings, looking forward to a schema mechansim in the future. - Oren reinforced Brian's comments; implicit types are not mandatory. But also, he pointed out that locale-sensitive schemes are a bad idea. - Tim brought up localization of numbers (where I think Oren's comment was also directed at enabling specific implcit types). - Oren responded that these type repository items are optional, and that strings should be the default. - Sean chimed in about the problem of application-specific schemas. And then gave an example of how he'd like implicit items for specific languages (:symbol). - Tim was happy to hear strings were the assumed default, Tim didn't have issues with implicit typing as long as the default is always a string. - Oren reponded to Why's question about (NaN), stating that these were old left over items from a time when all implicit types were surrounded by parenthesis. Oren noded that the specifications need to be cleaned up. Also, he noted the "t" and "f" are the worst of the lot... (they've caused me problems earlier). Oren focused on + and - as possible for implicit typing for booleans. - Why asked if "!" all by itself was still allowed, Oren resonded that they are not. - Jeremy suggested == for true and != for false - Brian responded with a joke, and Oren didn't get it (the usual state of affairs); but Tim did. - Rich stated unhappiness with the state of current parsers, he is using strings of lists instead of lists beacuse current parsers can't handle the implicit list form. Rich was asking we focus on implementations; not odd-ball notations. - Brian told Rich that we _do not_ have an "Inner Circle". I'd like to reinforce this... Inner Circles suck; and we have worked exceptionally hard to keep all discussions, especially negative ones, public. Thank you all for the wonderful discussion, I'll respond under a separate cover. Clark |
From: Clark C. E. <cc...@cl...> - 2004-08-08 19:40:05
|
Rich, Implicit typing is optional and it is _not_ part of the base standard [1]. However, we must have this conversation beacuse Why's parser is at the point where he is implementing this sort of feature, and I encourage his hard work. Other parsers are not even close to compliance with the base specification, and thus should not be worrying about implicit typing. As far as implementations, we need a "C" implementation everyone can use. Why don't we start one? They have been started many times as single-person efforts which have fizzled; doing a 'collaborative' implementation is very hard, but I'm willing to put in much work in that direction. I suspect it is at least six man-months of work, especially when one considers all of the time keeping the spec and a reference implementation in-sync (with test suite merged into the specification, as Oren has started in his current specification draft [3]). Best, Clark [1] Yes, the first set of examples in the spec should be updated to reflect this notion; they were written at a time when implicit typing was mandatory. [2] Unfortunately, the current PyYaml does implicit typing when it really isn't up-to-snuff with the rest of the core spec. This is due to history, when PyYaml was written, implicit types were _not_ optional, and it caused probelms, and the specification was changed from the realization of this msitake (thank you Steve Howell). Hopefully, the new PyYAML which Tim is working on will focus on the core spec first; leaving the data types to another day. [3] http://clarkevans.com/tmp/spec.pdf On Sun, Aug 08, 2004 at 09:51:00AM -0700, Rich Morin wrote: | As will be seen below, I am an active user of YAML. I am also a strong | proponent of its use, having written articles and given presentations | (e.g., "Modularity through Frozen Data Structures") on its behalf. So, | please take the following comments as "constructive criticism" from a | loyal (though troubled) supporter. | | | I think that YAML needs a usable standard and good implementations far | more | than it needs more oddball notations. Frankly, I'm not convinced that | YAML | should HAVE much in the way of typed data. Putting a zillion data types | (and related notations) in the standard | | * makes efficient parsers harder to write, | * complicates the sharing of YAML files, and | * increases the YAML learning curve. | My preference would be to leave most of this out of the base standard, | but | allow for a formal way to tie notations to data types in a declaration. | I | don't want or expect YAML to have built-in notations for everything I | might | come up with (e.g., quoted regular expressions as hash keys), but it | might | be nice to be able to formally declare what I'm doing (and let YAML do | more | of the work of parsing it)... | | | I've hand-edited some 30K lines of YAML for my current project and that | amount is dwarfed by the mechanically-generated YAML the system uses. I | use a tiny subset of the syntax, only what I need to encode comments, | strings (folding and non-folding), lists, and hashes. I find myself | using | space-separated strings in some places where I'd like to use lists, as: | | foo: '1 2 3' | | because YAML.pm still (AFAIK) doesn't handle syntax like: | | foo: [ 1, 2, 3 ] | | Processing the input YAML often takes the majority of the time used by my | scripts. I put up with this because YAML is a good match for Perlish | data | structures and because it's easy to read, edit, etc. I even | transliterate | XML files into YAML so that I can read them more easily, despite the fact | that it will slow my scripts down appreciably. | | One of these days I'd like to use YAML to communicate with some Cocoa | (Mac | OS X) applications. Unfortunately, there's no YAML implementation for | Objective-C. I may have to hack up Python or Ruby bridge code, just to | import my data files. YAML might also be a good match for Java (etc), | but | folks use XML because it has implementations and YAML doesn't. | | | Please, people, wake up and smell the coffee! Love YAML. Hate the | interminable language-lawyering... | | -r | | P.S. The Perl 6 folks are having similarly arcane and interminable | discussions, but I don't find this to be a problem. I think | the difference is that I have a solid version of Perl to use | while they work out the details of its (possible) successor. | -- | 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 | | | ------------------------------------------------------- | This SF.Net email is sponsored by OSTG. Have you noticed the changes on | Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, | one more big change to announce. We are now OSTG- Open Source Technology | Group. Come see the changes on the new OSTG site. www.ostg.com | _______________________________________________ | Yaml-core mailing list | Yam...@li... | https://lists.sourceforge.net/lists/listinfo/yaml-core -- Clark C. Evans o Director of Technology ~/ , Prometheus Research, LLC // Turning Data Into Knowledge (( Prometheus Research http://prometheusresearch.com \\ , office: +1.203.777.2550 \/ - Research Exchange Database mobile: +1.203.444.0557 /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers YAML Ain't Markup Language ~ * Data Serialization for Mortals http://yaml.org |
From: Oren Ben-K. <or...@be...> - 2004-08-15 18:13:34
|
On Sunday 08 August 2004 22:40, Clark C. Evans wrote: > [3] http://clarkevans.com/tmp/spec.pdf I was out of the loop for the last week or so - I moved to a new apartment, which is a painful and ongoing process. At any rate, I finally got my ADSL connection to work today. I just did a very quick view through the PDF (a welcome break from unpacking boxes). I like what you did to chapter 3. There are some minor things I'd like to fix - and will, through the CVS, once I'll unpack my 2k books into their shelves, which will take a while... Just so I'll remember them: - Use + and ++ instead of * and ** in the info model section graphs for serialization and presentation, so as not to get mixed up with using * for 1-to-many and many-to-many notation. - Beef up the parse & construct process explanations. That would mean a bot of repetition - so be it. - Clarify what is meant by a "complete YAML representation". Especially since an invalid/unrecognized collection is "complete"; complete representation doesn't imply complete knowledge. Clark, I think your phrasing skills are required here... All in all, nice work, Clark! I'll do my best to work on my side of the spec ASAP. Any chance we'll have a release candidate for my birthday (9/9)? :-) People - note that the syntax productions in chapter 4 are only "almost correct". They are different from the old set - I tried to make them more understandable - and I haven't done a thorough production review of them yet. Specifically, I know that there are problems with tracking the indentation levels. There are probably other problems. I'd appreciate some feedback about the new examples format (highlighting the parts of the text that matches specific productions). I used color in HTML and border styles in the PDF. Do you find it useful, annoying, ...? Have fun, Oren Ben-Kiki |