From: Oren Ben-K. <or...@ri...> - 2002-05-07 21:09:24
|
I just sent a post that crossed this one... Clark C . Evans wrote: > I've got to spend more time on my day job for the next > few weeks; so updating the spec will have to wait a > while... (unless someone else wants to take a stab) I'm willing to take it on, for a known token price :-) Your changes plan is more ambitious than mine, but I guess it is better to detail things... One point: > (d) the "type" of native object chosen should be determined > primarly on the type family and perhaps the content (in > the case of overflows, etc.) but should > be a factor of kind or format. You mean "should not depend on the kind or format", right? > few more thoughts: > > - The "transfer method" is two part; the family and the format. > the family survives round-trips in all cases and the format > may be changed via the NATIVE model round-trip. > > - The "kind" must always be preserved for data to be considered > "properly round-tripped" since some processors may not be able > to do the "compatibility" operation above. Even when going through a NATIVE model? This seems overly restrictive. If you insist, however... > Overall, I agree wholeheartedly with Oren's argument about > type family implying kind. And thus think that this should > go into the NATIVE model somewhere as a strong recommendation. Requirement :-) > However, just about any API representation of the SYNTAX, TREE, > and GENERIC models will have to distinguish between each kind > in a fundamental way by either using different event orderings > or different surrogate objects such as hashtables, arrays, > and strings. As such, I find it impractical to assert this > requirement in the other non-NATIVE models and our generic tools > should not assume this constraint. This argument can be used to claim that point (d) above can't be made. I think that specifying that requiring that each type family accept just one kind isn't artificial at all. It will be reflected directly in the APIs offered by Loader implementations, and as such will enforce what we all agree to be a vital property of YAML (Compatibility). Yes, it isn't reflected in the SYNTAX, TREE or GENERIC models. How can it? It is a specification of restrictions on the translation between a GENERIC model and the NATIVE one. By definition it can't effect anything other than the NATIVE model. > I think this does it. I've got to turn my focus away from YAML > for a while. It looks like the model clarifications will not > allow us to go "release canidate" on the 10th. That's cool, it > was rather arbitrary anyway. Yes. A pity, though... Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-05-08 05:39:02
|
Clark C . Evans wrote: > | > - The "kind" must always be preserved for data to be considered > | > "properly round-tripped" since some processors may not be able > | > to do the "compatibility" operation above. > | > | Even when going through a NATIVE model? This seems overlyi > | restrictive. If you insist, however... > > My logic goes this way; if a program "upgrades" the > data by injecting a compatibility mapping, then they > have changed the data. Thus, it is not a pure round-trip. OK. But note that a Filter that goes all the way to the NATIVE model would therefore be hard-pressed to "round trip". I guess that true anyway (think of things like default values for class members, etc.). I guess that's part of why YNY is so hard. I'll go with this. > | I think that specifying that requiring that each type family accept > | just one > | kind isn't artificial at all. It will be reflected directly in the > | APIs > | offered by Loader implementations, and as such will enforce what we > | all > | agree to be a vital property of YAML (Compatibility). > > Ok. I'm sold. And BTW, I like calling it "Compatibility" instead of > "Color" Great! Yes, it is a clearer name. And thanks for insisting Strict is too strict. Compatible is best. > | > I think this does it. I've got to turn my focus away from YAML > | > for a while. It looks like the model clarifications will not > | > allow us to go "release canidate" on the 10th. That's cool, it > | > was rather arbitrary anyway. > | > | Yes. A pity, though... > > Yes, but it is 3 days away... and I just have 0min left for > YAML specific stuff... (although I am going to finish giving > a python binding to the emitter). Perhaps we should have a > smaller party and Neil may be willing to publish a "preview" > of libyaml... *smile* ... it will have to be modified to > reflect the changes made here (in terminology). Would June 6th or June 13th work for a target date and a YAML party in NY? I'm free there both these days (and possibly also June 14th, if I delay going back to Israel by one day - but I'll have to decide on that real soon, since I'm finalizing my itinerary this week). Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-05-08 06:07:17
|
On Wed, May 08, 2002 at 01:40:51AM -0400, Oren Ben-Kiki wrote: | > Ok. I'm sold. And BTW, I like calling it "Compatibility" | > instead of "Color" | | Great! Yes, it is a clearer name. And thanks for insisting Strict is too | strict. Compatible is best. Ok. I guess it is up to Brian to add his blessing to option 0.5 It seems like the most resonable model; it won't be hard to grok if it is sold as a "restriction". In other words, keep the kind attached to the node (instead of attaching it to the family) but then add the restrictive verbage. This will be the least confusing. | Would June 6th or June 13th work for a target date and a YAML party in NY? | I'm free there both these days (and possibly also June 14th, if I delay | going back to Israel by one day - but I'll have to decide on that real soon, | since I'm finalizing my itinerary this week). That'd work for me; which one? You have a hotel room in NYC? Otherwise we could crash at an apartment of a coworker (although it'd be cramped) or split-up. Brian, NYC is 4 hours via car from D.C. So if you are still up for the road trip... otherwise you may just want to grab a puddle jumper. Alternatively, you could take the rail line down to D.C. and stay over an evening; although I have 2 cats... if you have alergies. Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Clark C . E. <cc...@cl...> - 2002-05-07 23:32:31
|
Ok. I'm willing to settle, we've beat this here horse to death. | > (d) the "type" of native object chosen should be determined | > primarly on the type family and perhaps the content (in | > the case of overflows, etc.) but should | > be a factor of kind or format. | | You mean "should not depend on the kind or format", right? Yes. "not" must have been deleted in my editing. Also, when writing the "generic" model; it'd be good to list the relationship between kind and family as a constraint. In other words, kind is a property of both the node; plus the constraint. | > - The "kind" must always be preserved for data to be considered | > "properly round-tripped" since some processors may not be able | > to do the "compatibility" operation above. | | Even when going through a NATIVE model? This seems overlyi | restrictive. If you insist, however... My logic goes this way; if a program "upgrades" the data by injecting a compatibility mapping, then they have changed the data. Thus, it is not a pure round-trip. | > Overall, I agree wholeheartedly with Oren's argument about | > type family implying kind. And thus think that this should | > go into the NATIVE model somewhere as a strong recommendation. | | Requirement :-) Ok. Requirement. | I think that specifying that requiring that each type family accept just one | kind isn't artificial at all. It will be reflected directly in the APIs | offered by Loader implementations, and as such will enforce what we all | agree to be a vital property of YAML (Compatibility). Ok. I'm sold. And BTW, I like calling it "Compatibility" instead of "Color" | > I think this does it. I've got to turn my focus away from YAML | > for a while. It looks like the model clarifications will not | > allow us to go "release canidate" on the 10th. That's cool, it | > was rather arbitrary anyway. | | Yes. A pity, though... Yes, but it is 3 days away... and I just have 0min left for YAML specific stuff... (although I am going to finish giving a python binding to the emitter). Perhaps we should have a smaller party and Neil may be willing to publish a "preview" of libyaml... *smile* ... it will have to be modified to reflect the changes made here (in terminology). Best, Clark |
From: Neil W. <neilw@ActiveState.com> - 2002-05-07 23:45:58
|
Clark C . Evans [07/05/02 19:38 -0400]: > Neil may be willing to publish a "preview" > of libyaml... *smile* ... it will have to be modified to > reflect the changes made here (in terminology). You mean renaming the events, rights? leaf_handler scalar_handler keyed_handler => map_handler series_handler sequence_handler and so on. Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-05-08 04:42:42
|
On Tue, May 07, 2002 at 04:45:38PM -0700, Neil Watkiss wrote: | Clark C . Evans [07/05/02 19:38 -0400]: | > Neil may be willing to publish a "preview" | > of libyaml... *smile* ... it will have to be modified to | > reflect the changes made here (in terminology). | | You mean renaming the events, rights? | | leaf_handler scalar_handler | keyed_handler => map_handler | series_handler sequence_handler Yes. Only I'd prefer "mapping" to "map" to be more consistent with "scalar" and "sequence". ;) Clark |
From: Brian I. <in...@tt...> - 2002-05-09 01:28:59
|
On 07/05/02 19:38 -0400, Clark C . Evans wrote: > > | > Overall, I agree wholeheartedly with Oren's argument about > | > type family implying kind. And thus think that this should > | > go into the NATIVE model somewhere as a strong recommendation. > | > | Requirement :-) > > Ok. Requirement. I will go with compatible. I'm basically lost in the arguments at this point, but it seems at the surface like we have the bases covered. The above paragraph triggers redflag thoughts though. Could someone explain this in detail. Why do we need to store type family in the native model? Do you mean explicitly, or implied? Would it be exposed or opaque to the application? I'm confused. The important things to me are: - We distinguish between map and sequence at the graph model. - We simplify the verbage. - We don't put constraints on the native model. - We target Ytools at the graph model. I've been working on the new API for libyaml. Interesting... It turns out that the same work required by application to define dumping opaque to graph, is exactly the layer needed to support Ytools at the native model. I guess that is obvious now that I realize it. I've even figured out how to round trip things like key order in a YNY scenario. Interesting stuff. Also, Neil and I were discussing (over coffee) (good to be in Vancouver :) that the same node structure created by the parser is the very argument that you want to pass to a graph-to-native transform. Only it would have an associated class for accessing things like kind, family and content. At that point it makes me wonder (again) why family must imply kind... Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-05-09 02:42:02
|
On Wed, May 08, 2002 at 06:28:50PM -0700, Brian Ingerson wrote: | The above paragraph triggers redflag thoughts though. Could someone explain | this in detail. Why do we need to store type family in the native model? Do | you mean explicitly, or implied? Would it be exposed or opaque to the | application? I'm confused. Our wording above was bad. The native model will be worded so that anything is allowed (opaque as a native binding would be) as long as it it has an "image" in the graph model, complete with the constraints of the graph model. | - We distinguish between map and sequence at the graph model. | - We simplify the verbage. | - We don't put constraints on the native model. | - We target Ytools at the graph model. Yep. Only that we have the kind/family compatibility constraint. | I've been working on the new API for libyaml. Interesting... It turns out | that the same work required by application to define dumping opaque to graph, | is exactly the layer needed to support Ytools at the native model. I guess | that is obvious now that I realize it. Hmm. | I've even figured out how to round trip things like key order in a YNY | scenario. Interesting stuff.a Well, this would mean that your application is working at the "tree" or "syntax" model, and not with the graph model. It's ok to round-trip key order; but the graph model does not (obviously) require this. ;) | Also, Neil and I were discussing (over coffee) (good to be in Vancouver :) | that the same node structure created by the parser is the very argument | that you want to pass to a graph-to-native transform. Only it would have an | associated class for accessing things like kind, family and content. Right. The yaml_node_t structure will be shared between the sequential-access API and a random-access API. ;) | At that point it makes me wonder (again) why family must imply kind... It depends how you think of YAML. If you consider YAML as just a serialization language; then the compatibility constraint does not seem obviously needed. And, I'd rather you think of it as a constraint on a document rather than "family implies kind", since "family implies kind" gives the wrong API idea... The constraint is needed so that one can uniquely 'identify' nodes of a particular kind using the family URI irrespective of the kind and/or format. Without this constraint, this isn't possible and then the "type" of the node becomes a tuple (family,kind) which is much harder to work with. Thus, to make the generic model more "useable" this constraint is needed. Basically, 99.9% of user data expressable won't violate the constraint; but the data that does is just "invalid YAML". This is needed since it keeps the YAML specific tools simpler... that is, it can consider "family *is* the node's type", rather than "family is only one factor in the node's type... let me check the other part, kind". I hope this helps! In short, the constraint isn't obvious from the API (and it may even be a bit counter intuitive) but it is needed to have a clean YAML toolset, and it happens to fit the common data patterns (despite a slightly less pretty syntax). Best, Clark |