From: Sean O'D. <se...@ce...> - 2004-09-09 16:18:33
|
A proposal: Quotes are used as a character escape mechanism, not a typing mechanism. When scalars are loaded, they would be always just scalars and not typed to !!str simply because they're wrapped by quotes. There's an implicit typing phase where scalars are turned into !!int and other types, so why not move !!str typing to that phase? Benefit: Other types can be wrapped in quotes as a character escape mechanism and still get their true implicit type later. Example: num: "-23" This allows "-23" to be loaded as just a scalar, not a !!str, with the '-' ignored as a delimiter and the quotes removed, so the scalar value is really just -23 initially. During the implicit typing phase, the scalar gets transformed into an !!int. It seems really inconsistent to me that we have a "pre-default typing phase" where some scalars get typed as !!str and then at a later phase other types like !!int are added. I see no reason to have a middle phase where scalars are either plain scalars or strings. An application either wants default implicit typing or it doesn't, so it won't have much use for a halfway typed representation. It either wants implicit types, so it wants !!int, !!str and everything else, or it just wants the representation loaded as a graph of just !!scalars (plus !!seq and !!map). If an applications WANTS *some* typing (such as just !!str and plain scalars), then let's design a mechanism that allows applications to specify which types it wants, but let's not assume that they'll only want !!str. The pre-default typing phase seems like a real wasted effort. I say: load everything as scalar, then transform into implicit types, but don't do half the job at one phase and then the rest later. Do it all, or don't do it at all. Sean O'Dell |
From: T. O. <tra...@ru...> - 2004-09-09 16:44:09
|
On Thursday 09 September 2004 12:18 pm, Sean O'Dell wrote: > A proposal: > > Quotes are used as a character escape mechanism, not a typing > mechanism. > > When scalars are loaded, they would be always just scalars and not typed > to !!str simply because they're wrapped by quotes. There's an implicit > typing phase where scalars are turned into !!int and other types, so why > not move !!str typing to that phase? > > Benefit: > > Other types can be wrapped in quotes as a character escape mechanism and > still get their true implicit type later. > > Example: > > num: "-23" > > This allows "-23" to be loaded as just a scalar, not a !!str, with the '-' > ignored as a delimiter and the quotes removed, so the scalar value is > really just -23 initially. During the implicit typing phase, the scalar > gets transformed into an !!int. But that's not how I use " ", I want the implicit specifying when I don't put " ", but when I do it's because I mean !!str. In fact after reading your opposite view, I am more inclined then before to insist that " " mean !!str -- we all know that's what we mean when we put quotes! I suppose ?string is okay. But I am dubious that there will ever be a case that specifies ?string as anything but !!str. But, hey, who knows. I guess stranger things have happend :) -- T. |
From: Sean O'D. <se...@ce...> - 2004-09-09 18:38:42
|
On Thursday 09 September 2004 09:44, T. Onoma wrote: > > But that's not how I use " ", I want the implicit specifying when I don't > put " ", but when I do it's because I mean !!str. > > In fact after reading your opposite view, I am more inclined then before to > insist that " " mean !!str -- we all know that's what we mean when we put > quotes! > > I suppose ?string is okay. But I am dubious that there will ever be a case > that specifies ?string as anything but !!str. But, hey, who knows. I guess > stranger things have happend :) I see that as implicit typing. Just like when a scalar made of all numerals is the criteria for determining the !!int type, quotes are a criteria for the !!str type. I think implicit typing should be done at ONE point, not partially once and then continued again later. a) If quotes mean !!str, then load all scalars equal, keep the quotes with the value and strip them off during the implicit typing phase. b) If quotes are a character escape mechanism, then strip them off during parsing and consider them !!str if, and only if, no other type is assigned to them during the implicit typing phase. I could go either way, but I prefer that quotes are only considered a character escape mechanism (b). My TRUE objection, though, the one thing I think is truly ugly, is that they are considered both and that there is a partial implicit typing phase where some scalars are tagged as !!str and then later, the rest of the implicit typing is done. I see no reason for a middle stage where scalars are plain or !!str and nothing else. Implicit typing is either done, or not done...I don't think there should be a halfway state. Sean O'Dell |
From: Damian C. <dam...@gm...> - 2004-09-09 16:58:09
|
On Thu, 9 Sep 2004 09:18:22 -0700, Sean O'Dell <se...@ce...> wrote: > A proposal: > > Quotes are used as a character escape mechanism, not a typing mechanism. A lot of people feel a deep emotional need for quotation marks to distinguish strings from integers, because that is what they expect from other languages. After all, they will say, you go to immense pains to distinguish 1.0 from 1 from 2004-09-09 based on how they look; "1" looks different from 1, so why is it also not distinguishable? Explaining that this is because the guessing of types happens too late, after the quotes are stripped, will not make them happy. Thus older drafts have a special flag passed up from the parser telling you that this particular item looked more string-y than int-ish. The current kerfuffle with unspecified-tag tags is an attempt to come up with a less hacky hack. I think that it is reasonable to say that enclosing characters in quotes is a strong indication that they are intended to be used verbatim as character data. Any other meaning is surprising enough that requiring an explicit tag. Put another way, if there is going to be implicit typing then it needs to be an very easy way to suppress it. Suppose quotes did not suppress the type-guessing step, and I had a YAML file full of company names: mobile phone companies: - "Orange" - "O2" - "3" (Yes, there really is a company called 3.) If I want to ensure none of them are accidentally interpreted as numbers I have to tag each of them with !!str. In fact I better start tagging every file I create with !!str because you never know when a string will happen to look a bit like a number. I have already been caught out by implicit typing; the Python implementation will report a file name "2004-09-09.LOG" as a syntax error (it tries to parse it as a date and fails). I could find no way to make this map work: statistic names: '-': none A: average MX: maximum because pyYaml interpreted '-' as a Boolean literal false which in Python 2.2 means 0. I had to special-case my code to check for a key that was equal to the number 0 and change it to the string '-'. This is probably a bug, but similar things would happen were implict typing to be applied universally. I don't see why people want to wrap plain scalars in quotes; the whole point of implicit typing is that it is for shortish, recognizable patterns of easily typed characters like numbers and dates; having implicit types for anything longer than half a line or so would be surprising. > Example: > num: "-23" > This allows "-23" to be loaded as just a scalar, not a !!str, with the '-' > ignored as a delimiter and the quotes removed, so the scalar value is really > just -23 initially. No need for quotes because a hyphen is not interpreted specially if it is not followed by space. -- Damian -- Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: Sean O'D. <se...@ce...> - 2004-09-09 18:38:43
|
On Thursday 09 September 2004 09:57, Damian Cugley wrote: > On Thu, 9 Sep 2004 09:18:22 -0700, Sean O'Dell <se...@ce...> wrote: > > A proposal: > > > > Quotes are used as a character escape mechanism, not a typing > > mechanism. > > A lot of people feel a deep emotional need for quotation marks to > distinguish strings from integers, because that is what they expect > from other languages. After all, they will say, you go to immense > pains to distinguish 1.0 from 1 from 2004-09-09 based on how they > look; "1" looks different from 1, so why is it also not > distinguishable? Explaining that this is because the guessing of types > happens too late, after the quotes are stripped, will not make them > happy. Thus older drafts have a special flag passed up from the parser > telling you that this particular item looked more string-y than > int-ish. The current kerfuffle with unspecified-tag tags is an attempt > to come up with a less hacky hack. I've never assumed quotes meant "a string" in a markup language; programming language, yes, but in a markup language it's always appeared as a character escape mechanism to me. I can understand that argument, but coming into YAML for the first time, my gut instinct was that it was an escape mechanism. It sounded odd to hear that it was an indicator for a string type. It made sense when I heard the reason why, but my instinct was that a markup language uses quotes to protect certain characters from being seen as a parsing delimiter. Talking about it for awhile makes it easy for me to see how quotes can be used to indicate a string type. But my initial, gut instinct was: quotes are an escape mechanism. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-09 17:00:57
|
On Thu, Sep 09, 2004 at 09:18:22AM -0700, Sean O'Dell wrote: | Quotes are used as a character escape mechanism, not a typing mechanism. Well, the idea with the ?implicit thing is to provide a hint, but not dictate typing; sorry to not respond to the remainder of your post, but let me try to explain. ... You're right to point out that this is ugly. However, it's an old compromise, and perhaps up for review (see my last-call post). It's not in my role to bring this up, as I've come to accept and work-around the situation. If you do post, I'll follow up with: The distinction is is a compromise. There are two competing desires: - people want to type data based upon the syntax style used in particular, treat quoted stuff as strings and unquoted stuff as other special data types - people also want the ability to have different ways to write the same thing without affecting the 'meaning' of the information; and it'd be nice if this was standardized, so that people didn't have to check how each application treats different styles a more 'formal' version of this is the need to keep presentation information separate from the graph model; if you allow them to blend as the application sees fit, it complicates the APIs and really complicates transformation and schema programs So. Rather than banning the use of style 'outright' we made a compromise. We allow a very limited version of this -- the plain scalar -- but bend over backwards to document the exception and work hard to keep it a 'presentation' issue (ie, you can have the parser report the same exact content using ! "double"). So, it's an inconsistency, but one that I think we have successfully limited and made very visible. The bet is simple -- by giving users who want to use presentation information their biggest bone (plain scalars) we hope that they will respect the other bones (key order, other styles, comments, etc.) and not use this other information to drive processing. With some help of the implementers, we hope this works out. Its an 80/20 thingy. So, while I personally think the rule sucks, it sucks less than all of the other alternatives. And thus, unless someone posts a brilliant alternative that helps resolve this dissonance, I'd rather keep the status quo. If it were just me and the wall, I'd always make unquoted and quoted the same... and alas, with a bit of parser configuration, aka 'strings are king', I can do just that. Best, Clark -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ * |
From: T. O. <tra...@ru...> - 2004-09-09 19:19:26
|
On Thursday 09 September 2004 01:00 pm, Clark C. Evans wrote: > So, while I personally think the rule sucks, it sucks less than all of > the other alternatives. =A0And thus, unless someone posts a brilliant > alternative that helps resolve this dissonance, I'd rather keep the > status quo. =A0If it were just me and the wall, I'd always make unquoted > and quoted the same... and alas, with a bit of parser configuration, > aka 'strings are king', I can do just that. Intersting. I'm really trying understand the ins and outs of ?variants in=20 relation to %TAG. The exception to the rule of ! bugs me. %TAG ! tag:yaml.org,2002:str # is this legal? --- - ! "23" # !!str 23 or ?variant 23 If we think of ! as NULL-tag the all maps and seqs would be strs too? Sill= y.=20 Is %TAG ! and %TAG !! limited to just a "domain"? What does this mean? --- - !! "23" On the other hand, is ! just a shorthand for ?variant --that would kind of= =20 second guess the whole "you can't write em in the doc" thing.=20 I know we can't use just '?' b/c of map keys, right? So this would not even= be=20 thinkable: --- - ? "23" Why was '?' chosen for null-value maps anyway? Perhaps, --- - !? "23" now I'm getting excitedly confused ;) Please Help! T. |
From: T. O. <tra...@ru...> - 2004-09-09 19:32:05
|
On Thursday 09 September 2004 02:30 pm, Sean O'Dell wrote: > a) If quotes mean !!str, then load all scalars equal, keep the quotes with > the value and strip them off during the implicit typing phase. That's an interesting approach. So they are all scalars, the quotes and all get passed on. The implementation can decide what to do with it. The resolution part of the spec can specify that they ought to become escaped strings, but of course the application can decide otherwise if it wants. Those canonical forms, I take it, would include all of these - "string" - 'string' - > string - | string Then we would need only the three variant / implicit null-tags: ?mapping, ?sequence, ?scalar. I have to admit that seems nice nice. -- T. |
From: Sean O'D. <se...@ce...> - 2004-09-09 19:48:26
|
On Thursday 09 September 2004 12:32, T. Onoma wrote: > > So they are all scalars, the quotes and all get passed on. The > implementation can decide what to do with it. The resolution part of the > spec can specify that they ought to become escaped strings, but of course > the application can decide otherwise if it wants. Those canonical forms, I > take it, would include all of these > > - "string" > - 'string' > - > > string > - | > string > > Then we would need only the three variant / implicit > null-tags: ?mapping, ?sequence, ?scalar. > > I have to admit that seems nice nice. Yes, and I'm okay with option (a) as well, although I prefer (b). (a) works for me...what DOESN'T work is that pre-pre-typing phase where !!str gets tagged before the other types get tagged. On or off, but not off, halfway on, then fully on. You know? I see no reason for a premature partial typing phase. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-09 19:54:26
|
On Thu, Sep 09, 2004 at 03:32:01PM -0400, T. Onoma wrote: | On Thursday 09 September 2004 02:30 pm, Sean O'Dell wrote: | > a) If quotes mean !!str, then load all scalars equal, keep the quotes with | > the value and strip them off during the implicit typing phase. | | That's an interesting approach. | | So they are all scalars, the quotes and all get passed on. | The implementation can decide what to do with it. I don't think so. You've just done what I considered the worst case, made the application have to be concerned about various styles and/or have to do unescaping. This 'wart' is less-worse. *winks* ;) Clark |
From: Sean O'D. <se...@ce...> - 2004-09-09 20:12:14
|
On Thursday 09 September 2004 12:54, Clark C. Evans wrote: > On Thu, Sep 09, 2004 at 03:32:01PM -0400, T. Onoma wrote: > | On Thursday 09 September 2004 02:30 pm, Sean O'Dell wrote: > | > a) If quotes mean !!str, then load all scalars equal, keep the quotes > | > with the value and strip them off during the implicit typing phase. > | > | That's an interesting approach. > | > | So they are all scalars, the quotes and all get passed on. > | The implementation can decide what to do with it. > > I don't think so. You've just done what I considered the worst case, > made the application have to be concerned about various styles and/or > have to do unescaping. This 'wart' is less-worse. Not entirely right there. The implicit typing phase could strip off outer quote characters as it tags the scalar a !!str, so the application would just get a normal string value tagged as !!str. The end result is that the application would get the same exact value+tag as currently, we'd just be eliminating that extra middle phase of half-typed graphs. Sean O'Dell |
From: T. O. <tra...@ru...> - 2004-09-09 20:15:33
|
On Thursday 09 September 2004 03:54 pm, Clark C. Evans wrote: > I don't think so. You've just done what I considered the worst case, > made the application have to be concerned about various styles and/or > have to do unescaping. This 'wart' is less-worse. > > *winks* Maybe not, b/c the deal with Oren is that the resolution thing is part of spec now. So application doesn't deal with it, resolution does. The cool thing about resolution is that's this half-way point between YAML and application. This is were they first meet. So there would be no difference in behavior, normally. It just opens it up for the application to "interject" if it wants --just like it does for ?implicit/variants. -- T. |
From: Oren Ben-K. <or...@be...> - 2004-09-09 19:51:02
|
On Thursday 09 September 2004 22:19, T. Onoma wrote: > Intersting. I'm really trying understand the ins and outs of > ?variants in relation to %TAG. The exception to the rule of ! bugs > me. There are no "ins" and "outs". Well, just a few :-) One way to look at it: "!" is simply something else ("I have no tag"). Obviously %TAG doesn't affect nodes without a tag. Hence %TAG doesn't affect "!". Another way: %TAG defines a prefix. In YAML, to use a prefix, you need a suffix. That is, in both "!suffix" and "!handle!suffix", suffix is mandatory. Since there's no suffix in a simple ! (or a simple !!), %TAG doesn't apply. We give a meaning to ! (unspecified tags) and reserve !! for future use (its currently simply invalid). %TAG !s! tag:yaml.org,2002:str # is this legal? > %TAG ! tag:yaml.org,2002:str # is this legal? > --- - !s!foo "23" # tag:yaml.org,2002:strfoo - !foo "23" # tag:yaml.org,2002:strfoo - !! "23" # Invalid today. - ! "23" # ?var - has unspecified tag > I know we can't use just '?' b/c of map keys, right? Right. > Why was '?' chosen for null-value maps anyway? Choosing another character wouldn't have helped, unles we were willing to define a new top indicator - which I think is an overkill. > --- > - !? "23" No. This is a private, specific tag, called '!?'. It doesn't start with a '?'. > Please Help! I hope I did. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@be...> - 2004-09-09 20:00:54
|
On Thursday 09 September 2004 22:50, Oren Ben-Kiki wrote: > - !s!foo "23" # tag:yaml.org,2002:strfoo > - !foo "23" # tag:yaml.org,2002:strfoo > - !! "23" # Invalid today. > - ! "23" # ?var - has unspecified tag - !s! "23" # invalid as well For consistency. Nice catch - these details needed working out. Have fun, Oren Ben-Kiki |
From: T. O. <tra...@ru...> - 2004-09-09 20:38:43
|
On Thursday 09 September 2004 03:50 pm, Oren Ben-Kiki wrote: > "!" is simply something else ("I have no tag"). Obviously %TAG doesn't > affect nodes without a tag. Hence %TAG doesn't affect "!". Does help. But that def. is too broad per my point out that it cause a contradiction. (a) "23" same as ! "23" (b) ! "23" means 23 hence "23" same as 23 ? No. So saying ! means "I have no tag" is not precise. In (b), ! is being used as a special operator to convert ?string to ?plain. This is different. This is blah (livable but blah). I like Sean's idea better: dealing with non-plain/escaping in resolution phase. Thinking of scalars in this way had not previously been the general concensus. Currently - | string - > string - "string" are all the same thing, just with different formatting. But now the will be considered ?string. But in fact the first two really don't make much sense as ?string cause they HAVE to end up as !!str if the formating is to be meaningful. Moreover, - string is really the same deal. Its a "string" with special formating --plain. So now you've added context: - Nodes with specified tags are loaded by-tag. - Nodes with unspecified tags are loaded by-content ... and context (path to the node). you might as well take the next step and add ... and scalar style Then, the spec will just have the three variants ?mapping, ?sequence and ?scalar. Then we move !!str to repository and define canonical forms for | > " " and so forth. -- T. |
From: T. O. <tra...@ru...> - 2004-09-10 01:09:15
|
On Thursday 09 September 2004 04:00 pm, Oren Ben-Kiki wrote: > On Thursday 09 September 2004 22:50, Oren Ben-Kiki wrote: > > - !s!foo "23" # tag:yaml.org,2002:strfoo > > - !foo "23" # tag:yaml.org,2002:strfoo > > - !! "23" # Invalid today. > > - ! "23" # ?var - has unspecified tag > > - !s! "23" # invalid as well > > For consistency. Nice catch - these details needed working out. Oren, I'm starting to think your NULL proposal might be better. An empty tag would mean "unspecified", and the kind would of course be available. In addition, the scalar content could keep it's style, i.e. plain, quoted, doublequoted, folded, literal, or we could have a style variable for that. Add in context, and resolution would be very flexible. Plus the spec could remain completely free of any kind of special tags. Per the style on the scalar. The default spec behavior would be as it is now. But it is conceivable that an application might want to specify literal scalars as something other then it that for the other non-plain scalars, etc. For instance, all folded scalars might be made !!notes, while all literals made !!notices. Granted, it probably seems odd to those who would rather have _all_ the scalars undifferentiated. But the fact is, they are not. So instead of making one style special above the rest --the wart, just allow all the scalars to be what they are. T. |
From: Clark C. E. <cc...@cl...> - 2004-09-11 03:36:58
|
On Thu, Sep 09, 2004 at 09:09:06PM -0400, T. Onoma wrote: | I'm starting to think your NULL proposal might be better. An empty tag | would mean "unspecified", and the kind would of course be available. I don't want to re-open this issue. However, for your information, the only version of a NULL proposal that I find acceptable has exactly one "kind" of NULL (my gripe was with 3 kinds of NULL), untagged mapping => tag:yaml.org,2002:map untagged sequence => tag:yaml.org,2002:seq untagged plain scalar => NULL untagged other scalar => tag:yaml.org,2002:str ! tagged other scalar => NULL with resolution limited to the content of each NULL scalar (via regular expressions). Yes, it's magical, but it's managed. | For instance, all folded scalars might be made !!notes, | while all literals made !!notices. No way. That would seriously undermine the whole idea of presentation vs representation. In other words, it is a feature of YAML that you can mess around with the styles and other presentation to make it look how you would like it to appear without worrying about the application treating it differently. Yes, the untagged plain scalar is an exception. However, it is one with historical significance, and we've worked hard to limit its impact. Cheers, Clark |
From: Oren Ben-K. <or...@be...> - 2004-09-10 07:25:30
|
On Friday 10 September 2004 04:09, T. Onoma wrote: > > ... Nice catch - these details needed working out. > > Oren, > > I'm starting to think your NULL proposal might be better. Well... other people don't. Besides: > An empty > tag would mean "unspecified", and the kind would of course be > available. In addition, the scalar content could keep it's style, > i.e. plain, quoted, doublequoted, folded, literal, or we could have a > style variable for that. Add in context, and resolution would be very > flexible. Plus the spec could remain completely free of any kind of > special tags. -100. No way we are letting the full scalar style affect the way its loaded. The horror! If 23 is a plain scalar, its an int. If its single quoted, its an ASCII character code. If its double quoted, its a string. If its a folded block, its an invoice id. If its a literal block, it is an age in years. Completely and utterly out of the question. We have an inherent problem in people taking "23" to be inherently different from 23. We must cater to that to be friendly to human readers. Yes, that's a chink in our armor. You are very good at detecting such chinks and "driving trucks through them". But not this time :-) we are well aware this is a wart - a less ugly wart given the '?unspecified' tags, but still wart-ish - and we are not going to let it grow one iota :-) Have fun, Oren Ben-Kiki |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-11 01:24:59
|
On Friday 10 September 2004 01:34 am, Oren Ben-Kiki wrote: > > An empty > > tag would mean "unspecified", and the kind would of course be > > available. In addition, the scalar content could keep it's style, > > i.e. plain, quoted, doublequoted, folded, literal, or we could have a > > style variable for that. Add in context, and resolution would be very > > flexible. Plus the spec could remain completely free of any kind of > > special tags. > > -100. No way we are letting the full scalar style affect the way its > loaded. The horror! If 23 is a plain scalar, its an int. If its single > quoted, its an ASCII character code. If its double quoted, its a > string. If its a folded block, its an invoice id. If its a literal > block, it is an age in years. > > Completely and utterly out of the question. "Me thinks ye doth protest _too_ much." > We have an inherent problem in people taking "23" to be inherently > different from 23. We must cater to that to be friendly to human > readers. Yes, that's a chink in our armor. I don't see how catering to humans is a bad thing (as long as the computer can reasonably handle it). That's one of the best things about YAML! > You are very good at detecting such chinks and "driving trucks through > them". But not this time :-) we are well aware this is a wart - a less > ugly wart given the '?unspecified' tags, but still wart-ish - and we > are not going to let it grow one iota :-) I'm not trying drive trucks through chinks. I'm simply taking what _we_ have noted as issues, working to clearly understand the problems, and then offering up any potential solutions I come across. Actually I'm not even offering up the solutions myself, rather, I have just put a couple of ideas together that other's have expoused and the results followed. Moreover, and _most importantly_, I am presently _using_ YAML, and some of this stuff _is_ biting me in the arse, Right Now! (Read that last statement three times for emphasis.) So my intent is not subversion. My intent is to have a tool work for me, and thus by extension to work for others. My intent is help YAML be supreme. T. -- ( o ) // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: Oren Ben-K. <or...@be...> - 2004-09-11 04:10:20
|
On Friday 10 September 2004 14:24, trans. (T. Onoma) wrote: > On Friday 10 September 2004 01:34 am, Oren Ben-Kiki wrote: > > -100. No way we are letting the full scalar style affect the way > > its loaded... > > > > Completely and utterly out of the question. > > "Me thinks ye doth protest _too_ much." No, we really mean it :-) Have fun, Oren Ben-Kiki |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-11 04:54:36
|
On Thursday 09 September 2004 11:08 pm, you wrote: > On Thu, Sep 09, 2004 at 09:09:06PM -0400, T. Onoma wrote: > | I'm starting to think your NULL proposal might be better. An empty tag > | would mean "unspecified", and the kind would of course be available. > > I don't want to re-open this issue. However, for your information, the > only version of a NULL proposal that I find acceptable has exactly one > "kind" of NULL (my gripe was with 3 kinds of NULL), Reopen? It hasn't even been on the table for more than two days! Given this= =20 I'd like to make an observation. The historical YAML specs you just gave links for was very interesting. I=20 enjoyed looking them over and seeing the progression. Quite fascinating. Ye= t=20 there seems quite a few "major" versions. P.S. This doesn't have every version, but it does have the major =A0versions that were on the web site for "extended" periods of time. My point being simply that maybe slowing down on the "closing" of issues mi= ght=20 not be a bad idea. Give things time to settle in, before saying "that's=20 that." MHO. > untagged mapping =3D> tag:yaml.org,2002:map > untagged sequence =3D> tag:yaml.org,2002:seq > untagged plain scalar =3D> NULL > untagged other scalar =3D> tag:yaml.org,2002:str > ! tagged other scalar =3D> NULL > > with resolution limited to the content of each NULL scalar (via > regular expressions). Yes, it's magical, but it's managed. Why back? Recall that NULL and ?unspecified are equivalent in function, jus= t=20 not form. The above propsal is essentially how the current spec works --no= =20 change.. Besides that, under any of the proposals the default outcome will= =20 be: untagged mapping =3D> tag:yaml.org,2002:map untagged sequence =3D> tag:yaml.org,2002:seq untagged plain scalar =3D> tag:yaml.org,2002:str/or implicit type untagged other scalar =3D> tag:yaml.org,2002:str ! tagged other scalar =3D> tag:yaml.org,2002:str/or implicit type Which is what you want. But your proposal _forces_ the the application into= =20 these --only the plain-scalar is given any room to be implicitly resolved.= =20 > | For instance, all folded scalars might be made !!notes, > | while all literals made !!notices. > > No way. That would seriously undermine the whole idea of presentation > vs representation. In other words, it is a feature of YAML that you > can mess around with the styles and other presentation to make it look > how you would like it to appear without worrying about the application > treating it differently. Yes, the untagged plain scalar is an > exception. However, it is one with historical significance, and we've > worked hard to limit its impact. Well, you have already done that with the plain-scalar. So it can't be all = the=20 serious. You have already expressed your opinion that you'd prefer to get rid of pla= in=20 scalar too. You again seem more interested in setting up theoretical=20 bonderies then letting people get things done. I grant you, there needs to = be=20 things like a model, etc. But you also have to deal with the practical=20 divisions that arise from it. If you want something reasonably elegant then= =20 you have the two options. It's you that has numerously complained about thi= s=20 wart too. Enough about "theory". Here's practice. What about emitting? How will the application control that. If we draw such= a=20 harsh distinction between presentation and representation how will I tell m= y=20 Notice object to emit as a literal, not folded, etc. There is no doubt that= =20 "presentation" can be wrapped up with semantics. This being the case, you=20 have to let the application account for it --since semantics belongs to the= =20 application.=20 Though lines need be drawn, they should be put in reasonable places. T. ( o __ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: Clark C. E. <cc...@cl...> - 2004-09-11 05:17:38
|
On Thu, Sep 09, 2004 at 11:48:06PM -0400, trans. (T. Onoma) wrote: | The historical YAML specs you just gave links for was very interesting. | I enjoyed looking them over and seeing the progression. Quite fascinating. | Yet there seems quite a few "major" versions. | | P.S. This doesn't have every version, but it does have the major | versions that were on the web site for "extended" periods of time. | | My point being simply that maybe slowing down on the "closing" of | issues might not be a bad idea. Give things time to settle in, | before saying "that's that." MHO. Well, how it has historically worked... about every 6 months we get a bit of free time (well, in my case borrowed time, beacuse my projects usually get a bit behind and I have to catch-up later). We hammer back and forth "lessons-learned" from the previous period, usually change a few things. If you notice in the history, the frequence of updates has _slowed_ dramatically; I like to think of it as reaching a farily sweet spot. Then, after we reach some agreements, we all usually went our own ways, made spec and implementation changes, and about 2 weeks later a new "version" appeared on the website. So, I figure most of these discussions will be up in a few weeks. However, also historically, issues rage for a week or so, and then we have agreement, and things just magically fit. On some occasions, after the 2 week "cool down" period, we have another quick iteration -- if one of us is really unhappy with the results. And then, the cycle repeats; either 2 weeks after that, or another 6 months later. So, I figure in 2 weeks or so we will probably be quite happy with this, or we will get irritated and the whole thing will cycle again! But the 'closed' issue I was saying, was more or less not that it is final, but that we can 'go back to our day jobs' without worrying that someone's going to start the debates again! Anyway... this one seemed to have been worth it. You and Sean were right to push and push on the wart. ;) | You have already expressed your opinion that you'd prefer to get rid of | plain scalar too. You again seem more interested in setting up | theoretical bonderies then letting people get things done. I grant you, | there needs to be things like a model, etc. But you also have to deal | with the practical divisions that arise from it. If you want something | reasonably elegant then you have the two options. It's you that has | numerously complained about this wart too. Well, ballence is the key. But ballence does not mean that what is most pratical wins. ;) | What about emitting? How will the application control that. If we draw | such a harsh distinction between presentation and representation how | will I tell my Notice object to emit as a literal, not folded, etc. | There is no doubt that "presentation" can be wrapped up with semantics. | This being the case, you have to let the application account for it | --since semantics belongs to the application. Oh, I have _zero_ problem with schema, or even with 'shadow' nodes. There are lots of approaches to this problem. And you are rightly concerned. Parsers have gotten much of the focus, perhaps this next 6 months should be spent on a decent emitter (I have not looked at _why's yet, so this isn't a takedown). The specification has 3 models, for three different sets of concerns. Application should have _direct_ control over the Emitter's Presentation Interface. | Though lines need be drawn, they should be put in reasonable places. That is certain. Cheers! Clark |
From: Sean O'D. <se...@ce...> - 2004-09-13 18:11:53
|
On Friday 10 September 2004 22:17, Clark C. Evans wrote: > > So, I figure in 2 weeks or so we will probably be quite happy with this, > or we will get irritated and the whole thing will cycle again! But the > 'closed' issue I was saying, was more or less not that it is final, but > that we can 'go back to our day jobs' without worrying that someone's > going to start the debates again! Anyway... this one seemed to have been > worth it. You and Sean were right to push and push on the wart. ;) I hope my obsessive desire for "simple and uniform" will have caused some of you to think more "outside the box" and get away from delving deeper and deeper into problems rather than working them cleanly from the outside, top-down and holistically. I don't have time to keep up with all the changes around here, so I won't make comment on any recent suggestions, but it seems like I turned some wheels, so I'll leave it to you guys to hash out for awhile. You're a smart group of folks, I'm sure in time you'll have YAML shining. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-13 18:35:42
|
On Mon, Sep 13, 2004 at 11:11:02AM -0700, Sean O'Dell wrote: | I hope my obsessive desire for "simple and uniform" will have caused | some of you to think more "outside the box" and get away from delving | deeper and deeper into problems rather than working them cleanly from | the outside, top-down and holistically. Well, so far, a majority of the vocal people here are preferring to keep the wart. It was a long discussion, and we're right back where we started (with a nice flesh colored bandaid of one sort or another), but perhaps everyone will now be happier with the status-quo and we can bettery defend our desire to be inconsistent. Cheers, Clark |
From: Sean O'D. <se...@ce...> - 2004-09-13 19:21:07
|
On Monday 13 September 2004 11:35, Clark C. Evans wrote: > On Mon, Sep 13, 2004 at 11:11:02AM -0700, Sean O'Dell wrote: > | I hope my obsessive desire for "simple and uniform" will have caused > | some of you to think more "outside the box" and get away from delving > | deeper and deeper into problems rather than working them cleanly from > | the outside, top-down and holistically. > > Well, so far, a majority of the vocal people here are preferring to > keep the wart. It was a long discussion, and we're right back where > we started (with a nice flesh colored bandaid of one sort or > another), but perhaps everyone will now be happier with the > status-quo and we can bettery defend our desire to be inconsistent. Don't be afraid to go against popular opinion to get to a clean, clear design. It's good to listen to people's ideas, but it's not so good to become a slave to a dozen sources of input. Sean O'Dell |