From: Donnal W. <don...@ya...> - 2002-07-14 14:27:22
|
Greetings, My introduction to YAML came through the following posting: From: Clark C . Evans Subject: Re: XML overuse? (was Re: Python to XML to Python conversion) Newsgroups: comp.lang.python > For my purposes, YAML (http://yaml.org) is doing just > perfectly. It has lots of advantages over XML, first > it is readable and second it uses native Python objects > (instead of a document object model) By way of introduction, I am a programmer by avocation only (my training and vocation is medicine). I'm also a staunch advocate for Python. For the past few months, I have been working on a personal toolkit to make it easier to write custom clinical applications in Python. My approach to persistence was to write a Python to (http://www.docuverse.com/smldev/minxmlspec.html) to Python writer/reader (using recursion and polymorphism). This has worked quite well so far, but I've worried about the verbosity of the data files among other things. When I read the YAML 1.0 spec, I was impressed with the clean syntax (goes right along with Python). It seems like my scheme would be easy to implement in YAML. My questions for the group are these: 1. How stable is the core YAML specification? I am not talking about the bleeding edge, but have the basics changed much lately, or are they likely to change much in the future? 2. How widely accepted is YAML at the current time? This is not the most important criteria for me, but wide spread (or widening) acceptance would be a plus. Just as I did not write a general purpose XML parser (nor did I use the XML packages included with Python), I have no plans to write a general purpose YAML parser. I am simply interested in using the YAML spec as the format for the data files that my writer and reader use. ===== Donnal Walter Arkansas Children's Hospital __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com |
From: Clark C . E. <cc...@cl...> - 2002-07-14 15:39:19
|
On Sun, Jul 14, 2002 at 07:27:22AM -0700, Donnal Walter wrote: | By way of introduction, I am a programmer by avocation only (my | training and vocation is medicine). I'm also a staunch advocate for | Python. For the past few months, I have been working on a personal | toolkit to make it easier to write custom clinical applications in | Python. My approach to persistence was to write a Python to | (http://www.docuverse.com/smldev/minxmlspec.html) to Python | writer/reader (using recursion and polymorphism). This has worked | quite well so far, but I've worried about the verbosity of the data | files among other things. It's great to hear that some people are actually using the minimal XML specification! Oren and I were actually major contributors to this spec (less so to Common XML). The other primaries, Mike Champion, Simon St. Laurent, Joe Lapp, and of couse Don Park are all very sharp minds. | When I read the YAML 1.0 spec, I was impressed with the clean | syntax (goes right along with Python). It seems like my scheme | would be easy to implement in YAML. Thanks. The credit belongs to members of this mailing list and the debates that have raged here over the past year and a quarter. I'd like to point out that the information model (which IMHO, is more important than the syntax) is also very clean. A solid information model is needed for a clean API and generic tools that process YAML. | 1. How stable is the core YAML specification? I am not talking | about the bleeding edge, but have the basics changed much lately, | or are they likely to change much in the future? I'd say 95% of the spec is now immutable mod explanation improvements and clarity. A few things may change off the top off my head: - adding escape mechanism to block scalars (10% chance) - removing extra constant sugars (on), (nill) (20% chance) The last big revision (about a month and a half ago) changed quite a bit as it reflected usage feedback since Febuary. In this change, about 80% of my texts were unaffected; and the other 20% needed a simple read-in with a old parser and write-out using a new emitter. Rather simple actually. Right now the "C" and Python implementations are a bit behind the spec; but the Perl parser is darn compliant. | 2. How widely accepted is YAML at the current time? This is not the | most important criteria for me, but wide spread (or widening) | acceptance would be a plus. Our team here is around 10 core members (many of them now coding up implementations) and about 15 on the bench and about 60-90 in the penut gallery, including a few XML-heads who are waiting till it is safe to come out of the closet. *poke* We have several market nitches which XML does poorly: - Moving information between programming languages - Readable log files, object in-memory debugging dumps - Configuration files And in those nitches, we are the only team with a serious specification and implementations in more than one major language. I hope this does the snowball thing. In the future we will expand further into "XML territory" with tools for distributed systems; competing in the remote object space with SOAP and XML-RPC, and with object transformations using cYATL. cYATL will be our up-and-coming transformation language (about 2 years out) which will be similar to XSLT but without the warts. XSLT has to bend over backwards to cope with XML's lack of information model; YAML was designed from the ground up to have a solid information model so that transformations and schemas will be clean -- I was part of an XSLT implementation team and had some early exposure with RELAX. Brian Ingerson has stated he is going to dig into Parrot (Perl 6) to make sure that we are part of the core distribution. Parrot is a open source "register based" virtual machine which is being designed to run not only Perl, but have byte-code compilers for Python, Ruby, Scheme, etc. | Just as I did not write a general purpose XML parser (nor did I use | the XML packages included with Python), I have no plans to write a | general purpose YAML parser. I am simply interested in using the | YAML spec as the format for the data files that my writer and | reader use. It isn't compliant, but Steve has a very nice python implementation that is in development. A snapshot from the source code repository is http://yaml.org/python/PyYaml_14jul2002.tgz ; it works, but expect bugs (there are a few) and some un-implemented features (emitter doesn't do anchors). We may want to label this module "yaml" so one can do "import yaml". I'm not sure what's up with the libyaml these days (Neil must be busy on other stuff) but it will re-emerge in a few months. This implementation includes a python binding as well; implemented via a "C" module instead of Pure Python as Steve's implementation above. I expect the two to be plug-in replacements for each other just as cStringIO is a native replacemnt for StringIO. Right now the native binding is "yaml", I'm going to move it to cyaml. I also expect to formalize an XML binding for YAML data, this is needed for those people who have a manager that requires XML but that they're sold on YAML. When I get time I'll add the input/output code to the python parser (both steve's and cyaml). The provisional spec for this is at http://yaml.org/xml.html but it needs one big semantic change -- all types not a string,list, or mapping are explicit. Right now it uses the implict rules... and this makes it hard for any XSLT transformations to work that rely upon typing information. I hope this is helpful. Best, Clark |
From: Neil W. <neilw@ActiveState.com> - 2002-07-14 16:55:09
|
Clark C . Evans [14/07/02 11:46 -0400]: > I'm not sure what's up with the libyaml these days (Neil must be > busy on other stuff) but it will re-emerge in a few months. Yeah, I got pulled into some big projects at work. Plus it seemed like a good time to take a holiday -- some implicits were changing, and multi-line strings were generalized a bit. I just read the tentative release schedule, and it looks good. I'll try to have a beta ready by August 1, so some language bindings have time to evolve by September 1. Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-07-14 18:13:42
|
On Sun, Jul 14, 2002 at 09:53:08AM -0700, Neil Watkiss wrote: | Clark C . Evans [14/07/02 11:46 -0400]: | > I'm not sure what's up with the libyaml these days (Neil must be | > busy on other stuff) but it will re-emerge in a few months. | | Yeah, I got pulled into some big projects at work. Plus it seemed like a good | time to take a holiday -- some implicits were changing, and multi-line | strings were generalized a bit. | | I just read the tentative release schedule, and it looks good. I'll try to | have a beta ready by August 1, so some language bindings have time to evolve | by September 1. This would be fantastic. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Donnal W. <don...@ya...> - 2002-07-15 15:31:34
|
[Clark C . Evans]: > [Donnal Walter]: > | When I read the YAML 1.0 spec, I was impressed with the clean > | syntax (goes right along with Python). It seems like my scheme > | would be easy to implement in YAML. > > Thanks. The credit belongs to members of this mailing list > and the debates that have raged here over the past year and > a quarter. I'd like to point out that the information model > (which IMHO, is more important than the syntax) is also very > clean. A solid information model is needed for a clean API > and generic tools that process YAML. Yes, the information model is also much of the attraction of YAML for me. I am in the process of trying to wrap my mind around it. The part about anchors is giving me pause, but I'm sure all will become clear with a little experimentation. :-) >[snip much helpful material] > We have several market nitches which XML does poorly: > - Moving information between programming languages > - Readable log files, object in-memory debugging dumps > - Configuration files I am also excited about the possibility of using YAML as an object-oriented database for small to medium-sized projects. As mentioned in my original post, Minimal XML seems to be working fairly well in this regard so far, and I am guessing that YAML would do even better. > And in those nitches, we are the only team with a serious > specification and implementations in more than one major > language. I hope this does the snowball thing. Yes. > [snip more good information] > > | Just as I did not write a general purpose XML parser (nor > | did I use the XML packages included with Python), I have > | no plans to write a general purpose YAML parser. I am simply > | interested in using the YAML spec as the format for the data > | files that my writer and reader use. > > It isn't compliant, but Steve has a very nice python > implementation that is in development. Well, as I currently see things, I would like to be compliant on the emitter side of the equation, but since I plan to limit the subset of YAML that I use, there is no reason to require full compliance on the parser side, is there? > [more good stuff snipped] > > I hope this is helpful. Yes, very much so. Thank you, Clark, for the detailed reply. And may I also respond to the following thread: [Oren Ben-Kiki]: | [Clark C . Evans]: | > schedule: | > - | > name: Working Draft Call For Implementations | > from: now | > till: August 31st | | Seems reasonable. BTW, I started working again on my pull-based | parser... I am not familiar with the term "pull-based", but it sounds a lot like the method I use to parse Minimal XML. The Python objects in my data model have a method Retrieve(reader) that loads (pulls) the data from a minimally parsed file into the appropriate attributes. (The reader parses the file into tokens, which the Retrieve method knows how to understand.) Is this somewhat similar? ===== Donnal Walter Arkansas Children's Hospital __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com |
From: Steve H. <sh...@zi...> - 2002-07-15 15:58:35
|
----- Original Message ----- > > > > It isn't compliant, but Steve has a very nice python > > implementation that is in development. > > Well, as I currently see things, I would like to be compliant on > the emitter side of the equation, but since I plan to limit the > subset of YAML that I use, there is no reason to require full > compliance on the parser side, is there? > I think you can get a lot done with subset YAML implementations. The pure Python emitter has a few limitations that you should probably know about: 1) Anchors aren't yet supported. If you have self-referential data structures, this might be a problem for you. 2) Multi-line scalars with white space on the first line aren't supported yet. This is kind of an edge case for YAML, since YAML uses white space for structure as well as content. The YAML spec handles this; I just haven't implemented it yet. 3) I emit most things as strings, and neither the emitter or parser supports all the implicit types. 4) I haven't documented or cleaned up the call interface yet. None of these features will be difficult to implement; just haven't gotten around to it yet. If you want to escalate any priorities, let me know. Also, if you want to contribute to the implementation, post to this list and we can set you up with source control. The code for both the parser and emitter is still quite small, and there are many tests that can show you what features are supported. Thanks, Steve |
From: Clark C . E. <cc...@cl...> - 2002-07-15 17:01:00
|
On Mon, Jul 15, 2002 at 08:31:33AM -0700, Donnal Walter wrote: | Yes, the information model is also much of the attraction of YAML | for me. I am in the process of trying to wrap my mind around it. | The part about anchors is giving me pause, but I'm sure all will | become clear with a little experimentation. :-) Any suggestions for making this more clear and understandable would be greatly apprechiated. As for anchors/aliases; these are just a mechanism used to serialize cases where a node appears more than once in the graph; the first occurance is marked with an anchor and subsequent occurances are represented via an alias which is a place-holder for the corresponding anchored node. | I am also excited about the possibility of using YAML as an | object-oriented database for small to medium-sized projects. As | mentioned in my original post, Minimal XML seems to be working | fairly well in this regard so far, and I am guessing that YAML | would do even better. I also have this hope. One of the things I plan to do in the next 2-4 months is a "transaction" layer on top of an in-memory binding of YAML; the transaction code would implement multi-version currency algorithems. ;) | I am not familiar with the term "pull-based", but it sounds a lot | like the method I use to parse Minimal XML. The Python objects in | my data model have a method Retrieve(reader) that loads (pulls) the | data from a minimally parsed file into the appropriate attributes. | (The reader parses the file into tokens, which the Retrieve method | knows how to understand.) Is this somewhat similar? By pull-based, I mean that the caller has the while loop and the parser has a next() method to "pull" the next node. Push-parsers the caller has an event which is called for each node; push-parsers are easier to write but more effort to use for the caller since they can't use a simple while loop. All in all, parsers should be pull and emitters should be push; this gives the application the greatest flexibility. Of course, if you are just loading it into memory in one pass and saving it in one pass this distinction doesn't matter a bit. Best, Clark |
From: Donnal W. <don...@ya...> - 2002-08-06 02:16:45
|
--- "Clark C . Evans" <cc...@cl...> wrote: > > We have several market nitches which XML does poorly: > - Moving information between programming languages > - Readable log files, object in-memory debugging dumps > - Configuration files > > And in those niches, we are the only team with a serious > specification and implementations in more than one major > language. I hope this does the snowball thing. > Speaking of ideal niches, can someone point me to any work being done using YAML for GUI resource files/editors? This would be the YAML counterpart, for example, of XRC for wxWindows/wxPython. ===== Donnal Walter Arkansas Children's Hospital __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |