From: Peter W. <pwo...@qu...> - 2004-04-29 18:15:06
|
Since this is what's on http://www.yaml.org/spec/, I assume this is I should be reading. I'm looking forward to reading the final spec, and hope you don't mind some unsolicited feedback on the draft in the meantime: After a statement indicating that "---" separates documents in a stream, example 2.7 shows a stream with what appears to be three documents, the first of which contains a comment by itself: # Ranking of 1998 home runs --- - Mark McGwire - Sammy Sosa - Ken Griffey # Team ranking --- - Chicago Cubs - St Louis Cardinals But the associated caption "Two documents in a stream each with a leading comment", seems to suggest a special rule, eg "a comment followed by --- is assumed to be a header comment for the following document". Such a rule would beg the question how to distinguish between the header comment associated with a document in a stream and a footer comment at the end the previous document in the stream (eg with a blank line). This seems too ugly to be plausible, and a few minutes searching the rest of the spec for "comment" doesn't clarify the matter for me. Cheers, Peter |
From: Clark C. E. <cc...@cl...> - 2004-04-29 21:22:27
|
On Thu, Apr 29, 2004 at 11:15:05AM -0700, Peter Wolfenden wrote: | Since this is what's on http://www.yaml.org/spec/, | I assume this is I should be reading. I'm looking | forward to reading the final spec, and hope you | don't mind some unsolicited feedback on the draft | in the meantime Feedback _is_ wonderful. | After a statement indicating that "---" separates | documents in a stream, example 2.7 shows a stream | with what appears to be three documents, the first | of which contains a comment by itself: | | # Ranking of 1998 home runs | --- | - Mark McGwire | - Sammy Sosa | - Ken Griffey | | # Team ranking | --- | - Chicago Cubs | - St Louis Cardinals | | But the associated caption "Two documents in a stream | each with a leading comment", seems to suggest a special | rule, eg "a comment followed by --- is assumed to be | a header comment for the following document". Such a | rule would beg the question how to distinguish between | the header comment associated with a document in a | stream and a footer comment at the end the previous | document in the stream (eg with a blank line). This | seems too ugly to be plausible, and a few minutes | searching the rest of the spec for "comment" doesn't | clarify the matter for me. Comments in YAML exist only in the "Presentation" level, and are not considered part of the serialized content ("Document"). By the term 'comment' we mean the traditional Unix sense, characters that a parser should not be reporting and which applications should not be using to inform processing. This is different from XML, where comments are just another form of content... and hence, really not comments at all. We have tried to make this clear by calling them "throwaway comments", and by bucketing this in "space processing" along with indentation and other non-informational details of the serialization. Clearly, if you are building a 'tokenizer' for YAML, you'd want to report syntax level details (such as indentation, what styles were used, and lots and lots of other items), and if you were making a syntax editor for YAML, you'd have to manage the placement of this stuff. Hence, this is part of the "Presentation" model, and not part of the "Representation" (YAML DOM) or the "Serialization" (YAML SAX). I hope this helps. Do you have any suggestions for improving the documentation so that this is more clear? Cheers! Clark -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: Oren Ben-K. <or...@be...> - 2004-04-29 21:52:48
|
On Friday 30 April 2004 00:22, Clark C. Evans wrote: > | ... would beg the question how to distinguish between > | the header comment associated with a document in a > | stream and a footer comment at the end the previous > | document ... > > Comments in YAML exist only in the "Presentation" level, and are not > considered part of the serialized content ("Document")... Right. Since comments aren't part of the serialized content, YAML doesn't specify any rules associating the comments with specific parts of the content. The human reader will, of course, associate a comment with some content - that's what comments are for, after all, specifying human-only explanation of the content. Presumably, the human reader knows whether a given comment refers to the previous document or to the next one (or both, or neither). That said, syntactically, each document may begin with a BOM, even if it isn't the first document. So, productions-wise, a comment before the BOM ends the previous document while a comment following the BOM precedes the next one. Again, this is not to say that YAML formally associates the comments with the document - comments are not formally associated with specific content, ever. However, if you wrote a program that split a YAML stream to separate documents, you could use this marker to control where the comments end up. Have fun, Oren Ben-Kiki |
From: Tim H. <tim...@co...> - 2004-04-30 16:43:54
|
I recently found a bug or something fairly bug-like in PyYaml 0.31 and 0.32. I looked at the download page at yaml.org, but all of the links to PyYaml appear to be broken. What is the status of PyYaml, is it still being maintained? Is it in limbo till the spec gets finalized? Anyway the bugish behavior is that PyYaml write the booleans True/False as True and False, but then naturally enough reads them as "True" and "False". I admit to being lazy and not having read the spec, so I'm not sure what the correct behavior should be here, but I suspect it's something different. Thanks, -tim |
From: Clark C. E. <cc...@cl...> - 2004-04-30 17:45:05
|
Tim, PyYaml has not seen an update in over a year. I've been using the python binding in the syck distribution for the last six months (_why did a great job). Since syck didn't have any dumping code a few months back, I stripped the dumping code from PyYaml and put it into syck's python extension, 'ydump'. It isn't the best solution, but it works. Best, Clark On Fri, Apr 30, 2004 at 09:43:37AM -0700, Tim Hochberg wrote: | | I recently found a bug or something fairly bug-like in PyYaml 0.31 and | 0.32. I looked at the download page at yaml.org, but all of the links to | PyYaml appear to be broken. What is the status of PyYaml, is it still | being maintained? Is it in limbo till the spec gets finalized? | | Anyway the bugish behavior is that PyYaml write the booleans True/False | as True and False, but then naturally enough reads them as "True" and | "False". I admit to being lazy and not having read the spec, so I'm not | sure what the correct behavior should be here, but I suspect it's | something different. | | Thanks, | | -tim | | | | ------------------------------------------------------- | This SF.Net email is sponsored by: Oracle 10g | Get certified on the hottest thing ever to hit the market... Oracle 10g. | Take an Oracle 10g class now, and we'll give you the exam FREE. | http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click | _______________________________________________ | Yaml-core mailing list | Yam...@li... | https://lists.sourceforge.net/lists/listinfo/yaml-core -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: why t. l. s. <yam...@wh...> - 2004-04-30 19:10:55
|
Clark C. Evans wrote: >PyYaml has not seen an update in over a year. I've been using >the python binding in the syck distribution for the last six >months (_why did a great job). Since syck didn't have any dumping >code a few months back, I stripped the dumping code from PyYaml >and put it into syck's python extension, 'ydump'. It isn't the >best solution, but it works. > > Hey, how about we get a proper dumper working in Syck? Syck has a pretty solid emitter builtin now. I say we use your API (you know Python so much better) and weave it into the extension. What say you, Evans? By the way, we're moved over to RubyForge now. I'm going to shut down the old yaml4r project soon. But the repository has all been copied and I've been committing to RubyForge CVS for about a month. _why |
From: Clark C. E. <cc...@cl...> - 2004-04-30 22:50:32
|
| Hey, how about we get a proper dumper working in Syck? Syck has a | pretty solid emitter builtin now. I say we use your API (you know | Python so much better) and weave it into the extension. What say | you, Evans? Sounds like fun. ;) | By the way, we're moved over to RubyForge now. I'm going to shut | down the old yaml4r project soon. But the repository has all been | copied and I've been committing to RubyForge CVS for about a month. I am cce on rubyforge, could you give me access? Clark -- Clark C. Evans Prometheus Research, LLC Chief Technology Officer Turning Data Into Knowledge cc...@pr... www.prometheusresearch.com (main) 203.777.2550 (cell) 203.444.0557 |
From: Tim H. <tim...@co...> - 2004-04-30 18:07:59
|
Clark C. Evans wrote: >Tim, > >PyYaml has not seen an update in over a year. I've been using >the python binding in the syck distribution for the last six >months (_why did a great job). Since syck didn't have any dumping >code a few months back, I stripped the dumping code from PyYaml >and put it into syck's python extension, 'ydump'. It isn't the >best solution, but it works. > > Thanks Clark. I guess I'd better check out Syck -- I've been trying to keep with a pure Python solution, to keep the number of extension I have to keep around down a bit, but no sense fighting the tides of history and all that. You wouldn't happen to have any hints on getting libsyck to compile on Windows would you? As far as I know configure doesn't work there. Or am I just being obtuse? Thanks, -tim >Best, > >Clark > >On Fri, Apr 30, 2004 at 09:43:37AM -0700, Tim Hochberg wrote: >| >| I recently found a bug or something fairly bug-like in PyYaml 0.31 and >| 0.32. I looked at the download page at yaml.org, but all of the links to >| PyYaml appear to be broken. What is the status of PyYaml, is it still >| being maintained? Is it in limbo till the spec gets finalized? >| >| Anyway the bugish behavior is that PyYaml write the booleans True/False >| as True and False, but then naturally enough reads them as "True" and >| "False". I admit to being lazy and not having read the spec, so I'm not >| sure what the correct behavior should be here, but I suspect it's >| something different. >| >| Thanks, >| >| -tim >| >| >| >| ------------------------------------------------------- >| This SF.Net email is sponsored by: Oracle 10g >| Get certified on the hottest thing ever to hit the market... Oracle 10g. >| Take an Oracle 10g class now, and we'll give you the exam FREE. >| http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >| _______________________________________________ >| Yaml-core mailing list >| Yam...@li... >| https://lists.sourceforge.net/lists/listinfo/yaml-core > > > |