From: Denis H. <db...@do...> - 2004-02-06 15:07:03
|
You've probably considered and rejected this idea already, but... It would be nice, for human readability, to have the option of omitting the [] round a simple inline sequence: colours: red, green, turquoise, blue You could no longer distinguish a scalar from a one-element list but I'd be happy to deal with that in higher level code in exchange for getting rid of the ugly brackets. Obviously this only works for one level sequences. Structured elements would need brackets though you're less likely to have structured elements in an inline sequence. (You could probably come up with a sensible interpretation even if you also allowed unbracketed inline mappings, but sequences are more important). -- Denis Howe <db...@do...> Free On-Line Dictionary of Computing http://www.foldoc.org/ |
From: Clark C. E. <cc...@cl...> - 2004-02-06 16:21:40
|
Hello Denis. | It would be nice, for human readability, to have the option of | omitting the [] round a simple inline sequence: | | colours: red, green, | turquoise, | blue This really is a great idea, and I've often thought of it (in fact I was musing about re-proposing this change in December, but we were trying to freeze the spec), in fact, I'm sure you can dig back in the archives where it is debated. It is probably too late to add it in at this time. | You could no longer distinguish a scalar from a one-element list but | I'd be happy to deal with that in higher level code in exchange for | getting rid of the ugly brackets. Let me explain the historical context. When we decided to require brackets we had use cases like $3,239.00 that we really needed to be plain scalars. At that time, we didn't distinguish between [23,2] and [23, 2] which are now completely different animals. The first one is a sequence with a single scalar "23,2" and the second is a sequence with two scalars "23" and "2". This distinction is reflected in production nb-plain-flow-char. Anyway, after we introduced this distinction, I don't think we circled back around and asked if we wanted to make top level sequences 'optional'. And now, with the two short hand mechanisms [ a: 23, b: 33 ] it may be impossible without adding yet another context sensitive switch (the inline-map-in-seq without-outer-backets case). I'm not really sure if we want to go there, and, probably more importantly, we would definately be breaking old documents which did work previously: company: Prometheus Research, LLC. street: 315 Whitney, Carriage House The two items above seem like compeling case to keep things as they are. | Obviously this only works for one level sequences. Structured | elements would need brackets though you're less likely to have | structured elements in an inline sequence. This was probably another factor in our decision, Oren tends to think of stuff like this (his nick name is, after all, MonkeyWrench). | (You could probably come up with a sensible interpretation even if you | also allowed unbracketed inline mappings, but sequences are more | important). Yes. I'm open to reconsider it. But it is getting awfuly late, and this would be the first "major" break with previously valid YAML documents. Our other two breaks this year have been extremely strange edge cases which most parsers didn't implement anyway. Then again, YAML is not so prevalent that one-last-change would hurt; I'd hate to be like "make" whose author was so worried about breaking the 10 customers he had that he decided not to remove the dependency on tab characters... Clark |
From: Sean O'D. <se...@ce...> - 2004-02-06 17:33:24
|
On Friday 06 February 2004 08:21 am, Clark C. Evans wrote: > Hello Denis. > > | It would be nice, for human readability, to have the option of > | omitting the [] round a simple inline sequence: > | > | colours: red, green, > | turquoise, > | blue > > This really is a great idea, and I've often thought of it (in fact I was > musing about re-proposing this change in December, but we were trying to > freeze the spec), in fact, I'm sure you can dig back in the archives where > it is debated. It is probably too late to add it in at this time. So, scalars with commas in them now would have to be quoted to be seen as string types? Meaning, the address line: MyTown, USA ...would appear as an array? Sean O'Dell |
From: Oren Ben-K. <or...@be...> - 2004-02-06 17:25:12
|
Denis Howe wrote: > It would be nice, for human readability, to have the option > of omitting the [] round a simple inline sequence: > > colours: red, green, > turquoise, > blue Tempting as it is, Clark correctly pointed out, that would rule out common use cases: Date: January 1st, 2004 Names: Howe, Denis Addresses: 1450 Broadway, New-York, NY, USA You could argue the case that these are actually lists, but that's just not how such data is treated by programs - or humans, for that matter. Luckily, the cost of two additional characters isn't that much to pay when one is writing a collection. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2004-02-07 03:51:30
|
On 06/02/04 19:24 +0200, Oren Ben-Kiki wrote: > Denis Howe wrote: > > It would be nice, for human readability, to have the option > > of omitting the [] round a simple inline sequence: > > > > colours: red, green, > > turquoise, > > blue > > Tempting as it is, Clark correctly pointed out, that would rule out > common use cases: > > Date: January 1st, 2004 > Names: Howe, Denis > Addresses: 1450 Broadway, New-York, NY, USA > > You could argue the case that these are actually lists, but that's just > not how such data is treated by programs - or humans, for that matter. > Luckily, the cost of two additional characters isn't that much to pay > when one is writing a collection. I am surprised that nobody mentioned that, theoretically anyway, an application is free to load a node as sees fit. So, theoretically anyway, you could write an application that loaded these values as collections. One would hope, from a YAML perspective anyway, that you would serialize the objects back as plain scalars. You could also have an application that serialized tables like such: --- table: | +-----+-----+-----+ | 5 | 3 | 1 | +-----+-----+-----+ | 7 | 6 | 5 | +-----+-----+-----+ | 9 | 2 | 9 | +-----+-----+-----+ and load the scalar back in as a table again. I am not endorsing that any general purpose YAML tool provide these mechanisms, or that they become standard, but they are definitely within our confines. Cheers, Brian |
From: Brian I. <in...@tt...> - 2004-02-07 03:59:26
|
On 06/02/04 19:51 -0800, Brian Ingerson wrote: > On 06/02/04 19:24 +0200, Oren Ben-Kiki wrote: > > Denis Howe wrote: > > > It would be nice, for human readability, to have the option > > > of omitting the [] round a simple inline sequence: > > > > > > colours: red, green, > > > turquoise, > > > blue > > > > Tempting as it is, Clark correctly pointed out, that would rule out > > common use cases: > > > > Date: January 1st, 2004 > > Names: Howe, Denis > > Addresses: 1450 Broadway, New-York, NY, USA > > > > You could argue the case that these are actually lists, but that's just > > not how such data is treated by programs - or humans, for that matter. > > Luckily, the cost of two additional characters isn't that much to pay > > when one is writing a collection. > > I am surprised that nobody mentioned that, theoretically anyway, an > application is free to load a node as sees fit. So, theoretically > anyway, you could write an application that loaded these values as > collections. One would hope, from a YAML perspective anyway, that you > would serialize the objects back as plain scalars. > > You could also have an application that serialized tables like such: > > --- > table: | > +-----+-----+-----+ > | 5 | 3 | 1 | > +-----+-----+-----+ > | 7 | 6 | 5 | > +-----+-----+-----+ > | 9 | 2 | 9 | > +-----+-----+-----+ > > and load the scalar back in as a table again. > > I am not endorsing that any general purpose YAML tool provide these > mechanisms, or that they become standard, but they are definitely within > our confines. Just to give a quick example. Say you had a config file format, and you didn't want to put the burden of learning too much YAML on your users. You could definitely split strings into lists for that application. And at that point you could split on commas, semicolons, spaces, whatever. # my config name: Pants McGee favorite colors: blue red pink Favorite colors could definitely be made to be a list internally. Since for this use case, serialization is not even considered, you don't need to worry about roundtripping. I the final analysis, I agree with Oren that no changes to YAML are necessary. You definitely have enough rope! Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-02-07 10:25:57
|
Brian Ingerson wrote: > I am surprised that nobody mentioned that, theoretically anyway, an > application is free to load a node as sees fit. So, theoretically > anyway, you could write an application that loaded these values as > collections. One would hope, from a YAML perspective > anyway, that you > would serialize the objects back as plain scalars. The spec uses such types in its examples already: Dates. A date can be thought of as being a mapping (with year, month, day, hour, minute, second keys). Some system actually use this as their internal representation. YAML doesn't care, as long as you re-emit dates as scalars. If you re-emit a dates as a collection, then from YAML's point of view you have created a completely different document (obeying a different schema, having a different digital signature, allowing for different YPATH expressions, and so on). So yes, this is a perfectly valid approach. Of course, you are missing out on a lot that YAML has to offer, such as being able to write "/birthday/year" and easily specifying in a schema that the valid values for some date are only business hours in work days. You can approximate this by using regexps and type-specific knowledge, but it isn't the same thing. Still, this is a legitimate design choice. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@be...> - 2004-02-07 18:44:40
|
This is a capture of a discussion Clark and I just had. The end result was that we decided to keep things as they are, so you can safely skip that. However, if you are interested _why_ we made this decision, read ahead at your own peril (this is unedited): cce: oh, there was another topic oren: ? cce: regarding brian's post, what you said was clear cce: let's muse here for a min though cce: you cant' have a 'complete' graph till it has been 'resolved' cce: by 'resolving', tags are added to the tree oren: or graph oren: or text, if you are sick :-) cce: assume for a minute that in the resolving phase, structural transformations are allowed in the subtree ;) oren: Then you are no longer merely loading the document, you are transforming it. Valid and all, but out of scope. cce: ie "2002-10-10" becomes !date { !str 'year': !int 2002, ... } oren: As long as you do the reverse when you dump - and be aware that you have _changed_ the document. cce: however, does it make sense to restrict a given 'tag' to a given kind. cce: ie !date 2002-10-10 and !date { ... } oren: Hmmm. cce: could we 'verify' why this constraint is necessary? oren: Strictly speaking, it isn't. cce: Well, I think the restriction is somewhat there oren: Oh, its there alright. cce: ie, a untagged plain scalar can be changed to a 'structure' during the tagging process cce: ie 2002-10-2 is ok, but !date '2002-10-2' isn't. oren: Boggles. cce: ie, if the tag is implicit (not in the text stream) it is ok cce: hmm. oren: Another angle on this. Schema evolution. cce: brb (thinking bout an explanation) oren: Suppose a scalar "evolves" to a collection... cce: ya, so our diagram is wrong oren: <groan> not another diagram </groan> cce: a kind is a property of a node, and not the tag oren: Not so fast. I might be convinced, but let's talk. cce: (making coffee, so give me about 1 min) oren: The question that needs to be answered, if you do that, is: What is the relationship between !tag <scalar>, !tag <sequence>, and !tag <mapping> ? Is there some mandatory relationship, or are these unrelated types (as far as YAML is concerned)? The answer is tricky. cce: lets use date as a test case cce: if I were representing, say a python date in YAML, it would definitely be a mapping. oren: I'd rather keep in mind the case of schema evolution as well. It sharpens the issue (or raises additional issues, if you will). cce: A yaml date object has several 'attributes', month, day, year, etc. cce: ok, evolution is also important oren: At any rate, go on. What is your view on the relationship issue? cce: anyway, so really 4 Mar 2004 should really be represented in YAML as { day: 4, month: 3, year: 2004 } cce: the '2004-03-04' is a presentation 'short hand' cce: its there to make the text stream readable cce: ok, let's call that the 'date problem' cce: now, let's talk about the integer problem oren: I didn't know there was one. cce: this one is simpler ten can be presented as 10, or 1A for example cce: how we deal with integers is that we say that the 'tag' must provide a canonical form oren: Ah. That one. cce: and then we can compare the canonical forms oren: Right. cce: who is to say that a canonical form can't actually be a sub-graph? cce: ie, the canonical form of my text date is that mapping oren: That's nice and all. But... let's see what happens to unknown types. cce: remember, I can't compare dates unless they are known anyway oren: Right. But, it used to be I could safely apply YPATH. cce: so, there isn't anything lost, right? oren: I can't safely say /birthday/year cce: ypath can still be applied oren: Not without schema knowledge. oren: /birthday/year will fail unless !date is resolved and recognized. cce: but ypath really could do much with scalar types without knowing the data type anyway. cce: /birthday/substring(1,4) isn't garmented to work either cce: because date could have come in another format other than ISO oren: Well, at least it returned something - something you could, say, print to the user. Now, I don't know what I'll be getting. oren: I don't know how important this is, but it is a loss. cce: hmm oren: You are basically saying: if you don't know the schema, well, you can't do much anyway, and it doesn't make sense to punish one who _does_ know the schema so you ignorant one will have some mostly-broken feature. oren: There is some sense in that, I guess. cce: well, I think it only makes sense for scalars you don't know about cce: I wouldn't extend it to structures oren: Slippery slope here... cce: ya oren: Can I change { 0: a, 1: b, 2 : c} to a sequence? cce: but we already are treating collections different than scalars -- as right we should, a scalar is OPAQUE to YAML. cce: no. cce: absolutely not oren: Because...? oren: Give me an argument that justifies forbidding it, if I can change '2002-01-02' to a mapping. What is true for collections that isn't for scalars? cce: because both of these structures are _not_ opaque to YAML cce: and they are different oren: Well, the { year: ... } mapping is also not opaque, so it is different from anything opaque like '2002-...'. Same argument. cce: what is true for scalars isn't true for collections, yes. cce: well, its tough oren: Consider this again. What would be the down side of allowing this? cce: it would break wysiwyg oren: It would mean that the connection between the model-as-visible in the file and the model-as-used for constructing objects may be different. wysiwyg, exactly. cce: ick oren: I would claim that '2004-02-01' being a map is also not wysiwyg. oren: I don't see what's special about the scalar case. It seems to me that the consistent thing is to either allow it everywhere or nowhere. cce: hmm oren: Before we decide, let's revisit schema evolution. cce: no, you are right, scalar -> map is not wysiwyg oren: We have the '=' key exactly to allow a scalar to evolve to a mapping. cce: right oren: Which is impossible if we say tag=>kind; once you set it, you set it. You could say !bloop#new-version but that's different. oren: As in !foo#1.0 is a scalar and !foo#2.0 is a mapping. cce: ya, I was fretting about this in November but didn't really bring it up oren: But you can't evolve !foo from a scalar to a mapping. cce: however, the !cast item is really introducing a simple transform cce: !equal = key oren: Now, if you liberally use implicit typing, that's not an issue, really. cce: right oren: The system will load one as !foo#1.0 and the second as !foo#2.0. Which is better, I think. oren: It can also _transform_ from !foo#1.0 to !foo#2.0 if it wants. Again, that's _changing_ the document. cce: right cce: these things are mutators oren: So, schema evolution doesn't require us to allow this sort of transformational trickery in the processor. On the other hand, if we did allow your trickery, one _could_ put it there and get a different schema evolution mechanism. But I'd claim it would mix people up. oren: I think I'd rather keep things as they are... cce: hmm cce: can you archive this discussion and post? Clark then summarized: cce: ok, let me recap. The question was, if equality is defined only if you know the tag, why restrict the tag to a particular kind (and no other kinds)? cce: the example used was a date, which could be seen as a scalar or a mapping, and why not allow the scalar to be promoted to a mapping; cce: but then, one would be violating wysiwyg cce: ie, the text file in YAML would be quite different than what one got via YPATH and/or schema tools cce: schema -> structural schema cce: hmm cce: why is this bad again? cce: cce is lacking sleep. oren: "YAML is WYSISYG for data" is a good slogan. We don't want to give it up. cce: ok oren: That's the whole _point_ of YAML... Well, there you have it. Tag still implies kind, and you can't willy-nilly convert a date to a mapping. That's life. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-02-07 21:11:48
|
A bit of follow up chat, we discussed if we should make all tagged scalars in a presentation canonical form. The idea didn't buy us anytyhing, so it got dropped. You don't need to read, just here for archival pruposes... Clark cce: Oh... I know where I was going with this. cce: oren.. you still there? oren: ? cce: What I was thinking... is that all TAGGED nodes in a YAML stream _must_ be in canonical form. cce: --- cce: one: 0xA cce: two: 10 cce: three: !int 10 cce: four: !int 0xA=A0 # this is bad form oren: Two points. First, this can only apply to scalars. cce: well collections are always in canonical form... oren: Second, it isn't as useful as you'd like it to be (because of the f= irst). cce: why not? oren: Since even if I tag the collection node, you still can't=20 compare it to another - the scalars are not comparable. cce: ya? oren: --- a: !foo int: 0xA b: !foo int: 10 oren: 'a' and 'b' are tagged. Not comparable unless you know about ints. cce: right, so what is the problem? oren: What's the _use_? cce: /a/int isn't tagged though oren: It isn't exactly a natural restriction, and you don't seem=20 to be gaining anything. cce: actually, I think you are oren: What? cce: it provides an extreme, if you see a scalar tagged in a YAML stream,= =20 you know it is canonical form and you can use it to form complete graphs cce: why not have this restriction? cce: those people worried about 'readabilty' arn't going to be tagging=20 each scalar anyway (in the output stream) oren: Hmmm... It looks like an artificial restriction. cce: it is just a constraint, if you put a tag on the node, its=20 scalar content must be in the tags canonical form oren: s/node/scalar node/ cce: not really, it increases data portaibility cce: (and yes, I agree with your substution) cce: it is a restriction with value, and it doesn' t hurt anyone cce: if you are going to go through the bother of typing a scalar node,=20 just put it in canonical form oren: So the idea is that if I tag every scalar node, a processor will be able to know for certain no tag resolution is required, and YAML becomes= a convenient intermediate format for talking between a "resolver" and the = rest of the system. Interesting. cce: yes oren: Then again, you could just do it "by convention". Have a resolver service that takes a YAML document, resolves the tags, and returns somet= hing with partial tags, where anything not tagged is (say) !str. cce: you have a 'gain' but no real loss (I really can't see a use case fo= r people tagging nodes and _not_ putting them in canonical form) oren: You don't need the restriction, as long as you control the whole system. The benefit is that if I get a document from China, I know it is "complete". Hmmm. cce: and I'm talking strictly about the 'presentation' level here. oren: Well, you are almost defining a canonical document format here. cce: which is useful cce: we arn't going quite far enough to make it canonical cce: BTW, I'd love the extra productions to make a canonical form of YAML= as an appendix.=A0 I wouldn't be _that_ hard.=A0 If I did it could I add it= ? oren: OK, think of it from a human author's point of view: it is incredib= ly tedious to have to tag every scalar. As a human, I'd rather have a direc= tive %COMPLETE saying all untagged scalars are strings, thank you very much, = and save 90% of the typing. cce: (as an appendix) oren: I'm wreaking havoc in the productions now, let the dust settle firs= t=20 cce: ok, but that's another optimization. cce: ie, you'd want that _in addition_ to the restriction oren: Well, the question is, what's the use case? If I'm accepting docume= nts from system A, and I don't know the schema, does it really matter much anyway? cce: if you dont' know the schema, but everything is tagged?=A0 sure oren: What's the use of a complete document with unrecognized types? Abou= t the only thing you could do is digitally sign it. cce: you know it is complete. cce: oh, beyond that though oren: Like what? cce: you could write YPATH expressions on say, dates, and know that substring(1,4) *will* return the year. cce: My sub-system doesn't need to know that information (ie, have a nati= ve date type) for this to be useful. oren: That means you _do_ know the schema - at least for !date. But if yo= u do, you can also canonize on your own. oren: recognize !=3D available! cce: well, I myself the human, know it. cce: I suppose so |
From: Brian I. <in...@tt...> - 2004-02-07 22:07:51
|
Interestig discussion. Let me throw another bone into the soup... We haven't discussed the old !include tag for some time. But it seems to me this will be an example of where a scalar definitely becomes a collection: --- !xyz.com/^thingy items: - !^item x: 5 y: 7 z:9 - !include file://path/to/item We should probably address this now rather than later. Cheers, Brian On 07/02/04 20:44 +0200, Oren Ben-Kiki wrote: > This is a capture of a discussion Clark and I just had. The end result > was that we decided to keep things as they are, so you can safely skip > that. However, if you are interested _why_ we made this decision, read > ahead at your own peril (this is unedited): > > cce: oh, there was another topic > oren: ? > cce: regarding brian's post, what you said was clear > cce: let's muse here for a min though > cce: you cant' have a 'complete' graph till it has been 'resolved' > cce: by 'resolving', tags are added to the tree > oren: or graph > oren: or text, if you are sick :-) > cce: assume for a minute that in the resolving phase, structural > transformations are allowed in the subtree ;) > oren: Then you are no longer merely loading the document, you are > transforming it. Valid and all, but out of scope. > cce: ie "2002-10-10" becomes !date { !str 'year': !int 2002, ... } > oren: As long as you do the reverse when you dump - and be aware that > you have _changed_ the document. > cce: however, does it make sense to restrict a given 'tag' to a given > kind. > cce: ie !date 2002-10-10 and !date { ... } > oren: Hmmm. > cce: could we 'verify' why this constraint is necessary? > oren: Strictly speaking, it isn't. > cce: Well, I think the restriction is somewhat there > oren: Oh, its there alright. > cce: ie, a untagged plain scalar can be changed to a 'structure' during > the tagging process > cce: ie 2002-10-2 is ok, but !date '2002-10-2' isn't. > oren: Boggles. > cce: ie, if the tag is implicit (not in the text stream) it is ok > cce: hmm. > oren: Another angle on this. Schema evolution. > cce: brb (thinking bout an explanation) > oren: Suppose a scalar "evolves" to a collection... > cce: ya, so our diagram is wrong > oren: <groan> not another diagram </groan> > cce: a kind is a property of a node, and not the tag > oren: Not so fast. I might be convinced, but let's talk. > cce: (making coffee, so give me about 1 min) > oren: The question that needs to be answered, if you do that, is: What > is the relationship between !tag <scalar>, !tag <sequence>, and !tag > <mapping> ? Is there some mandatory relationship, or are these unrelated > types (as far as YAML is concerned)? The answer is tricky. > cce: lets use date as a test case > cce: if I were representing, say a python date in YAML, it would > definitely be a mapping. > oren: I'd rather keep in mind the case of schema evolution as well. It > sharpens the issue (or raises additional issues, if you will). > cce: A yaml date object has several 'attributes', month, day, year, etc. > cce: ok, evolution is also important > oren: At any rate, go on. What is your view on the relationship issue? > cce: anyway, so really 4 Mar 2004 should really be represented in YAML > as { day: 4, month: 3, year: 2004 } > cce: the '2004-03-04' is a presentation 'short hand' > cce: its there to make the text stream readable > cce: ok, let's call that the 'date problem' > cce: now, let's talk about the integer problem > oren: I didn't know there was one. > cce: this one is simpler ten can be presented as 10, or 1A for example > cce: how we deal with integers is that we say that the 'tag' must > provide a canonical form > oren: Ah. That one. > cce: and then we can compare the canonical forms > oren: Right. > cce: who is to say that a canonical form can't actually be a sub-graph? > cce: ie, the canonical form of my text date is that mapping > oren: That's nice and all. But... let's see what happens to unknown > types. > cce: remember, I can't compare dates unless they are known anyway > oren: Right. But, it used to be I could safely apply YPATH. > cce: so, there isn't anything lost, right? > oren: I can't safely say /birthday/year > cce: ypath can still be applied > oren: Not without schema knowledge. > oren: /birthday/year will fail unless !date is resolved and recognized. > cce: but ypath really could do much with scalar types without knowing > the data type anyway. > cce: /birthday/substring(1,4) isn't garmented to work either > cce: because date could have come in another format other than ISO > oren: Well, at least it returned something - something you could, say, > print to the user. Now, I don't know what I'll be getting. > oren: I don't know how important this is, but it is a loss. > cce: hmm > oren: You are basically saying: if you don't know the schema, well, you > can't do much anyway, and it doesn't make sense to punish one who _does_ > know the schema so you ignorant one will have some mostly-broken > feature. > oren: There is some sense in that, I guess. > cce: well, I think it only makes sense for scalars you don't know about > cce: I wouldn't extend it to structures > oren: Slippery slope here... > cce: ya > oren: Can I change { 0: a, 1: b, 2 : c} to a sequence? > cce: but we already are treating collections different than scalars -- > as right we should, a scalar is OPAQUE to YAML. > cce: no. > cce: absolutely not > oren: Because...? > oren: Give me an argument that justifies forbidding it, if I can change > '2002-01-02' to a mapping. What is true for collections that isn't for > scalars? > cce: because both of these structures are _not_ opaque to YAML > cce: and they are different > oren: Well, the { year: ... } mapping is also not opaque, so it is > different from anything opaque like '2002-...'. Same argument. > cce: what is true for scalars isn't true for collections, yes. > cce: well, its tough > oren: Consider this again. What would be the down side of allowing this? > cce: it would break wysiwyg > oren: It would mean that the connection between the model-as-visible in > the file and the model-as-used for constructing objects may be > different. wysiwyg, exactly. > cce: ick > oren: I would claim that '2004-02-01' being a map is also not wysiwyg. > oren: I don't see what's special about the scalar case. It seems to me > that the consistent thing is to either allow it everywhere or nowhere. > cce: hmm > oren: Before we decide, let's revisit schema evolution. > cce: no, you are right, scalar -> map is not wysiwyg > oren: We have the '=' key exactly to allow a scalar to evolve to a > mapping. > cce: right > oren: Which is impossible if we say tag=>kind; once you set it, you set > it. You could say !bloop#new-version but that's different. > oren: As in !foo#1.0 is a scalar and !foo#2.0 is a mapping. > cce: ya, I was fretting about this in November but didn't really bring > it up > oren: But you can't evolve !foo from a scalar to a mapping. > cce: however, the !cast item is really introducing a simple transform > cce: !equal = key > oren: Now, if you liberally use implicit typing, that's not an issue, > really. > cce: right > oren: The system will load one as !foo#1.0 and the second as !foo#2.0. > Which is better, I think. > oren: It can also _transform_ from !foo#1.0 to !foo#2.0 if it wants. > Again, that's _changing_ the document. > cce: right > cce: these things are mutators > oren: So, schema evolution doesn't require us to allow this sort of > transformational trickery in the processor. On the other hand, if we did > allow your trickery, one _could_ put it there and get a different schema > evolution mechanism. But I'd claim it would mix people up. > oren: I think I'd rather keep things as they are... > cce: hmm > cce: can you archive this discussion and post? > > Clark then summarized: > > cce: ok, let me recap. The question was, if equality is defined only if > you know the tag, why restrict the tag to a particular kind (and no > other kinds)? > cce: the example used was a date, which could be seen as a scalar or a > mapping, and why not allow the scalar to be promoted to a mapping; > cce: but then, one would be violating wysiwyg > cce: ie, the text file in YAML would be quite different than what one > got via YPATH and/or schema tools > cce: schema -> structural schema > cce: hmm > cce: why is this bad again? > cce: cce is lacking sleep. > oren: "YAML is WYSISYG for data" is a good slogan. We don't want to give > it up. > cce: ok > oren: That's the whole _point_ of YAML... > > Well, there you have it. Tag still implies kind, and you can't > willy-nilly convert a date to a mapping. That's life. > > Have fun, > > Oren Ben-Kiki > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Clark C. E. <cc...@cl...> - 2004-02-07 22:16:57
|
I don't think this impacts anything, as the !include tag is really just an object. That you would run it though a separate stage to actually do the substitution is a separate issue. We will probably have parsers introduce an extra "expand" cycle where tags are converted into their content, but this is very different, IMHO, from the chicken we were discussing. I think. Clark On Sat, Feb 07, 2004 at 02:07:44PM -0800, Brian Ingerson wrote: | Interestig discussion. Let me throw another bone into the soup... | | We haven't discussed the old !include tag for some time. But it seems to | me this will be an example of where a scalar definitely becomes a | collection: | | --- !xyz.com/^thingy | items: | - !^item | x: 5 | y: 7 | z:9 | - !include file://path/to/item | | We should probably address this now rather than later. | | Cheers, Brian | | On 07/02/04 20:44 +0200, Oren Ben-Kiki wrote: | > This is a capture of a discussion Clark and I just had. The end result | > was that we decided to keep things as they are, so you can safely skip | > that. However, if you are interested _why_ we made this decision, read | > ahead at your own peril (this is unedited): | > | > cce: oh, there was another topic | > oren: ? | > cce: regarding brian's post, what you said was clear | > cce: let's muse here for a min though | > cce: you cant' have a 'complete' graph till it has been 'resolved' | > cce: by 'resolving', tags are added to the tree | > oren: or graph | > oren: or text, if you are sick :-) | > cce: assume for a minute that in the resolving phase, structural | > transformations are allowed in the subtree ;) | > oren: Then you are no longer merely loading the document, you are | > transforming it. Valid and all, but out of scope. | > cce: ie "2002-10-10" becomes !date { !str 'year': !int 2002, ... } | > oren: As long as you do the reverse when you dump - and be aware that | > you have _changed_ the document. | > cce: however, does it make sense to restrict a given 'tag' to a given | > kind. | > cce: ie !date 2002-10-10 and !date { ... } | > oren: Hmmm. | > cce: could we 'verify' why this constraint is necessary? | > oren: Strictly speaking, it isn't. | > cce: Well, I think the restriction is somewhat there | > oren: Oh, its there alright. | > cce: ie, a untagged plain scalar can be changed to a 'structure' during | > the tagging process | > cce: ie 2002-10-2 is ok, but !date '2002-10-2' isn't. | > oren: Boggles. | > cce: ie, if the tag is implicit (not in the text stream) it is ok | > cce: hmm. | > oren: Another angle on this. Schema evolution. | > cce: brb (thinking bout an explanation) | > oren: Suppose a scalar "evolves" to a collection... | > cce: ya, so our diagram is wrong | > oren: <groan> not another diagram </groan> | > cce: a kind is a property of a node, and not the tag | > oren: Not so fast. I might be convinced, but let's talk. | > cce: (making coffee, so give me about 1 min) | > oren: The question that needs to be answered, if you do that, is: What | > is the relationship between !tag <scalar>, !tag <sequence>, and !tag | > <mapping> ? Is there some mandatory relationship, or are these unrelated | > types (as far as YAML is concerned)? The answer is tricky. | > cce: lets use date as a test case | > cce: if I were representing, say a python date in YAML, it would | > definitely be a mapping. | > oren: I'd rather keep in mind the case of schema evolution as well. It | > sharpens the issue (or raises additional issues, if you will). | > cce: A yaml date object has several 'attributes', month, day, year, etc. | > cce: ok, evolution is also important | > oren: At any rate, go on. What is your view on the relationship issue? | > cce: anyway, so really 4 Mar 2004 should really be represented in YAML | > as { day: 4, month: 3, year: 2004 } | > cce: the '2004-03-04' is a presentation 'short hand' | > cce: its there to make the text stream readable | > cce: ok, let's call that the 'date problem' | > cce: now, let's talk about the integer problem | > oren: I didn't know there was one. | > cce: this one is simpler ten can be presented as 10, or 1A for example | > cce: how we deal with integers is that we say that the 'tag' must | > provide a canonical form | > oren: Ah. That one. | > cce: and then we can compare the canonical forms | > oren: Right. | > cce: who is to say that a canonical form can't actually be a sub-graph? | > cce: ie, the canonical form of my text date is that mapping | > oren: That's nice and all. But... let's see what happens to unknown | > types. | > cce: remember, I can't compare dates unless they are known anyway | > oren: Right. But, it used to be I could safely apply YPATH. | > cce: so, there isn't anything lost, right? | > oren: I can't safely say /birthday/year | > cce: ypath can still be applied | > oren: Not without schema knowledge. | > oren: /birthday/year will fail unless !date is resolved and recognized. | > cce: but ypath really could do much with scalar types without knowing | > the data type anyway. | > cce: /birthday/substring(1,4) isn't garmented to work either | > cce: because date could have come in another format other than ISO | > oren: Well, at least it returned something - something you could, say, | > print to the user. Now, I don't know what I'll be getting. | > oren: I don't know how important this is, but it is a loss. | > cce: hmm | > oren: You are basically saying: if you don't know the schema, well, you | > can't do much anyway, and it doesn't make sense to punish one who _does_ | > know the schema so you ignorant one will have some mostly-broken | > feature. | > oren: There is some sense in that, I guess. | > cce: well, I think it only makes sense for scalars you don't know about | > cce: I wouldn't extend it to structures | > oren: Slippery slope here... | > cce: ya | > oren: Can I change { 0: a, 1: b, 2 : c} to a sequence? | > cce: but we already are treating collections different than scalars -- | > as right we should, a scalar is OPAQUE to YAML. | > cce: no. | > cce: absolutely not | > oren: Because...? | > oren: Give me an argument that justifies forbidding it, if I can change | > '2002-01-02' to a mapping. What is true for collections that isn't for | > scalars? | > cce: because both of these structures are _not_ opaque to YAML | > cce: and they are different | > oren: Well, the { year: ... } mapping is also not opaque, so it is | > different from anything opaque like '2002-...'. Same argument. | > cce: what is true for scalars isn't true for collections, yes. | > cce: well, its tough | > oren: Consider this again. What would be the down side of allowing this? | > cce: it would break wysiwyg | > oren: It would mean that the connection between the model-as-visible in | > the file and the model-as-used for constructing objects may be | > different. wysiwyg, exactly. | > cce: ick | > oren: I would claim that '2004-02-01' being a map is also not wysiwyg. | > oren: I don't see what's special about the scalar case. It seems to me | > that the consistent thing is to either allow it everywhere or nowhere. | > cce: hmm | > oren: Before we decide, let's revisit schema evolution. | > cce: no, you are right, scalar -> map is not wysiwyg | > oren: We have the '=' key exactly to allow a scalar to evolve to a | > mapping. | > cce: right | > oren: Which is impossible if we say tag=>kind; once you set it, you set | > it. You could say !bloop#new-version but that's different. | > oren: As in !foo#1.0 is a scalar and !foo#2.0 is a mapping. | > cce: ya, I was fretting about this in November but didn't really bring | > it up | > oren: But you can't evolve !foo from a scalar to a mapping. | > cce: however, the !cast item is really introducing a simple transform | > cce: !equal = key | > oren: Now, if you liberally use implicit typing, that's not an issue, | > really. | > cce: right | > oren: The system will load one as !foo#1.0 and the second as !foo#2.0. | > Which is better, I think. | > oren: It can also _transform_ from !foo#1.0 to !foo#2.0 if it wants. | > Again, that's _changing_ the document. | > cce: right | > cce: these things are mutators | > oren: So, schema evolution doesn't require us to allow this sort of | > transformational trickery in the processor. On the other hand, if we did | > allow your trickery, one _could_ put it there and get a different schema | > evolution mechanism. But I'd claim it would mix people up. | > oren: I think I'd rather keep things as they are... | > cce: hmm | > cce: can you archive this discussion and post? | > | > Clark then summarized: | > | > cce: ok, let me recap. The question was, if equality is defined only if | > you know the tag, why restrict the tag to a particular kind (and no | > other kinds)? | > cce: the example used was a date, which could be seen as a scalar or a | > mapping, and why not allow the scalar to be promoted to a mapping; | > cce: but then, one would be violating wysiwyg | > cce: ie, the text file in YAML would be quite different than what one | > got via YPATH and/or schema tools | > cce: schema -> structural schema | > cce: hmm | > cce: why is this bad again? | > cce: cce is lacking sleep. | > oren: "YAML is WYSISYG for data" is a good slogan. We don't want to give | > it up. | > cce: ok | > oren: That's the whole _point_ of YAML... | > | > Well, there you have it. Tag still implies kind, and you can't | > willy-nilly convert a date to a mapping. That's life. | > | > Have fun, | > | > Oren Ben-Kiki | > | > | > | > ------------------------------------------------------- | > The SF.Net email is sponsored by EclipseCon 2004 | > Premiere Conference on Open Tools Development and Integration | > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. | > http://www.eclipsecon.org/osdn | > _______________________________________________ | > Yaml-core mailing list | > Yam...@li... | > https://lists.sourceforge.net/lists/listinfo/yaml-core | | | ------------------------------------------------------- | The SF.Net email is sponsored by EclipseCon 2004 | Premiere Conference on Open Tools Development and Integration | See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. | http://www.eclipsecon.org/osdn | _______________________________________________ | 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 |
From: Oren Ben-K. <or...@be...> - 2004-02-07 23:10:41
|
Clark C. Evans wrote: > I don't think this impacts anything, as the !include tag is > really just an object. That you would run it though a > separate stage to actually do the substitution is a separate > issue. We will probably have parsers introduce an extra > "expand" cycle where tags are converted into their content, > but this is very different, IMHO, from the chicken we were > discussing. I think. Agreed. Think of it this way - a document with an !include directive is different from a document that directly contains the data. In fact you'd want to have user control over the inclusion. For example: if you pretty-print the document, you'd sometimes want to be able to print the !include itself, and sometimes expand it. Performing the inclusion changes the document, so it can replace the !include element with anything at all. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2004-02-08 01:44:15
|
On 08/02/04 01:10 +0200, Oren Ben-Kiki wrote: > Clark C. Evans wrote: > > I don't think this impacts anything, as the !include tag is > > really just an object. That you would run it though a > > separate stage to actually do the substitution is a separate > > issue. We will probably have parsers introduce an extra > > "expand" cycle where tags are converted into their content, > > but this is very different, IMHO, from the chicken we were > > discussing. I think. > > Agreed. Think of it this way - a document with an !include directive is > different from a document that directly contains the data. In fact you'd > want to have user control over the inclusion. For example: if you > pretty-print the document, you'd sometimes want to be able to print the > !include itself, and sometimes expand it. Performing the inclusion > changes the document, so it can replace the !include element with > anything at all. Include "directive"? I don't think so. I mean really, at this point !include /path is a tagged scalar. Is this a special case. Do you want to talk about it? Do we need directives at the node level? %include:/path? Cheers, Brian > > Have fun, > > Oren Ben-Kiki > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@be...> - 2004-02-08 07:24:38
|
Brian Ingerson wrote: > Include "directive"? I don't think so. I mean really, at this > point !include /path is a tagged scalar. Is this a special > case. Do you want to talk about it? Do we need directives at > the node level? %include:/path? I misspoke; I meant the '!include' element (which directs the processor to include some other document, or not, as the case may be). Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2004-02-08 08:23:27
|
On 08/02/04 09:24 +0200, Oren Ben-Kiki wrote: > Brian Ingerson wrote: > > Include "directive"? I don't think so. I mean really, at this > > point !include /path is a tagged scalar. Is this a special > > case. Do you want to talk about it? Do we need directives at > > the node level? %include:/path? > > I misspoke; I meant the '!include' element (which directs the processor > to include some other document, or not, as the case may be). But surely this 'element' is a tag. It uses the tag syntax. What am I missing here? Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-02-08 18:13:38
|
Brian Ingerson wrote: > But surely this 'element' is a tag. It uses the tag syntax. > What am I missing here? Don't push it :-) |
From: Brian I. <in...@tt...> - 2004-02-08 22:39:37
|
On 08/02/04 20:13 +0200, Oren Ben-Kiki wrote: > Brian Ingerson wrote: > > But surely this 'element' is a tag. It uses the tag syntax. > > What am I missing here? > > Don't push it :-) But that's exactly what I *am* doing. Please oblige me by stating how you think we might accomodate such a mechanism, and how it fits in with our current syntax and models. If you don't talk about this now, it will come back to bite you. Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-02-09 07:41:49
|
Brian Ingerson wrote: > But that's exactly what I *am* doing. Please oblige me by > stating how you think we might accomodate such a mechanism, > and how it fits in with our current syntax and models. If you > don't talk about this now, it will come back to bite you. OK: An "!include foo" tagged element is a scalar, period. It's value is "foo". Its tag is "!include". Its canonical value is a URL. > > ... a document with An element with an > > !include tag > > is different from a document that directly contains the data that would result from performing the inclusion. > > In fact > > you'd want to have user control over the inclusion. For example: if > > you pretty-print the document, you'd sometimes want to be able to > > print the element with the > > !include tag > > itself, and sometimes expand it. Performing the > > inclusion changes the document, so it can replace the > > !include tagged > > element > > with anything at all (in particular, with the content of some other document) > >. So, it is reasonable to expect that a processor would allow the caller to specify whether or not to perform inclusions, either globally or on a case-by-case basis. The question of the !include tag and schemas is trickier. It suspect the most common way to handle it is to simply ignore the !include tag in the schema. Instead, specify the schema for the results of performing the inclusion. However, in special cases, it might make sense to provide both a schema for the original document (referring to the !include tagged elements) and a (related) schema for the results of performing the inclusion (referring to the content of the included documents). It is all very natural once you accept that there are two different (though related) documents, one before performing the inclusion and one resulting from performing the inclusion. Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-02-07 18:36:41
|
On Fri, Feb 06, 2004 at 07:51:22PM -0800, Brian Ingerson wrote: | You could also have an application that serialized tables like such: | | --- | table: | | +-----+-----+-----+ | | 5 | 3 | 1 | | +-----+-----+-----+ | | 7 | 6 | 5 | | +-----+-----+-----+ | | 9 | 2 | 9 | | +-----+-----+-----+ I'd rather have a pretty printer that recognized tables and spit them out with a nice readable presentation: --- table: - [ 5 , 3 , 1 ] - [ 7 , 6 , 5 ] - [ 9 , 2 , 9 ] |