From: Oren Ben-K. <or...@ri...> - 2002-09-13 07:30:05
|
Brian Ingerson [mailto:in...@tt...] wrote: > The biggest reason that I like it is that it came from Oren. > I never would have expected that. Oren is an airtight logic > kind of guy. Clark more so. I guess I'm more of a do the > right thing kind of guy, where right falls pretty much in the > abstract middle of conflicting concerns. So delaying the > resolution of (implicit) types seems a big shift from Oren. Hmmm. I didn't see it that way. If you look at the spec today, you'll see there's an explicit mention that the set of implicit (and explicit) types used in a document is arbitrary and the application determines it; there's no requirement that it support the core types (other than !map/!seq/!str), but it is _recommended_ it will. I think that parsing a YAML document must give the same results for everyone, regardless of the application. So I'm very strict there - e.g., the GRAPH model (the results of a parse) does not recognize key order or allow dups IMVHO (unless one uses the explicit '- ' notation). On the other hand, I'm very loose when it comes to loading. There I think there's no point not letting the application do what it will (as long as it is based on the strict GRAPH model that is agreed upon by _all_ applications). Until this discussion most issues were focused at the parsing level (syntax etc.) so I came through as being strict; now that we are focusing on loading issue I'm coming through as loose. But it really isn't a contradiction. BTW, the above distinction very nicely correlates to my framed sign - "distinguish semantics-blind and semantics-aware"... > "All is fair if you predeclare." Again I'll make the above distinction... I think there should be one way to parse a YAML file. Hence _if_ we allow tabs in the indentation, #TAP is the right way to go under the above maxim. I feel OK about removing #TAB, however, but this means tabs are simply not allowed in the indentation, period. As for loading, I think that eventually we'll have to support something like #SCHEMA or #IMPLICITS or some other way to explicitly associate a document with various meta data (set of types, validation rules, and so on). That seems to agree with the maxim above as well... But I'm wary of adding a half-defined directive. I'd rather we continue without it for now (in the core spec), and _move on_ already to discussing Ypath/Yschema (which are related in interesting ways) so we can define some such directive knowing what it actually means. > That said, I'm willing to forward without *any* of these > directives for the time being. +1 Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-09-13 20:43:49
|
Steve Howell wrote: > If I'm writing a YAML app that, say, departs from core YAML in its > ordering of > hash keys, do I predeclare my intent to preserve ordering in the code, > or in the data? You don't either. You use '- ' in front of the keys. Really. Otherwise, declarations or no declarations, any YAML tool will feel free to randomize them. Have fun, Oren Ben-Kiki |
From: Steve H. <sh...@zi...> - 2002-09-13 20:48:08
|
From: "Oren Ben-Kiki" <or...@ri...> > Steve Howell wrote: > > If I'm writing a YAML app that, say, departs from core YAML in its > > ordering of > > hash keys, do I predeclare my intent to preserve ordering in the code, > > or in the data? > > You don't either. You use '- ' in front of the keys. Really. Otherwise, > declarations or no declarations, any YAML tool will feel free to randomize > them. > Except that it's a pain in the butt, as I've explained in other emails. |
From: <ir...@ms...> - 2002-09-14 04:35:04
|
On Fri, Sep 13, 2002 at 11:45:03PM +0300, Oren Ben-Kiki wrote: > Steve Howell wrote: > > If I'm writing a YAML app that, say, departs from core YAML in its > > ordering of > > hash keys, do I predeclare my intent to preserve ordering in the code, > > or in the data? > > You don't either. You use '- ' in front of the keys. Really. Otherwise, > declarations or no declarations, any YAML tool will feel free to randomize > them. But remember, "feel free" doesn't mean "has to". If you use only tools that promise to respect the order, you're safe. It's just, you can't expect *all* YAML tools to do this. My crystal ball says there's a 99% that Steve's going to put a mode into PyYAML.load() that respects the order, 80% that he's not going to put dashes in front of his keys, and 50% that I'm not going to put dashes in front of my keys except when I need my ordered data to work with non-Howell tools. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Oren Ben-K. <or...@ri...> - 2002-09-13 20:52:06
|
Clark C. Evans wrote: > We have two choices for direction: > > a) YAML is a human-readable generic format, which has an > application in data serialization. > > b) YAML is a human-readable serialization format, which may > not be appropriate for all uses. Nice insight. I think that if anyone wants the generic format, Common-XML is a better fit. XML is the right tool for structured documents; YAML is the right tool for data serialization. Let's keep it that way. The right tool for the right job. (BTW, yes, I'm an old-time UNIX hacker and I use VI, not EMACS; it is all the same mindset :-) Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-09-13 20:58:12
|
On 13/09/02 23:53 +0300, Oren Ben-Kiki wrote: > Clark C. Evans wrote: > > We have two choices for direction: > > > > a) YAML is a human-readable generic format, which has an > > application in data serialization. > > > > b) YAML is a human-readable serialization format, which may > > not be appropriate for all uses. > > Nice insight. I think that if anyone wants the generic format, Common-XML is > a better fit. XML is the right tool for structured documents; YAML is the > right tool for data serialization. Let's keep it that way. The right tool > for the right job. > > (BTW, yes, I'm an old-time UNIX hacker and I use VI, not EMACS; it is all > the same mindset :-) But vim 6.0 now has a kitchen sink! Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2002-09-13 21:05:56
|
Clark C. Evans wrote: > | could you breifly out line the goals of ypath and "yschema"? These will be big discussions... > YPath: > > The execution of YPath need not be done against a generic YamlNode, > it could be carried out against native objects directly. That is, > a YPath could be executed against a Python data structure without > even having to serialize it -- indeed the experimental YPath in > the PyYaml distribution does exactly that. This is what I had in mind when I taled about a "viewer". > The importance of YPath is that it is language/binding/application > independent. Thus, you could load any YAML file into any language > binding and use YPath expressions to identify particular nodes. That's crucual. > YSchema: > I think this is too overloaded a term. There are the following: - Validation; what types are allowed; what keys are allowed; what values are allowed; and so on. This includes implicit and explicit types, but goes beyond it. - Loading. Note that to load a document to natice structures you only need a subset of the above (the implicit type part). So maybe these are two separate things (one re-using the other). - Presentation. The best way to use styles, formats etc. to convert the native data back to YAML syntax. This may be broken to Dumping instructions and Emission instructions. I think we need to be very clear at each phase what is the purpose of the "schema" we are talking about. Even if it is "all of the above at once" (which may or may not be a good thing). > The advantage of a schema is that it is language neutral, every > binding would be able to use a schema to do implicit typing, > structure verification, and emitting things so that they are pretty. > As such, it is a great boon for interoperability. The final decision of what native data type to use for loading the !bloop type family is always language dependent and may be schema-specific. However I agree that we can leave it out of the discussions and assume that it would stay the same across applications. > CYATL: > > > This is a transformaion language for re-structuring YAML graphs. > It is most useful when someone gives you a Y and you want an X. This isn't going to be an easy language to define. > Although one could use a general-purpose language to do this > sort of thing, having a generic tool which is supported by multiple > implementations is probably the best way to proceed. An intermediate way is to provide a general-purpose framework with some common API/basic actions and allow language-specific code to be integrated with it somehow. XSL started as completely pure but was forced down this path by necessity; I think we should consider it from the first day. There's also the question of streaming vs. random-access on the input... This will be a fun discussion. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-09-13 21:11:42
|
Brian Ingerson wrote: > > (BTW, yes, I'm an old-time UNIX hacker and I use VI, not EMACS; it is > > all > > the same mindset :-) > > But vim 6.0 now has a kitchen sink! I suspected I'll get it for saying the above :-) I hereby formally state that there's nothing wrong with EMACS as such. I will not budge on my view of Windows, though. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-09-13 21:15:51
|
Steve Howell wrote: > > You don't either. You use '- ' in front of the keys. Really. > > Otherwise, > > declarations or no declarations, any YAML tool will feel free to > > randomize them. > > Except that it's a pain in the butt, as I've explained in other emails. Having YAML tools randomize your data would be worse :-) As Mike has pointed out, you can just view this as an explicit syntax. Two chars aren't expensive syntactically, and you are free to load it into anything you want, not necessarily a seq of maps. I think that addresses your main pain. Have fun, Oren Ben-Kiki |
From: Steve H. <sh...@zi...> - 2002-09-13 21:24:37
|
From: "Oren Ben-Kiki" <or...@ri...> > Steve Howell wrote: > > > You don't either. You use '- ' in front of the keys. Really. > > > Otherwise, > > > declarations or no declarations, any YAML tool will feel free to > > > randomize them. > > > > Except that it's a pain in the butt, as I've explained in other emails. > > Having YAML tools randomize your data would be worse :-) So don't run them. > As Mike has pointed out, you can just view this as an explicit syntax. Two > chars aren't expensive syntactically, and you are free to load it into > anything you want, not necessarily a seq of maps. I think that addresses > your main pain. > Here's my challenge to you, Oren. Take this data here, put it in vim, add dashes in front of all the keys, then send it back to me in email. --- Name: Steve Howell Hometown: Columbia, MD Languages: [Python, Ruby, Java] --- First name: Brian Last name: Ingerson Language: Perl --- Last Name: Ganapathy First Name: Vijay Birthplace: India Languages: - English - French I bet you don't accept the challenge. It's beneath you. It's a pain in the butt. What intelligent human being wants to do work that a computer could do just as easily? Cheers, Steve |
From: Brian I. <in...@tt...> - 2002-09-13 21:28:59
|
On 13/09/02 17:25 -0400, Steve Howell wrote: > From: "Oren Ben-Kiki" <or...@ri...> > > Steve Howell wrote: > > > > You don't either. You use '- ' in front of the keys. Really. > > > > Otherwise, > > > > declarations or no declarations, any YAML tool will feel free to > > > > randomize them. > > > > > > Except that it's a pain in the butt, as I've explained in other emails. > > > > Having YAML tools randomize your data would be worse :-) > > So don't run them. > > > As Mike has pointed out, you can just view this as an explicit syntax. Two > > chars aren't expensive syntactically, and you are free to load it into > > anything you want, not necessarily a seq of maps. I think that addresses > > your main pain. > > > > Here's my challenge to you, Oren. Take this data here, put it in vim, add > dashes in front of all the keys, then send it back to me in email. > > --- > Name: Steve Howell > Hometown: Columbia, MD > Languages: [Python, Ruby, Java] > --- > First name: Brian > Last name: Ingerson > Language: Perl > --- > Last Name: Ganapathy > First Name: Vijay > Birthplace: India > Languages: > - English > - French > > I bet you don't accept the challenge. It's beneath you. It's a pain in the > butt. What intelligent human being wants to do work that a computer could do > just as easily? I think Oren's view is that you are doing something Non-YAML (although useful, IMO). But I'd agree that it isn't YAML-endorsed behaviour. You couldn't expect Why and me to support it. (Although I do ;) Cheers, Brian |
From: Steve H. <sh...@zi...> - 2002-09-13 21:32:38
|
----- Original Message ----- From: "Brian Ingerson" <in...@tt...> To: "Steve Howell" <sh...@zi...> Cc: "Oren Ben-Kiki" <or...@ri...>; <yam...@li...> Sent: Friday, September 13, 2002 5:28 PM Subject: Re: [Yaml-core] Think or Dwim > On 13/09/02 17:25 -0400, Steve Howell wrote: > > From: "Oren Ben-Kiki" <or...@ri...> > > > Steve Howell wrote: > > > > > You don't either. You use '- ' in front of the keys. Really. > > > > > Otherwise, > > > > > declarations or no declarations, any YAML tool will feel free to > > > > > randomize them. > > > > > > > > Except that it's a pain in the butt, as I've explained in other emails. > > > > > > Having YAML tools randomize your data would be worse :-) > > > > So don't run them. > > > > > As Mike has pointed out, you can just view this as an explicit syntax. Two > > > chars aren't expensive syntactically, and you are free to load it into > > > anything you want, not necessarily a seq of maps. I think that addresses > > > your main pain. > > > > > > > Here's my challenge to you, Oren. Take this data here, put it in vim, add > > dashes in front of all the keys, then send it back to me in email. > > > > --- > > Name: Steve Howell > > Hometown: Columbia, MD > > Languages: [Python, Ruby, Java] > > --- > > First name: Brian > > Last name: Ingerson > > Language: Perl > > --- > > Last Name: Ganapathy > > First Name: Vijay > > Birthplace: India > > Languages: > > - English > > - French > > > > I bet you don't accept the challenge. It's beneath you. It's a pain in the > > butt. What intelligent human being wants to do work that a computer could do > > just as easily? > > I think Oren's view is that you are doing something Non-YAML (although > useful, IMO). But I'd agree that it isn't YAML-endorsed behaviour. You > couldn't expect Why and me to support it. (Although I do ;) > So, we've come full circle then. Thank you for your quick response, Brian. Oren must still be insert mode. As I said earlier... > > If I'm writing a YAML app that, say, departs from core YAML in its > > ordering of > > hash keys, do I predeclare my intent to preserve ordering in the code, > > or in the data? So, yeah, of course it isn't YAML-endorsed behavior. And Oren and I agree on that. But it's still a pain in the butt. |
From: Neil W. <neilw@ActiveState.com> - 2002-09-13 21:44:57
|
Steve Howell [13/09/02 17:25 -0400]: > Here's my challenge to you, Oren. Take this data here, put it in vim, add > dashes in front of all the keys, then send it back to me in email. I used this: :%s,^\s*\([^:]\+\):,- \1: --- - Name: Steve Howell - Hometown: Columbia, MD - Languages: [Python, Ruby, Java] --- - First name: Brian - Last name: Ingerson - Language: Perl --- - Last Name: Ganapathy - First Name: Vijay - Birthplace: India - Languages: - English - French > I bet you don't accept the challenge. It's beneath you. It's a pain in the > butt. What intelligent human being wants to do work that a computer could do > just as easily? If the data is generated by a computer, it can do this for you; if it's written by a human, they can type it correctly the first time around. That seems acceptable. If you're using this in an application where you want to use YAML to build some kind of picture of the data to show a user (say, a YAML document which is dynamically turned into a data-entry GUI), then you do care about order, because people are used to seeing data entry boxes in a logical order. If this is the case, then a sequence of maps is perfectly natural, and actually very easy to deal with in languages like Python: for attrib in person: # In Perl: ($k, $v) = each %attrib; k = attrib.keys[0] # is that right? v = attrib.values[0] # ditto? gui.add_entry_box('label': k, 'value': v) Preferably, you could load this into a 'person' class and do this: for attrib in person: gui.add_entry_box('label': attrib.label, 'value': attrib.value) I think that gets the job done. Please pardon any Python booboos. Later, Neil |
From: Tom S. <tra...@tr...> - 2002-09-13 22:13:25
|
On Fri, 2002-09-13 at 15:47, Neil Watkiss wrote: > --- > - Name: Steve Howell > - Hometown: Columbia, MD > - Languages: [Python, Ruby, Java] > --- > - First name: Brian > - Last name: Ingerson > - Language: Perl > --- > - Last Name: Ganapathy > - First Name: Vijay > - Birthplace: India > - Languages: > - English > - French ouch. i may take that back. that's pretty damn UUUUUUUUUUGLY! still i can live with if i have to. i think. -- tom sawyer, aka transami tra...@tr... |
From: why t. l. s. <yam...@wh...> - 2002-09-13 23:18:54
|
Neil Watkiss (neilw@ActiveState.com) wrote: > Steve Howell [13/09/02 17:25 -0400]: > > Here's my challenge to you, Oren. Take this data here, put it in vim, add > > dashes in front of all the keys, then send it back to me in email. > > I used this: > > :%s,^\s*\([^:]\+\):,- \1: Highlight the first characters of each key with Ctrl-V. Then do Shift-I. Dash. Space. Ctrl-[. Good for doing the above to a single nested hash. One of my favorite key combos. _why |
From: Steve H. <sh...@zi...> - 2002-09-14 00:51:55
|
From: "Neil Watkiss" <neilw@ActiveState.com> > Steve Howell [13/09/02 17:25 -0400]: > > Here's my challenge to you, Oren. Take this data here, put it in vim, add > > dashes in front of all the keys, then send it back to me in email. > > I used this: > > :%s,^\s*\([^:]\+\):,- \1: > > --- > - Name: Steve Howell > - Hometown: Columbia, MD > - Languages: [Python, Ruby, Java] > --- > - First name: Brian > - Last name: Ingerson > - Language: Perl > --- > - Last Name: Ganapathy > - First Name: Vijay > - Birthplace: India > - Languages: > - English > - French > > > I bet you don't accept the challenge. It's beneath you. It's a pain in the > > butt. What intelligent human being wants to do work that a computer could do > > just as easily? > > If the data is generated by a computer, it can do this for you; if it's > written by a human, they can type it correctly the first time around. That > seems acceptable. > The context of this conversation has always been humans not wanting to type the dash. Who the :%s,^\s*\([^:]\+\):,- \1: wants to type in dashes on every row of their doc? It's a pain in the butt. And there's no reason to make them do it, if you have a YAML loader slightly adapted to non-YAML purposes. |
From: <ir...@ms...> - 2002-09-14 04:47:15
|
On Fri, Sep 13, 2002 at 02:47:17PM -0700, Neil Watkiss wrote: > for attrib in person: > # In Perl: ($k, $v) = each %attrib; > k = attrib.keys[0] # is that right? > v = attrib.values[0] # ditto? > gui.add_entry_box('label': k, 'value': v) # List of pairs person = [ ('name': 'George Bush II'), ('nickname': 'Dubya' ) ] for k, v in person: gui.add_entry_box('label': k, 'value': v) # List of dictionaries person = [ {'name': 'George Bush II'}, {'nickname': 'Dubya' } ] for attrib in person: for k, v in attrib.items(): gui.add_entry_box('label': k, 'value': v) I don't like that two-level iteration process for a list of one-element dictionaries, but if you hide it in a generic function you don't have to look at it. There are prob'ly other ways to "optimize" it too. Another thing a user-level importer could do for order-challenged dictionary types is to pass back a dictionary and a companion list, the list showing the key order. Or put the list in an agreed-upon dictionary item, or accessible as a method in a dict subclass. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: <ir...@ms...> - 2002-09-14 04:54:45
|
Argh, I should be going to sleep rather than writing bad Python. On Fri, Sep 13, 2002 at 09:47:13PM -0700, Mike Orr wrote: > # List of pairs > person = [ ('name': 'George Bush II'), > ('nickname': 'Dubya' ) > ] > for k, v in person: > gui.add_entry_box('label': k, 'value': v) # List of pairs person = [ ('name', 'George Bush II'), ('nickname', 'Dubya' ) ] for k, v in person: gui.add_entry_box(label=k, value=v) > # List of dictionaries > person = [ {'name': 'George Bush II'}, > {'nickname': 'Dubya' } > ] > for attrib in person: > for k, v in attrib.items(): > gui.add_entry_box('label': k, 'value': v) # List of dictionaries person = [ {'name': 'George Bush II'}, {'nickname': 'Dubya' } ] for attrib in person: for k, v in attrib.items(): gui.add_entry_box(label=k, value=v) -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tom S. <tra...@tr...> - 2002-09-13 22:06:36
|
On Fri, 2002-09-13 at 15:17, Oren Ben-Kiki wrote: > Steve Howell wrote: > > > You don't either. You use '- ' in front of the keys. Really. > > > Otherwise, > > > declarations or no declarations, any YAML tool will feel free to > > > randomize them. > > > > Except that it's a pain in the butt, as I've explained in other emails. > > Having YAML tools randomize your data would be worse :-) > > As Mike has pointed out, you can just view this as an explicit syntax. Two > chars aren't expensive syntactically, and you are free to load it into > anything you want, not necessarily a seq of maps. I think that addresses > your main pain. i don't mine the -, in fact i think it is good for "order" consistency. the problem you will have, as i've said before, is that it's not really an ordered map, but an array of single maps. hence you will have problems interoping if one tool treats it as an ordered map b/c it can (like php) and another that dosen't (cause its not so smart like that ;) but BUT! :) i am happy to say that it seems this may not be such a problem after all, if a type def is used like !omap and the "dumb" language promises to return it as such (i.e. with the type decleration). then all may be well. do you follow? so i ask: when a native implementation dumps an obect, does it return the type descleration with whihc it received the data in the first place? by the way i am glad to hear python gaining Sets. they are an important data structure often neglected in programming, but used all the time in mathematics. -tom -- tom sawyer, aka transami tra...@tr... |
From: Oren Ben-K. <or...@ri...> - 2002-09-14 07:49:30
|
Steve Howell [mailto:sh...@zi...] wrote: > The context of this conversation has always been humans not > wanting to type the dash. You might as well complain about having to type the ' >' for folded scalars. > Who the :%s,^\s*\([^:]\+\):,- \1: wants to type in dashes on > every row of their doc? > > It's a pain in the butt. So the only problem is aesthetic? Relief. Look, every format has its places where it requires some extra notation for some things. YAML is very good in this respect, but there are some things there anyway. We've spent more than a year reducing these. For example, we've spent a long time investigating not having '- ' in lists at all. It turns out it can't be made to work. If anyone wants to re-open this, find it in the archives, re-read the threads, and then only post something. Yes, it was long, and that's exactly why I don't want to repeat it now. There were also endless debates about the right markers for various things. At some point we made a judgment call. We even had some 2 vs. 1 votes on some of these; there's really no way 3 people can agree on aesthetics, never mind all the list participants. So there are some issues where I'm not 100% happy as well. Not many and I'm not too unhappy about them; but they are still there. YAML is much better as a result of cooperating on it and I wouldn't replace it with whatever I would have come up on my own. So I accept this. > And there's no reason to make them do it, if you have a YAML > loader slightly adapted to non-YAML purposes. That's no YAML loader. That's a loader for something else that is almost completely, but not quite, un/like YAML. We'd end up with a big mess if loader A decides on the native type according to the previous throwaway comment, loader B preserves key order, loader C loads escaped strings one way and blocks another way... All just "slightly adapted" of course. A line must be drawn somewhere and there will always be someone that would be unhappy about it being in that particular place. The solution isn't to move the line, because we'll end up with SGML or as close to XML as to make no difference, and that's not what we set out to do. I don't know the exact use case that makes you need ordered keys. Maybe YAML isn't the right solution for it. XML _is_ a good solution for some things. We want to do other things - in particular, data serialization. For this I think the current notation, '- ' and all, is the right way to go. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-09-14 07:49:30
|
Tom Sawyer [mailto:tra...@tr...] wrote: > i don't mine the -, in fact i think it is good for "order" > consistency. the problem you will have, as i've said before, > is that it's not really an ordered map, but an array of > single maps. hence you will have problems interoping if one > tool treats it as an ordered map b/c it can (like php) and > another that dosen't (cause its not so smart like that ;) I fail to see how a "sequence of key/value pairs" is different from "an ordered map". It thought it was the _definition_ of an ordered map. As for interoperation problems, if there's no problem in loading an '!int' to a Java Integer vs. Python's BigInt (or for that matter, into Perl's smart-strings), there's no problem in loading the above into PHP-thingies vs. Perl's array-of-hashes. > but BUT! :) i am happy to say that it seems this may not be > such a problem after all, if a type def is used like !omap > and the "dumb" language promises to return it as such (i.e. > with the type decleration). then all may be well. do you > follow? so i ask: when a native implementation dumps an > obect, does it return the type descleration with whihc it > received the data in the first place? It should. Note that such an implementation is by definition S-aware, so it may make use of implicit typing to do so. > by the way i am glad to hear python gaining Sets. they are an > important data structure often neglected in programming, but > used all the time in mathematics. Before this sets of a whole new syntax debate, the easiest way to represent this in YAML is: Set: one: two: seventeen: Have fun, Oren Ben-Kiki |
From: Tom S. <tra...@tr...> - 2002-09-14 09:21:03
|
On Sat, 2002-09-14 at 01:50, Oren Ben-Kiki wrote: > Before this sets of a whole new syntax debate, the easiest way to represent > this in YAML is: > > Set: > one: > two: > seventeen: > > Have fun, > > Oren Ben-Kiki > no syntax war. just a solutions query :) okay, to actually be a set, the above would have to be: Set: !set one: two: three: otherwise it's just a map with null values. same goes for an ordered map: OMap: !omap - one: 1 - two: 2 - three: 3 otherwise this would be just an array of single element maps. so cool, that covers sets and ordered maps, and though i agree that they are ugly, and it would be nice to have a neater cleaner syntax, perhaps we'll get that with yaml version 2, and if not then zayml ;) but at least we have them, they work and are consistent. now one last thing, how about duplicate keys? DMap: !dmap - one: 1 - one: 2 - three: 3 this works, and i recall there being some comment that duplicate keys may not be useable without order. how else would you specifically reference an element? point taken. so that covers these objects. i purpose that we make !set, !omap and !dmap official "1st order" types (unless others have better names for omap and dmap) -- tom sawyer, aka transami tra...@tr... |
From: <ir...@ms...> - 2002-09-14 14:23:53
|
On Sat, Sep 14, 2002 at 10:50:44AM +0300, Oren Ben-Kiki wrote: > Tom Sawyer [mailto:tra...@tr...] wrote: > > i don't mine the -, in fact i think it is good for "order" > > consistency. the problem you will have, as i've said before, > > is that it's not really an ordered map, but an array of > > single maps. hence you will have problems interoping if one > > tool treats it as an ordered map b/c it can (like php) and > > another that dosen't (cause its not so smart like that ;) > > I fail to see how a "sequence of key/value pairs" is different from "an > ordered map". It thought it was the _definition_ of an ordered map. The difference is in the duplicates. The success of the "array of single maps" concept rests on how well we can treat them as single units above the syntax level. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Oren Ben-K. <or...@ri...> - 2002-09-14 07:49:34
|
ir...@ms... [mailto:ir...@ms...] wrote: > > You don't either. You use '- ' in front of the keys. Really. > > Otherwise, declarations or no declarations, any YAML tool will feel > > free to randomize them. > > But remember, "feel free" doesn't mean "has to". If you use > only tools that promise to respect the order, you're safe. > It's just, you can't expect *all* YAML tools to do this. If I can't run Perl's/Python's/Ruby's default YAML->load() on a document without it ruining the document, it isn't YAML. So the above isn't. > My crystal ball says there's a 99% that Steve's going to put > a mode into > PyYAML.load() that respects the order, 80% that he's not > going to put dashes in front of his keys, and 50% that I'm > not going to put dashes in front of my keys except when I > need my ordered data to work with non-Howell tools. Oh _great_. So we'll have Howell's YAML vs. Oren's YAML? Shudder. Have fun, Oren Ben-Kiki |
From: <ir...@ms...> - 2002-09-14 14:18:20
|
On Sat, Sep 14, 2002 at 10:50:45AM +0300, Oren Ben-Kiki wrote: > ir...@ms... [mailto:ir...@ms...] wrote: > > > You don't either. You use '- ' in front of the keys. Really. > > > Otherwise, declarations or no declarations, any YAML tool will feel > > > free to randomize them. > > > > But remember, "feel free" doesn't mean "has to". If you use > > only tools that promise to respect the order, you're safe. > > It's just, you can't expect *all* YAML tools to do this. > > If I can't run Perl's/Python's/Ruby's default YAML->load() on a document > without it ruining the document, it isn't YAML. So the above isn't. So what if a load() function parses both YAML and pseudo-YAML documents? I thought we were about making it easy for the user to do things "our" way, while also making it possible for them to do things we can reasonably accommodate; that's the whole reason we just added an access level with ordered keys in the first place. You can't prevent people from using YAML (or close-to-YAML) syntax without patenting the syntax, or lifting code without prohibiting derivitive works, or writing parsers that parse both YAML and pseudo-YAML documents without putting a NDA on the models. > > My crystal ball says there's a 99% that Steve's going to put > > a mode into > > PyYAML.load() that respects the order, 80% that he's not > > going to put dashes in front of his keys, and 50% that I'm > > not going to put dashes in front of my keys except when I > > need my ordered data to work with non-Howell tools. > > Oh _great_. So we'll have Howell's YAML vs. Oren's YAML? Shudder. No, we have one YAML defined in the spec. Extensions are extensions, and the important point is that extension implementors don't deceive users into thinking their extensions are standard YAML. But if users want to use the extensions and implementors want to support them, why not? We have other things to think about, like getting a wonderful model hierarchy finalized and amazing tools built. (Tools so stunning that users will be putting the dashes back in their documents so they can use them. :) -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |